Field Manual
Claude Code in 14 Days
From novice to skilled user — one focused session a day.
Each day has three parts: Learn the concept hands-on, run the Drill to build the habit, then answer the Teach-back question out loud as if explaining it to a beginner. The spots where you go vague are exactly the gaps to revisit before moving on.
git init a junk project) as your sandbox, and keep everything in Git so every mistake is one git reset away. Exact slash commands and key bindings shift between versions — run /help inside Claude Code or check the official docs when something looks different.Week 1 · Foundations
The mental model, the plan-first habit, and a complete feature loop.
Setup & the agentic loop
Get installed and form the right mental model before anything else.
Install via the native installer (or Homebrew / WinGet), then cd your-project && claude and log in. The core loop: you describe what you want → Claude reads files, edits them, and runs commands → you review and iterate. It's an agent, not autocomplete. Watch the permission prompts and actually read what it proposes before approving — that's your safety rail.
In your sandbox: ask "What does this project do? Summarize the structure." Then have it read one file and explain it step by step. Then ask for one trivial change (a comment or log line), approve it, and undo with git reset.
"What kind of tool is Claude Code, what actually happens in one turn when I send a message, and why does it ask permission before doing things?"
Resources · Quickstart · Overview
Prompting & the explore→act→verify rhythm
Output quality is mostly context and specificity, not magic words.
Specific beats vague: name the goal, the files, and the constraints. Give Claude a reference — pasting an example of good existing code noticeably improves output. Adopt the rhythm: explore (have it read and explain before changing anything) → act → verify (run the tests).
Write the same task two ways — once vaguely, once with explicit files, constraints, and a reference snippet — in two fresh sessions. Compare results and note exactly what made the better one better.
"A friend says Claude Code 'gives bad answers.' What three things do I tell them to put in a prompt to fix that, and why does an example file help so much?"
Resources · Best practices · Common workflows
Plan Mode
The single highest-leverage habit: make Claude think before it writes.
Press Shift+Tab to cycle into Plan Mode, where Claude reads and proposes an approach without editing. Why it matters: a feature has many decisions; if each is 80% right, all-correct odds are tiny — planning collapses them into one reviewed spec. Edit the plan before approving, and use the guard phrase "don't implement yet." Skip planning for a typo, a rename, or a one-liner.
Pick a task touching 2–3 files. Enter Plan Mode, ask for a detailed plan, deliberately tweak one step before approving, then let it implement and verify against the plan.
"What is Plan Mode, why does planning dramatically raise the odds of a good result on a big task, and how do I decide when a task is too small to bother?"
Resources · Best practices (planning)
Context management + CLAUDE.md & memory
Controlling what Claude knows — both the transient and the persistent.
Every turn re-sends the whole conversation: that bundle is the context window, and as it fills, Claude forgets early constraints and makes detail mistakes. Use /clear to reset and /compact to summarize; before clearing, write progress to a file (document-and-clear). For persistence, CLAUDE.md in your project root is read at the start of every session — generate a starter with /init, add commands, conventions, and checklists, keep it lean, and treat it as a living doc: every time Claude repeats a mistake, add a line. Commit it to Git.
Clutter a session, then have Claude write progress to notes.md and /clear. Next, run /init and hand-edit CLAUDE.md with your test command, one convention, and one "always X / never Y" rule. Start a fresh session and confirm it follows the rule unprompted.
"Why does a long session start making more mistakes, what's my routine for resetting without losing my place, and what belongs in CLAUDE.md (and what doesn't)?"
Resources · Memory & CLAUDE.md
Slash commands + the full Git feature loop
Run a complete feature end to end, streamlined with commands.
/help lists built-in commands (/clear, /compact, /init, /model, /mcp); custom slash commands save a reusable prompt so you stop re-typing scaffolding. Claude works directly with Git — staging, commit messages, branches, PRs. Chain it all: Plan Mode → implement → run tests and fix failures → review the diff yourself → commit. You are the reviewer; Claude is the author.
Implement one small real feature start to finish on a branch — plan, build, test, review the diff, commit (optionally open a PR). Then turn one prompt you typed more than once into a custom command.
"Walk me through shipping a feature from a fresh branch to a committed change — and where in that loop am I, the human, irreplaceable?"
Resources · CLI reference · Common workflows
Debugging & test-driven workflows
Make Claude prove its work runs — don't trust the explanation.
Paste an error message or describe the symptom; Claude traces it to a root cause and fixes it. For new behavior, work test-first: ask for a failing test, then implement until it passes, and have Claude run the suite and fix failures itself. The discipline: never accept "it should work" — make it actually run.
Introduce a bug in your sandbox and give Claude only the error message — let it find and fix it. Then ask it to write a failing test for a new behavior and make it pass.
"How do I debug with Claude from just an error message, and why do I make it run the tests instead of trusting its explanation?"
Resources · Common workflows (debug & test)
Consolidation mini-project
No new concept — chain every fundamental into real reps.
Today is practice, not theory. The goal is to run the whole fundamentals stack without prompting yourself: CLAUDE.md in place, Plan Mode, context discipline, the Git loop, and debugging — all in one continuous piece of work.
Pick a real (small) feature or refactor and take it end to end: branch → plan → implement → test/fix → review diff → commit/PR. Keep a running tasks/todo.md and update it as you go.
"Walk through my complete fundamentals workflow in order, and explain why each habit is there."
Resources · Best practices
Week 2 · Power User
One capability per day — automation, extensibility, and scale.
Skills
Package a repeatable workflow once; invoke it forever.
A Skill packages a repeatable workflow — often with attached scripts — that Claude can invoke (think /review-pr or /deploy-staging). The pattern: attach a script instead of documenting a long procedure in prose, and share it with your team so the recipe travels.
Take one multi-step routine you ran this week, build it into a Skill, invoke it, and confirm it behaves the same as your manual prompt.
"What's the difference between typing a long prompt and creating a Skill, and what kind of task is worth packaging up?"
Resources · Skills
Hooks
Mechanical quality gates that don't depend on Claude remembering.
Hooks run shell commands before or after Claude's actions (PreToolUse, PostToolUse) — e.g. auto-format after every edit, or run lint before a commit. They catch errors mechanically instead of relying on Claude to remember. A useful instinct: prefer checking the final result over blocking mid-plan.
Add a PostToolUse hook that auto-formats or lints after file edits. Make an edit and watch it fire.
"What are hooks for, how are they different from just asking Claude to 'remember to lint,' and when would I use one?"
Resources · Hooks
Settings & permissions
Tune how much Claude can do without asking — carefully.
settings.json is shared and committed; settings.local.json is gitignored, so you tune your machine without affecting teammates. Pre-approve safe, repetitive commands to cut prompt fatigue. The safety reality: Claude has real filesystem access, and auto-approving destructive commands is how people lose work — widen permissions deliberately, never lazily.
Open your settings, pre-approve one safe repetitive command you keep approving by hand, and guard a dangerous category. Verify the prompt behavior changes.
"What's the difference between settings.json and settings.local.json, and what's the danger of being too generous with auto-approved permissions?"
Resources · Settings
MCP — connecting external tools
Let Claude reach beyond the codebase into the tools your work lives in.
The Model Context Protocol connects Claude Code to external data and tools — design docs in Google Drive, tickets in Jira, messages in Slack, or your own custom tooling. Manage servers with /mcp and follow the MCP quickstart to connect one end to end. Keep the set minimal and purposeful — each server adds capability but also context cost and surface area.
Connect one safe, read-mostly MCP server (a docs or browser tool is ideal). Have Claude pull information from it and use that in a task inside your repo.
"What problem does MCP solve that CLAUDE.md and Skills don't, and give an example of a task that only becomes possible once a server is connected."
Resources · MCP overview · MCP quickstart
Subagents & agent teams
Split a big task across coordinated agents.
You can spawn multiple agents that work on different parts of a task simultaneously, with a lead agent assigning subtasks and merging results. It shines on large, parallelizable work — but keep each agent's context small and focused, and don't reach for it when a single session would do.
Take a task with genuinely independent parts (e.g. tests for two unrelated modules). Have a lead delegate to subagents, then review the merged result.
"When do subagents beat a single session, and what's the risk if I overuse them?"
Resources · Subagents
Parallel sessions + headless CLI
Run several streams at once, and script Claude from your shell.
Run multiple sessions in parallel, each in its own Git worktree so changes don't collide. For automation, claude -p "..." runs non-interactively so you can pipe and script: tail -200 app.log | claude -p "flag anomalies" or git diff main --name-only | claude -p "review these for security issues". This is also how Claude plugs into CI like GitHub Actions.
Create a Git worktree and run two sessions on different branches at once. Then write one useful claude -p one-liner you'd actually run from your shell.
"Why use worktrees for parallel work, and what's one real task I'd automate with claude -p?"
Resources · CLI reference
Capstone
Ship something real using the entire toolkit.
No new concept — assemble everything. A non-trivial feature, shipped with the full discipline: CLAUDE.md, Plan Mode, context management, a hook enforcing format/lint, optionally a Skill or an MCP server, your own diff review, and a clean commit + PR.
Take a real multi-step feature or refactor end to end with quality gates in place. Afterward, reflect: which habits saved you the most time?
"Teach my complete workflow for a non-trivial feature — every habit, in order, with reasons — then explain when I'd reach for subagents or parallel worktrees instead of one session."
Resources · Best practices · Anthropic engineering guide
Bookmark these
- Claude Code Docs — Overviewcode.claude.com/docs · the canonical source, updated frequently
- Quickstartyour first real task, start to finish
- Best practices (docs)planning, context, the four-phase workflow
- Anthropic Engineering — Best practices for agentic codinganthropic.com · the original patterns from the team
- Common workflowsrecipes for debugging, testing, and PRs
- CLI referenceevery command and flag, including
-pheadless mode - Troubleshootingfor when something behaves differently than this guide
You've reached "skilled" when…
- You plan before you build on anything non-trivial — and skip planning on trivial fixes without thinking about it.
- You manage context deliberately: clearing, compacting, and dumping progress to files instead of letting sessions rot.
- Your CLAUDE.md is a living document that gains a line every time Claude repeats a mistake.
- You always review the diff and never blind-approve destructive commands.
- You reach for Skills, hooks, MCP, and headless mode when they fit, instead of re-typing the same scaffolding.
If you can answer all fourteen teach-back questions cleanly to an imaginary beginner, you've genuinely internalized it.
No comments:
Post a Comment