Anthropic publishes a working set of best practices for using Claude Code. The community has converged on it as the de facto playbook for agentic coding. The patterns in that doc are what we'll work through here, in curriculum voice, with one clarification up front: the patterns travel. The exact commands often don't.

What I mean: CLAUDE.md is a Claude Code thing, but OpenClaude reads it natively, Cursor uses .cursorrules for the same job, and Codex CLI uses AGENTS.md. Plan mode is a Claude Code feature, but the workflow underneath it (read the code, write a plan, then implement) works in any harness that lets you run a model in read-only mode before letting it write files. The discipline is what matters. The tool you apply it through is, for most working purposes, interchangeable.

OpenClaude is worth naming explicitly. It's an independent open-source project (https://github.com/Gitlawb/openclaude) that takes the Claude Code workflow patterns and adapts them to work with OpenAI, Gemini, DeepSeek, Codex, GitHub Models, Ollama, and 200+ other models via OpenAI-compatible APIs. Not affiliated with Anthropic. Same workflow shape, different model behind it. For readers running local models on a Mac mini or a Spark (Part 4), or readers who want to use a non-Anthropic provider for cost or privacy reasons, OpenClaude is the bridge that lets you keep the discipline this section teaches without changing your tools.

The playbook that follows is six categories of practice: setup that pays for itself, the four-phase loop, prompts that don't waste your turn, session management, scaling up, and the failure modes you will actually hit. If you read nothing else in Part 2, read this section.

2.6.1 THE SETUP THAT PAYS FOR ITSELF

[INTRO] The five minutes you spend configuring your environment correctly will save you hours per week for the rest of the project's life.

[BODY] There are five setup moves that compound. None of them are optional, and all of them pay back within the first session.

CLAUDE.md AT THE PROJECT ROOT. This is the file the agent reads on every session start. It's where you put the things the agent can't infer from the code: the bash commands you use to build and test (because nothing in the source tells the agent how to run your tests), the code style rules that differ from defaults, the testing instructions, the repo etiquette, and the architectural decisions that aren't visible in any single file.

What goes IN: bash commands the agent couldn't guess, code style that deviates from the language's defaults, the test runner you prefer, branch naming and PR conventions, environment quirks (the env vars you have to set, the version of Node you require), and the gotchas the agent would otherwise rediscover. What stays OUT: anything the agent can read from the code itself, standard language conventions, file-by-file descriptions of the codebase, long explanations, anything that changes frequently.

Bloat is the failure mode here. A 500-line CLAUDE.md is a CLAUDE.md the agent will start ignoring partway through. The test for whether a line belongs in the file: if you removed this rule, would the agent make a mistake it doesn't currently make? If yes, keep it. If no, cut it. Treat it like code: review it when something breaks, prune it regularly.

The cross-tool note: OpenClaude reads CLAUDE.md natively because it inherits the file format. Cursor uses .cursorrules. Codex CLI uses AGENTS.md. The shape of the content is the same regardless. Section 8.3 has the template; if you're using something other than Claude Code, copy the template into whatever filename your tool reads.

PERMISSIONS THAT DON'T DRIVE YOU INSANE. By default, an agent will ask permission for every file write, every bash command, every external API call. After the tenth approval you're not reviewing anymore, you're just clicking through, and the clicking-through habit is exactly when the agent does something you wish you'd actually read. Three options to fix this:

Auto mode: a separate classifier model reviews each command and only prompts you for the risky stuff. Best when you trust the general direction of a task.

Allowlists: explicitly permit specific commands you know are safe (npm run lint, git commit, pytest). The agent runs those without asking; everything else still prompts.

Sandboxing: OS-level isolation that restricts filesystem and network access. Most aggressive option; works well for unattended runs.

The Claude Code commands are --permission-mode auto, /permissions, and /sandbox. OpenClaude uses --allowedTools to scope what's permitted. Different syntax, same idea: stop being interrupted for the routine work, keep the prompts for the work that actually warrants them.

CLI TOOLS THE AGENT CAN ACTUALLY USE. The most context-efficient way to interact with external services is through their CLIs. Install gh for GitHub. Install aws for AWS. Install gcloud for Google Cloud. Install stripe for Stripe. The agent already knows how to use these; it'll reach for them automatically once they're available. Without them, the agent will fall back to API calls that often hit rate limits or require auth setup the agent has to figure out from scratch.

