The Claude Code First-Week Guide You Actually Need

7 primitives, 12 moves, and why less wiring beats more every time.

Monday, 9:14 a.m. | the first claude

Priya types claude into a fresh terminal and watches a cursor blink. She has two tabs open: the Anthropic quickstart, and a Reddit thread titled "I built 47 skills and now Claude ignores all of them." She closes the Reddit tab.

This is the part nobody writes about honestly. Claude Code installs in under a minute. It feels productive almost immediately. And then, somewhere around day three, you've got a .claude/ folder that looks like a teenager's bedroom: half-written skills, three subagents that do the same thing, a hook that fires twice, and a CLAUDE.md so long that the model has quietly stopped reading the bottom half of it.

The docs themselves admit this last one. If Claude keeps ignoring a rule, the file is probably too long and the rule is getting lost in the noise. [1] That sentence should be tattooed somewhere.

Here is the thesis of this piece, the one I wish someone had told Priya: Claude Code has a small number of primitives and a large number of ways to misuse them. Wiring it well is not about adding more. It is about knowing which lever does what, in which order, and when to leave a lever alone.

By Friday, Priya's setup will be tight. Seven primitives. Twelve ordered steps. A decision tree she can run in her head. We'll get there day by day.

Tuesday | the 7 primitives (and 2 you can ignore at first)

Priya makes coffee and decides to stop wiring things and start understanding them. She opens a notes file and writes the seven primitives down. Not what they are, but what they're for.

1. Memory (CLAUDE.md) — what Claude should believe is true about this repo before you say anything. Conventions, build commands, the "we use pnpm not npm" rule. [2]

2. Slash commands — verbs you reach for repeatedly. /init, /review, your own /ship-it. If you've typed the same instruction three times, it's a slash command.

3. Skills — packaged know-how. A folder with a SKILL.md and supporting files, loaded only when relevant. Skills are not commands. They're a domain Claude becomes fluent in. [3]

4. Subagents — a fresh context window with a different brief. Useful when you want a second opinion uncontaminated by the first, or when a subtask would otherwise blow your main context. [4]

5. Hooks — shell commands the harness runs at lifecycle moments. Not Claude. The harness. This is how you enforce formatting, gate dangerous tools, or fire a Slack ping when a run ends. [5]

6. MCP servers — Claude's hands in other systems. Notion, Figma, GitHub, your internal API. Tool-calling, standardized. [6]

7. Settings & permissions (settings.json) — the boring one. Model choice, allowlists, env vars. This is the file that decides whether npm test prompts you every single time.

There are technically two more: Plugins (bundles of the above) and Checkpoints (built-in undo). Useful, but you won't reach for them in week one. [7]

A way to hold these in your head: Memory tells Claude what's true. Skills tell it what it knows. Subagents give it more brains. MCP gives it more hands. Hooks give the harness reflexes. Slash commands give you shortcuts. Settings sets the rules of the room.

If you can name which primitive solves a problem before you start solving it, you've already beaten 80% of .claude/ folders in the wild.

The week, in twelve moves

Priya's week, compressed. Do them in this order. The order is not aesthetic; later steps depend on earlier ones.

Monday | get on the road

1. Install the CLI. Homebrew or the install script. Two minutes. [8]

2. Authenticate. Run claude, browser opens, done. Credentials stored locally.

3. Run /init in your repo. It reads the codebase and drafts a starter CLAUDE.md. Treat the output as a first pass, not the final file.

Tuesday | tell Claude what's true

1. Edit CLAUDE.md down, not up. The docs target under 200 lines. [2] Build commands, conventions, the three rules you actually care about. Rules buried at line 400 may as well not exist. [1]

2. Set permissions. In .claude/settings.json, allowlist the commands you trust (npm test, pnpm build, git status). This is the single highest-ROI step for daily friction. [9]

Wednesday | set the room

1. Pick the model and output style. Opus for hard reasoning, Sonnet for daily driving, Haiku for cheap loops. Output style ("Explanatory", "Concise") shapes voice without you re-prompting. [10]

