← Claude Code & Certification

[BORIS] Mastering Claude Code in 30 Minutes

[BORIS] Mastering Claude Code in 30 Minutes

Source: workshop “Mastering Claude Code in 30 Minutes” by Boris Cherny, Member of Technical Staff at Anthropic and creator of Claude Code.

This file collects Boris’s specific emphasis and meta-principles. The cert-track notes (claude-code-101, claude-code-in-action, introduction-to-subagents, introduction-to-agent-skills) cover the same surface area but underweight the items captured here. Where the two diverge, trust Boris — he wrote the tool.


TL;DR — 10 principles to memorize

  1. Start with codebase Q&A. Don’t let Claude touch code on day one.
  2. CLAUDE.md is the most underrated feature — it’s how you “train” Claude on your team’s codebase.
  3. For big features, the magic prompt is: “Brainstorm the approach, write a plan, ask me for approval before writing code.”
  4. Give Claude a way to verify its own work (unit tests, screenshots, simulator) — it will iterate to near-perfect.
  5. “commit, push, PR” — three words, Claude handles all of it.
  6. Plug your team’s tools (custom CLIs + MCP servers) — this is when Claude Code actually shines.
  7. Use dictation — spoken prompts are longer and more specific than typed ones.
  8. Shift+Tab to enable auto-accept when you trust the direction.
  9. # writes a memory line into CLAUDE.md instantly.
  10. Multi-Claude with git worktree — how power users actually work.

The Hierarchy of Mastery

How Anthropic onboards new engineers. Cut technical onboarding from 2-3 weeks to 2-3 days.

Level 4: Multi-Claude + SDK automation + enterprise CLAUDE.md
   ↑
Level 3: Plug in team tools (custom CLIs + MCP servers)
   ↑
Level 2: Editing with plan-first + feedback-loop workflow
   ↑
Level 1: Codebase Q&A — START HERE, teach your team HERE

Don’t skip levels. Each one teaches a habit you’ll carry up.


Level 1 — Codebase Q&A

Claude does not index your codebase. No upload. No remote DB. No model training on your code. You can use it the second installation finishes — no waiting for indexing.

Starter prompts:

"How is the OrderService class instantiated and used in this codebase?"

"Look through git history and explain why the createOrder function has 15 arguments
 and why they're named so weirdly."

"Fetch issue #234 and explain the context of this bug."

"Look through git log, my username is tuannn. What did I ship this week?
 Format as a standup update."

Claude figures out git log, git blame, gh on its own — no system prompt needed. The model is good. Trust it.

Why start here?

  • Zero risk of breaking code.
  • Teaches you Claude’s capability boundary on your codebase.
  • Non-engineers on the team can use it too.

Level 2 — Editing with the right workflow

Claude has a few simple tools (edit, bash, search) and chains them intelligently.

A. Plan-first for big features

Verbatim prompt to memorize:

“Brainstorm the approach, write a plan, and ask me for approval before writing code.”

You don’t need a special plan-mode command. Just say it. Single cheapest way to avoid 3000 wrong lines.

B. Feedback loop — the single biggest differentiator

Boris’s strongest claim: give Claude a way to verify itself, and it will iterate 2-3 cycles to near-final output. This is what separates Claude Code from every other AI assistant.

SurfaceVerification signal
Backend / libraryunit tests (npm test, pytest, cargo test)
Web UIscreenshot via Puppeteer/Playwright MCP
MobileiOS Simulator screenshot
Statictsc --noEmit, npm run lint

If no signal exists, create one before iterating. Coding without a feedback loop = guessing blind.

C. “commit, push, PR”

Three words. Claude:

  1. Reads git log to learn your team’s commit style
  2. Stages, writes the commit message in that style
  3. Branches if needed
  4. Pushes
  5. Opens the PR via gh

No system prompt, no template, no skill. The model figures it out.


Level 3 — Plug in team tools

A. Bash CLIs

We have a CLI called `transformctl`. Run `transformctl --help` to learn how to use it,
then use it to deploy the staging environment.

First call: Claude reads --help. After: dump the knowledge into CLAUDE.md so it persists across sessions.

B. MCP servers

This is where Claude Code becomes a force multiplier. Compose Claude with your team’s domain.

Example chain: “Use Haravan MCP to fetch top 10 SKUs by revenue, write a Markdown report, post it to the Lark group ‘BGD Daily.’” Claude orchestrates the MCP servers end-to-end.


Level 4 — Maximize context

“The more context Claude has, the smarter its decisions get.” — Boris

CLAUDE.md hierarchy

~/.claude/CLAUDE.md                # personal, every project
/repo/CLAUDE.md                    # team-shared, project root
/repo/CLAUDE.local.md              # personal-for-this-project
/repo/src/agents/CLAUDE.md         # nested — only loaded when working inside /agents

Nested CLAUDE.md is the underused power feature: per-module instructions without bloating context for unrelated work. Enterprises can also pin a policy-level CLAUDE.md across all employees.

