Scenario: Code Generation with Claude Code

The full picture

A team uses Claude Code every day. They generate code, refactor, debug, and write docs. They set it up with CLAUDE.md, slash commands, hooks, and skills. The exam asks which part of that toolkit fits a problem. Two ideas decide most answers. First: a hook guarantees an action, a prompt only asks for one. Second: plan mode is for big or risky work, not for one-line fixes.

flowchart TD
    P[Your prompt] --> M{Big, risky or<br/>unfamiliar?}
    M -- Yes --> PM[Plan mode<br/>explore first]
    M -- No --> DE[Direct execution]
    PM --> DE
    DE --> ED[Claude edits files]
    ED --> HK[PostToolUse hook<br/>runs the formatter]
    CM[CLAUDE.md and .claude/rules/] -. context .-> P
    SK[Slash commands and skills] -. reusable steps .-> P
    PD[permissions.deny] -. blocks protected paths .-> ED

The cast: your Claude Code toolkit

Each dotted line in the diagram is one part of the setup. Here is what each part is for.

Hooks and permissions guarantee things

Start with the toolkit parts that never depend on Claude remembering. Code runs them.

• A hook always runs. A prompt only asks.
• Run Prettier on every file Claude edits.
• Use a PostToolUse hook.
• Set its matcher to Edit|Write.
• Protect the migrations folder with a permissions.deny rule for that path.
• Put the logging style preference in CLAUDE.md.
• Keep the formatting job in the hook.
• One exam question mixes all three. The answer uses all three.

Plan mode vs direct execution

Hooks decide what always happens. Plan mode decides how you start the work.

flowchart TD
    A{The change is…} -->|Small, clear, low risk| B[Direct execution]
    A -->|Unfamiliar code| C[Plan mode]
    A -->|Architecture / many files| C
    A -->|Needs approval| C

The exam tests both directions. Too little planning is wrong. Too much planning is also wrong.

Memory files: CLAUDE.md and rules

Plan mode sets the pace. Memory files set the standing rules Claude reads first.

• A CLAUDE.md can grow past 500 lines with mixed concerns.
• Split it into .claude/rules/ files.
• Give each file path-scoped frontmatter.
• Example: paths: ["terraform/**/*"].
• A monorepo needs different standards per package.
• Give each package its own CLAUDE.md.
• Use @imports to pull in the standards it needs.
• Then ask the check question: is my CLAUDE.md even loaded?
• Exam-era answer: /memory shows the memory files.
• Current docs: /context, then Memory files, shows what really loaded.

Reusable workflows: slash commands and skills

Memory files hold rules. Slash commands and skills hold steps you repeat.

• A team checklist should not live in one person's head.
• Make a slash command, like /review.
• Or make a skill at .claude/skills/<name>/SKILL.md.
• Commit it to git. Then the whole team gets it.

How to prompt for good code

The setup is done. Now the daily habits that the exam rewards.

• Claude should follow existing patterns. @-reference the example files in your prompt.
• A bug with null values. Give a failing test case with input and expected output. Ask for a fix.
• Requirements are vague. Ask Claude to interview you about them first.
• Several UI bugs at once. Fix one at a time. Fix, verify, next.
• A complex feature must be correct. Write tests first. Ask Claude to make them pass. Iterate.

What gets tested

Here is the whole lesson as a lookup table. Every row is an exam pattern.

Traps

Wrong answers repeat too. Learn these four.

• ❌ Plan mode for a one-line fix. It wastes time, and the exam tests this direction too.
• ❌ One giant CLAUDE.md holding every team's rules.
• ❌ Prompt instructions for things a hook can guarantee, like formatting or blocking paths.
• ❌ Restarting a session to "fix" behavior. A memory-file check explains it. Use /memory, or /context in current docs.

See also

• claude-code/claude-code.mdx

Recap

• The team uses Claude Code for code generation, refactoring, debugging, and docs.
• The setup parts are CLAUDE.md, slash commands, hooks, and skills.
• Auto-format with a PostToolUse hook. Matcher: Edit|Write.
• Block a protected path with a permissions.deny rule.
• Keep style preferences, like logging style, in CLAUDE.md.
• Never use a prompt for something a hook can guarantee.
• Direct execution fits small, clear, low-risk changes.
• Plan mode fits unfamiliar code, architecture work, many files, and approvals.
• Plan mode for a one-line fix is a trap.
• Split a 500+ line CLAUDE.md into .claude/rules/ files.
• Rule files use path-scoped frontmatter, like paths: ["terraform/**/*"].
• A monorepo uses one CLAUDE.md per package with @imports.
• Check loaded memory with /memory on the exam. Current docs use /context, then Memory files.
• Share a workflow as a slash command or a skill at .claude/skills/<name>/SKILL.md, committed to git.
• @-reference example files so Claude follows your patterns.
• Fix a null bug with a failing test case: input plus expected output.
• For vague requirements, ask Claude to interview you first.
• Fix several UI bugs one at a time: fix, verify, next.
• For a complex feature, write tests first and iterate until they pass.