The agent is also good at learning CLIs it doesn't already know. Try a prompt like "use 'foo --help' to learn this tool, then use it to do X." This works for most well-documented CLIs.

MCP SERVERS FOR YOUR EXISTING SYSTEMS. MCP (Model Context Protocol) is how an agent talks to third-party services in a standardized way. Notion, Figma, Postgres, Slack, Sentry, and most major SaaS products now have MCP servers (official or community-built). Connect them once and the agent can read your issues, query your database, look up designs, post to channels, all without you copy-pasting between windows.

Claude Code adds MCP servers via claude mcp add. OpenClaude and Cursor both support MCP. The catalog grows weekly; check https://mcp.so for what exists.

SKILLS, HOOKS, AND SUBAGENTS. These are Claude Code-specific features with cross-tool conceptual equivalents. Skills (.claude/skills/) are reusable workflows the agent loads on demand: "fix-issue", "deploy", "review-pr". Hooks run scripts deterministically at specific points ("after every edit, run lint"). Subagents are isolated mini-sessions for investigation that don't pollute your main context. We'll come back to subagents in section 2.6.5 because they're a scaling pattern, not just a setup item.

2.6.2 THE FOUR-PHASE LOOP: EXPLORE, PLAN, IMPLEMENT, COMMIT

[INTRO] The single most consequential workflow change for vibe coders. Skip this phase structure and you'll iterate in circles. Use it and most of your sessions land in one pass.

[BODY] Most beginners do all four phases at once, in their head, while typing at the agent. The result is what 1.3 warned about: prompts that produce plausible-looking code that solves the wrong problem. The fix is to do the four phases in sequence, with the agent's role changing at each one.

PHASE 1: EXPLORE. The agent reads the code without changing it. You ask questions. You build a shared understanding of the codebase before any edits happen.

In Claude Code, this is plan mode (toggled with the keyboard shortcut or the /plan command). The agent has read access but no write access. You can ask "how does the auth system work in this project?" and the agent walks the code and tells you. In OpenClaude, you get the same effect by running with --allowedTools set to read-only operations (Read, Grep, Glob) and excluding the edit tools. In Cursor, you ask the agent to "explain before editing" and watch what it reads.

The discipline this phase enforces: separate "what is the code currently doing" from "what should I change." Most bad agent output comes from the agent guessing wrong about the existing code. Exploration before edits makes that guessing unnecessary.

PHASE 2: PLAN. Now that the agent has explored, ask it for a written plan. "Add Google OAuth. What files need to change? What's the session flow? Create a plan." The agent produces a plan you can read, edit, and revise before any code gets written.

This is the most consequential phase. The plan is your spec for this specific change. If the plan is wrong, the implementation will be wrong; correcting the plan is much cheaper than correcting the implementation. Read the plan critically. If something looks off, fix it before saying go.

In Claude Code, plan mode lets you press Ctrl+G to open the plan in your text editor for direct editing. Use this. A plan you've personally edited is a plan the agent will follow more reliably than a plan you just nodded at on screen.

PHASE 3: IMPLEMENT. Switch out of plan mode. The agent executes against the plan: writes code, runs tests, fixes lint issues, addresses the verification criteria you specified. You watch and course-correct if something's going off track. You don't have to type much during this phase; if the plan was good, the implementation mostly runs itself.

The verification work happens here. If your spec said "tests must pass before this is done," the agent runs the tests and reports back. If your spec referenced a screenshot, the agent compares the screenshot. If your spec said "the build must succeed," the agent runs the build. Your role is to confirm the verification actually happened and to read the diff before approving it.

PHASE 4: COMMIT. Once the implementation is verified, commit with a descriptive message and (if the project uses PRs) open a pull request. Most agents will write the commit message for you; review it for accuracy and edit the parts that don't match what actually changed.

The four-phase loop is overkill for trivial changes. If the diff fits in one sentence, skip planning. Adding a log line, renaming a variable, fixing a typo: those are direct-execute tasks. The loop is for changes where you're uncertain about the approach, the change touches multiple files, or you're unfamiliar with the code being modified.

The rule: plan when you would otherwise rewrite the code three times. Direct-execute when you know exactly what the diff looks like.

