The Six-Step Order I Use Before Handing Claude Code to Non-Engineers — A Rollout Design for Tiny Teams

Step 1: a bootstrap script you actually want to run

The most reusable piece of the WINTICKET program is the way session 0 is delivered through a single script that installs Claude Code's Managed Settings, a Managed CLAUDE.md, and recommended brew and pnpm settings. Their note about it — "this lets us suppress support load during the session while giving everyone the same safe initial setup" — is exactly the lever a tiny team needs.

Here's the version I use:

#!/usr/bin/env bash
# bootstrap-claude-code.sh — onboarding for non-engineers
set -euo pipefail
 
if ! command -v brew >/dev/null; then
  echo "Install Homebrew first via the official instructions."
  exit 1
fi
brew install node pnpm gh git
 
sudo mkdir -p "/Library/Application Support/ClaudeCode"
sudo tee "/Library/Application Support/ClaudeCode/managed-settings.json" >/dev/null <<'JSON'
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Bash(git diff:*)",
      "Bash(git status)",
      "Bash(pnpm:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "WebFetch(domain:*)"
    ],
    "defaultMode": "ask"
  },
  "env": {
    "CLAUDE_CODE_DISABLE_BUG_REPORT": "true"
  }
}
JSON
 
sudo tee "/Library/Application Support/ClaudeCode/managed-CLAUDE.md" >/dev/null <<'MD'
# Team-wide Claude Code rules
- Never Read files that contain customer PII, billing data, or API keys
- Hands off: .env, .env.local, secrets/*, *.pem, *.key
- All curl/wget to external hosts is denied — escalate to a human
- Any bulk-delete proposal must be escalated before execution
MD
 
mkdir -p ~/.config/pnpm
cat > ~/.config/pnpm/rc <<'INI'
save-prefix=""
minimum-release-age=1440
INI
 
echo "✅ Setup complete. Run `claude --help` to confirm."

Drop this on a private GitHub repo or a USB stick and every new collaborator starts on the same ground. The savings add up fast — every new tool I've adopted since 2014 has cost me ten to twenty wasted minutes per teammate just from "it doesn't run on my machine." A bootstrap script kills that recurring tax once.

Step 2: build a quiz so someone can actually say "no"

CyberAgent's session 2 includes a Permission quiz. The original article calls out a specific failure mode I've watched up close: non-engineers "click Allow without understanding what they're allowing, which leads to prompt-injection incidents, unnecessary token spend, and worse productivity." A small paper quiz prevents most of that.

I print the following on a single page and hand it to anyone touching Claude Code for the first time:

Q1. Claude Code asks for "Bash(rm -rf node_modules)" inside a Next.js project you're working on.
    a) Allow once   b) Always allow   c) Deny   d) Ask Claude what it intends to do first

Q2. Claude Code asks for "WebFetch(domain:slack.com)" but you only asked it to tidy up a README.
    a) Allow   b) Deny   c) Ask Claude what it's trying to fetch

Q3. Claude Code asks to read ".env.local" but you weren't editing API keys.
    a) Allow   b) Deny   c) Hit Esc, open the file yourself, then resume

Correct answers: d, c, c. If someone picks "a," I take one minute to explain why "a" was the wrong move. The framing I want to land is, "an Allow click is an act of trust, and the responsibility moves to you the instant you click." Once that idea sticks, the rest of the rollout gets dramatically easier.

Step 3: ship a real PR on day one

This is the part of the WINTICKET design I most want to copy. Session 3 is a hands-on where everyone adds their own name file to a shared repo via a PR. The follow-on signal — thirteen non-engineer PRs in the first month, marketing teammates writing their own automation scripts — comes directly from this single experience.

For Dolice Labs I built a small "welcome" repo for the same purpose. A new collaborator opens Claude Code, writes a one-page profile Markdown about themselves, and ships it as a PR I merge:

cd ~/welcome
claude
> Create people/{your-name}.md and write a short self-introduction.
> Run git status to confirm the change, branch with
> git checkout -b intro/{your-name}, commit, then open a PR
> using gh pr create --fill.

The moment a first PR merges, Claude Code stops being a chat box and becomes a tool that delivers real changes to a real place. An editor who once helped me with marketing copy told me afterwards, "I finally feel like I'm someone who can do Git." That feeling is the whole point.

The original post nails the underlying motivation: "you don't strictly need Git or GitHub to use Claude Code, but once everyone in the business unit can use it, each team starts wanting to gather their CLAUDE.md and Claude Code Skills in one place." That instinct shows up the moment people see a PR merge.

Step 4: pnpm narrows the supply-chain attack surface for free

Session 4 of the CyberAgent program teaches supply-chain risk through npm, and recommends pnpm as a defense: minimumReleaseAge on the workspace, an empty savePrefix that pins versions exactly, and a whitelist (onlyBuiltDependencies) for lifecycle scripts. I run three rules across every Dolice Labs project:

1. No new package gets installed until it has aged 24 hours — minimum-release-age=1440 (minutes) makes this mechanical
2. No ^ or ~ — save-prefix="" pins versions exactly so a poisoned release can't sneak in via a minor bump
3. Lifecycle scripts are opt-in only — onlyBuiltDependencies lists the few packages that may run scripts

// package.json (project root)
{
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild",
      "sharp"
    ]
  }
}

# ~/.config/pnpm/rc
save-prefix=""
minimum-release-age=1440

The same defenses now live in the six automated publishing pipelines that drive Lacrima and Mystery. The CyberAgent post is correct that the underlying risk lives anywhere we install code from outside — PyPI, MCP servers, Claude Code plugins, VS Code extensions — and I extend the same caution to Skills I drop into .agents/skills/: I check the author and the recent history before running any of them.

Step 5: replace the exam with a real first task

WINTICKET ends with a certification exam (12 multiple choice, 8 written, 80 to pass) and gates a useful internal tool behind it. The structure works because the gate is real. For a tiny team an actual exam is overkill, so I use a real first task instead:

• Read one existing MDX article in Claude Code and ship a PR that fixes typos
• Read one site's CLAUDE.md and ship a Markdown summary as a PR
• Pick one feature from a vendor's docs, write an internal Skill, and ship it as a PR

When the PR merges, I say out loud: "you're a real contributor to this project now." The line matters. WINTICKET buys the same effect with the gamification of a certificate; for a solo shop, a merged PR is the certificate.

Step 6: take the numbers at three months or it didn't happen

The CyberAgent post is convincing because it shows the after picture — thirteen PRs in the first month, a marketing teammate publishing automation, photos of business members talking about Claude Code in their normal flow. None of that is visible without measurement.

After three months of running the compressed program, I always pull these four numbers:

• PRs opened by non-engineers outside the welcome repo
• Total hours I spent reviewing their code
• Permission deny rate (the share of times the human said "no")
• Repetitive tasks that were silently done by hand instead of via the new path

A zero-percent deny rate in month one is a warning — it means people are clicking Allow on autopilot. That sends me back to step 2 to reissue the quiz.

Closing — six steps as an investment, not a chore

The reason a company the size of CyberAgent invests in six sessions is to lift the safety floor of the whole organization at once. The same logic applies in miniature to a solo developer: a half day spent up front means the next person who joins is a half day, not a month, behind.

I run four sites, two blog properties, and six apps as a one-person operation, so the next teammate is still a far-off "maybe." Even so, I've decided that always being ready to hand the tools off is part of the work I want to leave behind. I learned to code in 1997 by following English tutorials posted by strangers I never met. It's my turn to be one of the strangers who left a usable trail.

The smallest next step: write a one-line bootstrap-claude-code.sh today, even if it's nearly empty. The next time you want to hand Claude Code to someone, you'll already be half ready.

Thanks for reading.