Keep CLAUDE.md SHORT. Long ones eat the context window and rarely beat lean ones.

Slash commands

.claude/commands/*.md — one file per repeatable workflow. Anthropic’s own repo uses /label-issues to auto-label GitHub issues from a fixed taxonomy. Same files run in GitHub Actions for CI.

Multi-Claude with git worktree

git worktree add ../myapp-feature-a feature-a
git worktree add ../myapp-feature-b feature-b
git worktree add ../myapp-bugfix    bugfix-123

cd ../myapp-feature-a && claude
cd ../myapp-feature-b && claude
cd ../myapp-bugfix    && claude

Each Claude has its own context, no file conflicts, can run tests independently. While one waits for tests, switch to another. Practical “self-cloning” pattern for solo devs.


SDK — Claude Code as a Unix utility

Headless mode via claude -p:

claude -p "Analyze this log file and find anomalies" \
  --allowed-tools "Bash(grep:*),Read" \
  --output-format json

Pipe-in / pipe-out — this is the same SDK that powers the interactive mode:

# Group git changes by feature area
git status --porcelain \
  | claude -p "Group these changes by feature area" --output-format json \
  | jq .summary

# Diff review in CI
git diff origin/main \
  | claude -p "Review this diff for security issues" --output-format json \
  > review.json

# Incident triage
gcloud logging read "severity>=ERROR" --limit 1000 \
  | claude -p "Summarize the top 3 error patterns and suggest fixes"

# Sentry regression detection
sentry-cli issues list --project=my-app \
  | claude -p "Which issue is most likely a regression from yesterday's deploy?"

“Think of it as a super-intelligent Unix utility.” — Boris


Keybindings worth memorizing

KeyAction
Shift+TabToggle auto-accept mode
#Append a line to CLAUDE.md (instant memory)
!Drop into bash mode
@Mention a file
EscInterrupt Claude mid-action
Esc EscStep back through history
Ctrl+RShow full output

The “Esc-to-redirect” pattern

Claude proposes 20 changes. 19 are right, 1 is wrong. Don’t let it finish wrong and clean up after. Hit Esc, redirect:

“Change if (x > 10) to if (x > 100) and reapply.”

Claude redoes. Cheap, fast, saves context.


Multimodal — often forgotten

Claude Code has been multimodal from day one but the terminal hides it:

  • Drag-and-drop images into the terminal — supported.
  • Cmd+V to paste an image — supported.
  • @path/to/image.png — inline file reference.

Designer ships a Figma PNG → drop it in → “Implement this UI. Dev server is at localhost:3000. Use Puppeteer MCP to screenshot and iterate until it matches the mockup.” Walk away. Come back to working UI.


Boris’s meta-principle (the most important paragraph)

“You don’t have to prompt it specifically to use this tool and that tool. You just say ‘do this thing’ and it’ll figure out how to do it. The model is good. We’re lucky to be building on such a good model.”

Trust the model. Don’t over-engineer prompts. Don’t micromanage tool selection. Give context, give a feedback loop, get out of the way.

This is in tension with the cert-track best-practice checklists. Both can be true: when learning, checklists scaffold the habit. Once fluent, the checklist disappears and you trust the model.


Why CLI, not IDE?

  1. Common denominator — Anthropic engineers use VS Code, Zed, Xcode, Vim, Emacs. Terminal is the only surface every one of them shares. Build for everyone, not for one editor.
  2. Future-proofing“There’s a real chance people won’t use IDEs by end of year.” (Boris) When the model is changing this fast, investing in a UI layer is wasted. CLI is the minimum interface that survives every model jump.

What Anthropic actually struggled with

Bash safety. Bash is inherently dangerous (mutates system state) but approving every command kills productivity. Their landed solution:

  • Read-only commands auto-approved (ls, grep, cat, …)
  • Static analysis catches dangerous chains
  • Tiered permissions across user / project / enterprise

Credibility anchor

80% of Anthropic engineers use Claude Code daily — including researchers, who lean on the notebook tool for Jupyter. Internally dogfooded, not marketing.


Cheatsheet — print this

SETUP:     /terminal-setup  /theme  /install-github-app  /permissions

KEYS:      Shift+Tab=auto   #=memory   !=bash   @=file
           Esc=stop         Esc Esc=history   Ctrl+R=output

WORKFLOW:  Q&A → Plan → Code (with feedback loop) → "commit, push, PR"

CONTEXT:   CLAUDE.md (team)         CLAUDE.local.md (you)
           .claude/commands/*.md    .mcp.json (team-shared)

SDK:       claude -p "..." --output-format json
           Pipe in, pipe out — like a smart Unix utility

PARALLEL:  git worktree add ../feat-x feat-x
           One Claude per worktree — don't self-limit to one session

This file is curated commentary on Boris’s emphasis, not a verbatim transcript. For exam-track material, see the cert- notes in this folder. Where the cert notes contradict Boris on a model-behavior claim, trust Boris.*