2.6.3 PROMPTS THAT DON'T WASTE YOUR TURN

[INTRO] The most common prompt failure isn't that the agent didn't understand. It's that you didn't tell it enough to understand correctly.

[BODY] Anthropic's doc lists four prompt patterns that compound. Each one looks small. Each one cuts iteration count by half on the kind of work most readers will do.

SCOPE THE TASK. Vague prompts get vague output. Specific prompts get specific output.

BAD: "add tests for foo.py" GOOD: "write a test for foo.py covering the edge case where the user is logged out. avoid mocks. run the tests after writing them."

The good version names three things the bad version doesn't: which file, what scenario, and what testing style. Three sentences worth of context that turn a 30% chance of useful output into a 90% chance.

POINT TO SOURCES. When the answer is in your project's history or documentation, tell the agent where to look.

BAD: "why does ExecutionFactory have such a weird API?" GOOD: "look through ExecutionFactory's git history and summarize how its API came to be."

The agent answers the second prompt by actually reading the history. The agent answers the first prompt by hallucinating a story about your code. The difference is one sentence.

REFERENCE EXISTING PATTERNS. Your codebase has conventions. If you want new code to match them, point at the file that already does it.

BAD: "add a calendar widget" GOOD: "look at how widgets are implemented on the home page, especially HotDogWidget.php as a pattern. follow the same structure for a calendar widget that lets the user pick a month and paginate forwards/backwards through years."

The agent reads HotDogWidget.php, learns the pattern, applies it. The new code looks like it belongs. No "I'll restructure it later" todo list.

DESCRIBE THE SYMPTOM. When something is broken, give the agent the full picture: what's wrong, where to look, what 'fixed' means.

BAD: "fix the login bug" GOOD: "users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it."

The good version gives the agent a reproducible failure to fix. The bad version gives the agent a license to guess.

A separate move that fits in this section because it's prompt-shaped: the AskUserQuestion interview pattern. For a feature you haven't fully specified yet, instead of writing a long prompt, write a short one that makes the agent interview you:

"I want to build a customer scheduling agent for a small services business. Interview me using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, and tradeoffs. Don't ask obvious questions; dig into the hard parts. Keep going until we've covered everything, then write a complete spec to SPEC.md."

The agent asks questions you wouldn't have thought to ask. You answer. You end up with a spec written collaboratively that's tighter than what you would have produced alone. Then you start a fresh session pointed at SPEC.md and execute. This is the single most-improving prompt move in the playbook.

ON RICH CONTENT: don't just describe; show. The @ syntax in Claude Code (and OpenClaude, and Cursor) lets you reference a file directly: the agent reads it before responding. Paste screenshots into the prompt window: the agent sees them. Pipe data in with cat error.log | claude: the agent reads the log. URLs work for documentation references.

The rule: anything you can show the agent instead of describing, show. Description is lossy. Showing is not.

2.6.4 SESSION MANAGEMENT: CLEAR, COMPACT, REWIND, RESUME

[INTRO] Conversations with an agent are persistent and reversible. Use both properties.

[BODY] The fundamental constraint of agentic work is the context window. Every file the agent reads, every command output, every message you've sent, all of it sits in the context window taking up space. When the window fills up, the agent's performance degrades: it forgets earlier instructions, makes more mistakes, repeats things you've already clarified.

Managing the context window is the difference between sessions that get better as they go and sessions that get worse. Four moves.

CLEAR BETWEEN UNRELATED TASKS. The single most important habit. When you switch from "build the login page" to "fix a bug in the inventory report," start a new session. Don't let the agent's memory of the login work bleed into the inventory work.

In Claude Code, the command is /clear. In OpenClaude, the same. In Cursor, "New Chat." The reflex is: when the next thing you ask is unrelated to the last thing you finished, clear first.

COMPACT WHEN YOU NEED TO STAY ON THE SAME TASK. Sometimes you've been working on one feature for an hour and the context is bloated with debugging detours, but you don't want to lose the actual work. Compact the conversation: the agent summarizes what's important and drops what isn't.

The Claude Code command is /compact <instructions> where the instructions tell the agent what to preserve: "/compact Focus on the API changes" or "/compact Keep the file list and the test results, drop the debugging exploration."