2. Add env vars. DEBUG, API tokens, anything your hooks or MCP servers will need. Settings.json, not shell rc. Portable across machines.

Thursday | extend the reach

1. Wire MCP servers. Start with one. GitHub via gh, or Notion if your specs live there. Don't add five on day one; you won't use four of them. [6]

2. Author one skill. Pick the workflow you do most often (PR reviews, writing migrations, a specific debugging dance) and write a SKILL.md for it. One real skill beats ten speculative ones. [3]

3. Define a subagent only if you need a clean room. A reviewer that shouldn't see how the code got written. A researcher that shouldn't carry your debugging context. Otherwise, skip. [4]

Friday | give the harness reflexes

1. Configure hooks, sparingly. There are 29 lifecycle events available, from SessionStart to PreToolUse to PostCompact. [5] You probably need three: a PostToolUse formatter, a PreToolUse guard on destructive commands, and a Stop notification.

2. Statusline and observability. A custom statusline showing model + token burn keeps you honest. [11] OTel (OpenTelemetry) export, if your team cares about cost attribution, goes here too.

That's it. Twelve steps, one week, no skill graveyard.

The decision tree Priya now runs in her head

By Friday afternoon, Priya stops asking "should I build a skill for this?" and starts asking better questions. Here's the tree.

Is the thing I want a verb I keep typing? → Slash command. If you've prompted "review this PR for security issues" four times this week, that's a /security-review. Cheap, no context cost.

Is it a body of knowledge Claude needs to be fluent in, but only sometimes? → Skill. Skills load lazily when relevant, so you don't pay context tax when they're irrelevant. [3] Good fit: "how we write migrations," "how our billing domain works." Bad fit: a skill called general-helpfulness.

Do I need a clean room? → Subagent. Two real cases. First, a reviewer that shouldn't have watched the writer write the code, because reviewers contaminated by author context miss things. The Anthropic best-practices docs call this the writer/reviewer pattern, and it's the single highest-ROI subagent use. [12] Second, a research or migration task whose intermediate junk would blow your main context window.

Do I need Claude to touch a system outside the repo? → MCP server. GitHub, Notion, Figma, your internal API. If the answer is "Claude needs to query our staging Postgres," that's MCP, not a skill. [6]

Do I want something to happen automatically, every time, without Claude deciding? → Hook. This is the distinction people miss most. Hooks are harness behavior, not model behavior. "Format on PostToolUse." "Block rm -rf at PreToolUse." "Ping Slack on Stop." If the rule has to fire even when Claude forgets, it's a hook. [5]

Three use cases that earn their wiring:

1. Parallel writer/reviewer. One session writes the migration; a subagent in a fresh context reviews it without seeing the writing process. Catches the edge cases the author rationalized away. [12]

2. Headless CI runs. claude -p "fix the lint errors and open a PR" in a GitHub Action. Scales to dozens of repos, deterministic, auditable. This is where MCP + permissions + a tight CLAUDE.md compound. [13]

3. Worktree fan-out for big migrations. Loop claude -p across 2,000 files, each in its own git worktree so they don't collide. A week of grunt work, done overnight. [12]

The pattern across all three: the wiring is invisible at the moment of use. Priya doesn't think about hooks when she runs /review. She thinks about the review. That's the whole point.

Friday, 4:47 p.m. | what Priya kept

By end of week, Priya's .claude/ folder has seven files: a CLAUDE.md at 94 lines, one skill for PR reviews, one subagent brief for the security reviewer that shouldn't watch her write code, three hook scripts (formatter, rm -rf guard, Slack ping on stop), and a settings.json with the allowlist. That's it. She deleted the two experimental skills she wrote speculatively on Thursday morning, the hook that fired twice because she wrote it as two files instead of one script, and the extra MCP server she added "just in case." The deleted stuff took about forty minutes to build and ten seconds to remove. She doesn't miss any of it. The .claude/ folder she can now hold in her head on a Monday morning — and that, it turns out, was the whole point.