REWIND WHEN SOMETHING WENT WRONG. Every action the agent takes creates a checkpoint. You can restore the conversation, the code, or both to any previous checkpoint. Press Esc twice (or run /rewind) to open the rewind menu.

The strategic implication: you can tell the agent to try something risky. If it works, great. If it doesn't, rewind and try a different approach. This changes how you work; instead of carefully planning every move, you can probe and revert.

Checkpoints only track changes made by the agent, not external processes. Rewind isn't a replacement for git; it's a faster, more granular layer that sits on top of git.

RESUME ACROSS SITTINGS. When a task spans multiple sessions, you don't have to re-explain the context. claude --continue picks up the most recent session. claude --resume lets you choose from a list. Name sessions when you start them ("oauth-migration", "inventory-fix") so you can find them later.

Treat sessions like git branches: each meaningful workstream gets its own persistent context, named for what it's doing. The mental model is similar; the operational mechanics are simpler because there's no merge step. Sessions don't interact with each other unless you explicitly share files between them.

THE TWO-CORRECTION RULE. If you've corrected the agent twice on the same issue in one session, the context is polluted with failed approaches. The agent is now reading "the user wants X" and "actually not X" and "wait, here's why X is wrong" and trying to satisfy all three. The fix isn't a third correction. The fix is /clear and a new prompt that incorporates what you learned.

A clean session with a better prompt almost always outperforms a long session with accumulated corrections. This is unintuitive (you spent all this time getting the agent up to speed, why would you throw it away?) and reliably correct.

2.6.5 SCALING UP: SUBAGENTS, PARALLEL SESSIONS, FAN-OUT

[INTRO] Once you're effective with one agent in one session, the next move is multiplication. Most readers won't need this on day one. Some readers will need it on day thirty.

[BODY] The patterns in this sub-section assume you've already got the basics locked in. They're tools for taking a workflow that works at one-person scale and running it at multi-person or multi-task scale.

SUBAGENTS FOR INVESTIGATION. The most common reason your main session fills up is that the agent had to read 40 files to answer one question. Subagents fix this. You delegate the investigation to a separate agent-in-a-separate-context, and only the summary comes back to your main conversation.

"Use a subagent to investigate how our authentication system handles token refresh, and whether we have any existing OAuth utilities I should reuse."

The subagent runs, reads what it needs, writes you a summary, exits. Your main context has the summary, not the 40 files. This is a context- efficient research move that you'll reach for repeatedly once you've done it once.

Subagents can also be used for verification: after an implementation, ask "use a subagent to review this code for edge cases." A fresh-context agent reading code it didn't write produces better review feedback than the agent that just wrote it; the writing agent is biased toward its own work.

WRITER/REVIEWER PATTERN. The verification idea generalized. Two sessions, two roles, two contexts.

Session A (Writer): "Implement a rate limiter for our API endpoints." Session B (Reviewer, fresh context): "Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns." Session A: "Here's the review feedback: [paste B's output]. Address these issues."

The reviewer doesn't know how the writer thought about the problem, which is exactly what makes the review useful. You can do the same with tests: one session writes the tests, another writes the implementation. Each session is more honest about its work because neither is trying to defend the other's choices.

PARALLEL SESSIONS. For genuinely independent workstreams, run multiple sessions in parallel. Worktrees (separate git checkouts) let you isolate the changes so they don't collide. The Claude Code desktop app and the web version both support parallel sessions visually. OpenClaude runs parallel just fine via separate terminal windows.

The payoff: you can have one session refactoring a backend module while another builds the frontend that consumes it, both moving simultaneously instead of sequentially. The catch: you have to merge their work yourself (or ask a third session to do the merge).

NON-INTERACTIVE MODE FOR AUTOMATION. claude -p "prompt" runs the agent without an interactive session, returns the output, exits. This is how you put an agent in a CI pipeline, a pre-commit hook, or a scheduled script.

One-off query

claude -p "Explain what this project does"

Structured output for scripts

claude -p "List all API endpoints" --output-format json

Streaming for real-time processing

claude -p "Analyze this log file" --output-format stream-json

OpenClaude supports the same flag with the same syntax. Non-interactive mode is the foundation for the next pattern.