Three things that bite you if you don't know them

The primitives, the setup steps, and the decision tree cover the what and the when. These three cover the how — the non-obvious behaviors that aren't in the intro docs.

1. Hooks run in parallel, not in order. Matching hooks for the same event all fire simultaneously, and identical handlers are deduplicated automatically. [5] If you need step A before step B, don't write two hooks and hope. Chain them inside a single script. The harness will not sequence them for you.

2. The permission mode toggle exists. Shift+Tab cycles default → acceptEdits → plan mid-session without interrupting your flow. [14] New teammates routinely spend weeks not knowing this. Put it in your onboarding doc, at the top.

3. Statusline pays for itself in a week. A statusline showing current model and token burn keeps you honest about when you're accidentally running Opus on a one-line edit. [11] Cheapest behavioral intervention available.

The cheatsheet (print this, pin it)

Primitive → use it for

12 setup steps, in order

1. Install CLI

2. Authenticate

3. /init

4. Trim CLAUDE.md to <200 lines

5. Permissions allowlist

6. Model + output style

7. Env vars

8. One MCP server

9. One skill (extracted, not invented)

10. Subagent only if you need isolation

11. Hooks (chained inside one script if order matters)

12. Statusline + observability

Hook events worth knowing first (29 total [5])

• SessionStart — load context, print reminders

• UserPromptSubmit — inject standing instructions, redact secrets

• PreToolUse — gate destructive commands, require confirmation

• PostToolUse — auto-format, lint, run quick tests

• Stop — Slack ping, log token spend, save transcript

• PreCompact / PostCompact — preserve critical state across compaction

Three honest rules

1. Fewer, sharper primitives beat more, blurrier ones.

2. Extract skills, don't invent them.

3. Matching hooks for the same event run in parallel. [5] If you need ordering, chain inside one script.

References

All URLs verified live on 2026-05-24. Canonical host is code.claude.com (the older docs.claude.com/en/docs/claude-code/* URLs 301 to these).

1. Best practices for Claude Code — Anthropic. https://code.claude.com/docs/en/best-practices ("The over-specified CLAUDE.md" anti-pattern; "if your CLAUDE.md is too long, Claude ignores half of it because important rules get lost in the noise").

2. How Claude remembers your project (memory / CLAUDE.md). https://code.claude.com/docs/en/memory ("Size: target under 200 lines per CLAUDE.md file"; load order; auto memory).

3. Extend Claude with skills. https://code.claude.com/docs/en/skills (lazy loading; skill content lifecycle; disable-model-invocation).

4. Create custom subagents. https://code.claude.com/docs/en/sub-agents ("Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions").

5. Hooks reference. https://code.claude.com/docs/en/hooks (29 lifecycle events including SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, PreCompact, PostCompact, SessionEnd; "All matching hooks run in parallel, and identical handlers are deduplicated automatically").

6. Connect Claude Code to tools via MCP. https://code.claude.com/docs/en/mcp ("Claude Code can connect to hundreds of external tools and data sources through the Model Context Protocol").

7. Plugins and Checkpointing. https://code.claude.com/docs/en/plugins · https://code.claude.com/docs/en/checkpointing.

8. Quickstart / install. https://code.claude.com/docs/en/quickstart.

9. Permissions. https://code.claude.com/docs/en/permissions (allowlists; auto mode; sandboxing).

10. Settings. https://code.claude.com/docs/en/settings (model, output style, env).

11. Customize your status line. https://code.claude.com/docs/en/statusline ("monitor context window usage, costs, and git status").

12. Best practices — Run multiple Claude sessions / Fan out across files. https://code.claude.com/docs/en/best-practices (Writer/Reviewer pattern; worktree fan-out with claude -p).

13. Run Claude Code programmatically (headless / non-interactive). https://code.claude.com/docs/en/headless (claude -p; --bare mode for CI; --allowedTools).

14. Choose a permission mode. https://code.claude.com/docs/en/permission-modes ("press Shift+Tab to cycle default → acceptEdits → plan").