FAN-OUT ACROSS FILES. For migrations, large analyses, or anything where you're applying the same operation to many files, write a script that loops through and calls claude -p for each.

for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from React to Vue. Return OK or FAIL."
--allowedTools "Edit,Bash(git commit *)" done

The --allowedTools flag scopes permissions tight, which matters when the script is running unattended. Test on three files, refine the prompt based on what went wrong, then run on the full set.

This is the pattern that turns a five-day refactor into a 90-minute script run. Most curriculum readers won't write fan-out scripts in their first month. Some will, by month three, write nothing else.

AUTO MODE FOR UNATTENDED RUNS. When you want the agent to keep going without prompting you for permission, but you still want safety checks:

claude --permission-mode auto -p "fix all lint errors"

A classifier model reviews each command and only blocks the risky stuff (scope escalation, unknown infrastructure, hostile-content-driven actions). You get autonomy without the worst-case behaviors. For unattended runs the classifier is the safety net; in interactive use auto mode is the convenience layer.

2.6.6 THE FIVE FAILURE MODES YOU WILL ACTUALLY HIT

[INTRO] These aren't hypothetical. Every reader of this curriculum will hit at least three of them in their first month. The fix in each case is the same shape: stop, recognize the pattern, reset.

[BODY] THE KITCHEN-SINK SESSION. You start with one task. You ask the agent something unrelated halfway through. You go back to the first task. The context is now full of irrelevant information about the side question, and the agent is splitting attention between two threads.

Symptom: the agent starts confusing details from the two tasks, or asking questions that were already answered, or producing code that references files from the wrong workstream.

Fix: /clear between unrelated tasks. Set up a new session for the side question. Don't reuse the same chat for genuinely different problems.

CORRECTING OVER AND OVER. The agent does something wrong. You correct. It does it slightly differently wrong. You correct again. Three rounds in, the context is polluted with failed approaches and the agent is trying to satisfy contradictory instructions.

Symptom: the agent's third attempt looks like a frankenstein of the first two attempts and your three corrections, instead of a clean solution.

Fix: after two failed corrections, /clear and write a better initial prompt. Incorporate what you learned from the failed attempts into the new prompt. A clean session with a better prompt beats three rounds of correction every time.

THE OVER-SPECIFIED CLAUDE.MD. Your CLAUDE.md is 600 lines long. The agent ignores half of it because the rules you actually need are buried in a wall of "be sure to write clean code" and "always test your changes."

Symptom: the agent keeps doing things you have a rule against, or asks you questions that are answered in the file.

Fix: ruthlessly prune. For every line, ask: "would removing this cause the agent to make a mistake it doesn't currently make?" If no, delete it. Convert non-negotiable rules into hooks (deterministic scripts) instead of CLAUDE.md instructions (advisory text). Section 8.3's template is on the small side on purpose.

THE TRUST-THEN-VERIFY GAP. The agent produces a plausible-looking implementation. The tests pass (because the agent wrote the tests, and the tests don't actually exercise the failure cases). The output looks correct. You ship it. A week later it breaks in a way that was predictable.

Symptom: confident-looking code that's wrong on edge cases. Tests that pass but don't test what you actually care about. Subtle bugs that surface in production.

Fix: provide verification the agent didn't write. Tests YOU wrote before the implementation. Screenshots from the existing system. A failing test that reproduces the bug before the fix. If you can't verify the work without trusting the agent's claims about its own work, don't ship it. The verification habit (section 6.3) is the load-bearing discipline here. This is also where AFD code (section 1.4) most often gets shipped broken; the failure modes overlap.

THE INFINITE EXPLORATION. You ask the agent to "investigate" something without scoping it. The agent reads 50 files. Your context is full. Every subsequent question is now expensive and the agent's responses are degraded.

Symptom: a single innocuous question that ate your whole session. The agent reading files you didn't expect it to read. Long reports full of detail you didn't want.

Fix: scope investigations narrowly ("read just src/auth/ and tell me how token refresh works"), or use a subagent so the exploration happens in a separate context. Never let an unscoped "investigate this" prompt into your main session if you can avoid it.

These five failure modes account for most of the bad sessions you'll have. Recognizing them early is most of the cure. None of them mean you're doing this wrong; they mean you're doing this for real.

================================================================================ PART 3 — TOOLS OF THE TRADE