claude-code-ultimate-guide/quiz/questions/09-advanced-patterns.yaml

category: "Advanced Patterns"
category_id: 9
source_file: "guide/ultimate-guide.md"

questions:
  - id: "09-001"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What are the three components of 'The Trinity' pattern?"
    options:
      a: "Git, VSCode, Terminal"
      b: "Plan Mode, Extended Thinking, Sequential Thinking"
      c: "Serena, Context7, Playwright"
      d: "Agent, Skill, Command"
    correct: "b"
    explanation: |
      The Trinity is the most powerful Claude Code pattern combining:

      1. **Plan Mode** - Safe exploration without changes
      2. **Extended Thinking** - Deep analysis (enabled by default in Opus 4.5)
      3. **Sequential Thinking (MCP)** - Structured multi-step reasoning

      Combined, these provide maximum understanding before taking action.
      Use for architecture decisions, complex debugging, and legacy modernization.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.1 The Trinity"
      anchor: "#91-the-trinity"

  - id: "09-002"
    difficulty: "power"
    profiles: ["power"]
    question: "How do you toggle thinking mode in Claude Code (Opus 4.5+)?"
    options:
      a: "Use 'ultrathink' keyword in your prompt"
      b: "Alt+T (or Option+T on macOS)"
      c: "--think CLI flag"
      d: "/thinking command"
    correct: "b"
    explanation: |
      With Opus 4.5 (v2.0.67+), thinking mode is enabled by default at maximum budget.

      **Controlling Thinking Mode:**
      | Method | Action | Persistence |
      |--------|--------|-------------|
      | **Alt+T** | Toggle on/off | Session |
      | **/config** | Enable/disable globally | Permanent |

      **Note**: Keywords like "ultrathink" are now cosmetic only - they no longer control thinking behavior.

      Use Alt+T to disable thinking for simple tasks (faster, cheaper).
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.1 Extended Thinking"
      anchor: "#extended-thinking-opus-45"

  - id: "09-003"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What CLI flag runs Claude Code without interactive prompts for CI/CD?"
    options:
      a: "--ci"
      b: "--headless"
      c: "--batch"
      d: "--automated"
    correct: "b"
    explanation: |
      The `--headless` flag runs Claude Code without interactive prompts:

      ```bash
      # Basic headless execution
      claude --headless "Run the tests and report results"

      # With timeout
      claude --headless --timeout 300 "Build the project"
      ```

      Essential for CI/CD integration, automated pipelines, and scripted workflows.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.3 CI/CD Integration"
      anchor: "#headless-mode"

  - id: "09-004"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "How do you pipe content to Claude Code with a prompt?"
    options:
      a: "claude | cat file.txt -p 'analyze'"
      b: "cat file.txt | claude -p 'analyze this code'"
      c: "claude < file.txt --prompt 'analyze'"
      d: "file.txt > claude -p 'analyze'"
    correct: "b"
    explanation: |
      Use standard Unix piping with the `-p` flag:

      ```bash
      cat file.txt | claude -p 'analyze this code'
      git diff | claude -p 'explain these changes'
      npm test 2>&1 | claude -p 'summarize test failures'
      ```

      This enables powerful shell integration for automated code analysis.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.3 CI/CD Integration"
      anchor: "#unix-piping-workflows"

  - id: "09-005"
    difficulty: "power"
    profiles: ["power"]
    question: "What is the 'Rev the Engine' pattern?"
    options:
      a: "Running tests in parallel"
      b: "Multiple rounds of write-critique-improve cycles"
      c: "Restarting Claude Code between tasks"
      d: "Using higher compute models"
    correct: "b"
    explanation: |
      The "Rev the Engine" pattern uses multiple rounds of critique for quality:

      ```
      Round 1: [Initial implementation]
      Critique: [What's wrong]
      Improvement: [Better version]

      Round 2: [Improved implementation]
      Critique: [What's still wrong]
      Improvement: [Even better version]

      Round 3: [Final implementation]
      Final check: [Verification]
      ```

      Typically 3 rounds are recommended for quality work.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.2 Composition Patterns"
      anchor: "#the-rev-the-engine-pattern"

  - id: "09-006"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What output format flag gets structured JSON from Claude for scripting?"
    options:
      a: "--format json"
      b: "--output-format json"
      c: "--json"
      d: "--structured"
    correct: "b"
    explanation: |
      Use `--output-format` to control response format:

      | Format | Use Case |
      |--------|----------|
      | `text` | Human-readable output (default) |
      | `json` | Machine-parseable structured data |
      | `stream-json` | Real-time streaming for large outputs |

      Example:
      ```bash
      git log --oneline -10 | claude -p 'Categorize commits' --output-format json
      ```
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.3 CI/CD Integration"
      anchor: "#output-format-control"

  - id: "09-007"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is 'Vibe Coding' according to the guide?"
    options:
      a: "Coding while listening to music"
      b: "Rapid prototyping through natural conversation before committing to implementation"
      c: "Using AI to generate random code"
      d: "Coding in a relaxed environment"
    correct: "b"
    explanation: |
      Vibe Coding is rapid prototyping through natural conversation.

      When to vibe code:
      - Early exploration: Testing if an approach works
      - Proof of concept: Quick validation before full implementation
      - Learning: Understanding a new library or pattern

      Rules:
      - No production code - exploration only
      - Throw away freely
      - Focus on learning
      - Signal clearly: "This is vibe code, not for production"
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.8 Vibe Coding & Skeleton Projects"
      anchor: "#vibe-coding"

  - id: "09-008"
    difficulty: "power"
    profiles: ["power"]
    question: "What is the Verify Gate Pattern before creating a PR?"
    options:
      a: "Just run tests"
      b: "Build -> Lint -> Test -> Type-check -> THEN create PR"
      c: "Create PR first, then fix issues"
      d: "Manual review only"
    correct: "b"
    explanation: |
      The Verify Gate Pattern ensures all checks pass before PR creation:

      ```
      Build -> Lint -> Test -> Type-check -> THEN create PR
      ```

      If ANY step fails:
      - Stop immediately
      - Report what failed and why
      - Suggest fixes
      - Do NOT proceed to PR creation

      This prevents wasted CI cycles and review time.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.3 CI/CD Integration"
      anchor: "#verify-gate-pattern"

  - id: "09-009"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is the key insight of 'Todo as Instruction Mirrors'?"
    options:
      a: "Todos are just for tracking"
      b: "What you write as a todo becomes Claude's instruction"
      c: "Todos should be vague for flexibility"
      d: "Always use bullet points"
    correct: "b"
    explanation: |
      The Mirror Principle: What you write as a todo becomes Claude's instruction.

      Bad (vague todo -> vague execution):
      "Fix the bug"

      Good (specific todo -> precise execution):
      "Fix null pointer in getUserById when user not found - return null instead of throwing"

      Well-crafted todos guide Claude's execution with precision.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.6 Todo as Instruction Mirrors"
      anchor: "#the-mirror-principle"

  - id: "09-010"
    difficulty: "power"
    profiles: ["power"]
    question: "According to 'Continuous Improvement Mindset', what should you ask after every manual intervention?"
    options:
      a: "Was this my fault?"
      b: "How can I improve the process so this error can be avoided next time?"
      c: "Who is responsible for this?"
      d: "Should I use a different AI?"
    correct: "b"
    explanation: |
      After every manual intervention, ask:
      "How can I improve the process so this error or manual fix can be avoided next time?"

      The improvement pipeline:
      1. Can a linting rule catch it? -> Add lint rule
      2. Can it go in conventions/docs? -> Add to CLAUDE.md or ADRs
      3. Neither? -> Accept as edge case

      The meta-skill: instead of fixing code, fix the system that produces the code.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.10 Continuous Improvement Mindset"
      anchor: "#the-key-question"

  - id: "09-011"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is a Skeleton Project?"
    options:
      a: "A project with no code"
      b: "A minimal, working template that establishes patterns before full implementation"
      c: "A deprecated project"
      d: "A project outline document"
    correct: "b"
    explanation: |
      A skeleton project is a minimal, working template that establishes patterns.

      Skeleton principles:
      1. **It must run**: `pnpm dev` works from day 1
      2. **One complete vertical**: Full stack for one feature
      3. **Patterns, not features**: Shows HOW, not WHAT
      4. **Minimal dependencies**: Only what's needed

      Progression: Skeleton (Day 1) -> MVP (Week 1) -> Full (Month 1)
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.8 Vibe Coding & Skeleton Projects"
      anchor: "#skeleton-projects"

  - id: "09-012"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is OpusPlan mode?"
    options:
      a: "Using only Opus for everything"
      b: "Opus for planning, Sonnet for execution"
      c: "A special debugging mode"
      d: "Planning without AI"
    correct: "b"
    explanation: |
      OpusPlan mode combines model strengths:
      - **Planning**: Opus for high-level thinking
      - **Execution**: Sonnet for implementation

      This provides strategic thinking + cost-effective execution.

      ```bash
      /model opusplan
      Shift+Tab x 2  # Enter Plan Mode (Opus)
      # Design architecture...
      Shift+Tab      # Exit Plan Mode (Sonnet)
      # Implement the plan...
      ```
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.13 Cost Optimization Strategies"
      anchor: "#model-selection-matrix"

  - id: "09-013"
    difficulty: "power"
    profiles: ["power"]
    question: "When should you NOT use --dangerously-skip-permissions?"
    options:
      a: "In CI/CD pipelines"
      b: "On production systems or sensitive codebases"
      c: "For automated testing"
      d: "In Docker containers"
    correct: "b"
    explanation: |
      Never use `--dangerously-skip-permissions` on production systems or sensitive codebases.

      Safe usage:
      - CI/CD pipelines with isolated environments
      - Automated testing with limited scope
      - Development containers

      Unsafe usage:
      - Production systems
      - Codebases with secrets
      - Environments with sensitive data

      The flag bypasses all permission prompts, creating security risks.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.11 Common Pitfalls & Best Practices"
      anchor: "#security-pitfalls"

  - id: "09-014"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What prompt format does the guide recommend for effective requests?"
    options:
      a: "Simple natural language"
      b: "WHAT, WHERE, HOW, VERIFY"
      c: "Subject, Body, Footer"
      d: "Title, Description, Acceptance Criteria"
    correct: "b"
    explanation: |
      The recommended prompt format:

      - **WHAT**: Concrete deliverable
      - **WHERE**: File paths/locations
      - **HOW**: Constraints/approach
      - **VERIFY**: Success criteria

      Example:
      ```
      WHAT: Add input validation to the login form
      WHERE: src/components/LoginForm.tsx, src/schemas/auth.ts
      HOW: Use Zod schema validation, display errors inline
      VERIFY: Empty email shows error, invalid format shows error
      ```
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.11 Common Pitfalls & Best Practices"
      anchor: "#effective-prompt-format"

  - id: "09-015"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is the recommended learning progression for Claude Code?"
    options:
      a: "Learn everything at once"
      b: "Start with advanced features"
      c: "Week 1: Basic commands -> Week 2: CLAUDE.md -> Week 3: Agents -> Month 2+: MCP servers"
      d: "Skip to MCP servers immediately"
    correct: "c"
    explanation: |
      The guide recommends progressive learning:

      1. **Week 1**: Basic commands, context management
      2. **Week 2**: CLAUDE.md, permissions
      3. **Week 3**: Agents and commands
      4. **Month 2+**: MCP servers, advanced patterns

      Start with simple, low-risk tasks and build up complexity gradually.
      This avoids overwhelm and builds solid fundamentals.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.11 Common Pitfalls & Best Practices"
      anchor: "#learning--adoption-pitfalls"

  - id: "09-016"
    difficulty: "power"
    profiles: ["power"]
    question: "What git workflow enables working on multiple features simultaneously with isolated contexts?"
    options:
      a: "Git stash"
      b: "Git worktrees"
      c: "Git branches only"
      d: "Git submodules"
    correct: "b"
    explanation: |
      Git worktrees create multiple working directories from the same repository.

      Benefits:
      - Work on multiple features simultaneously
      - Each worktree has independent Claude Code context
      - No need for stash/switch operations
      - Parallel testing while developing

      ```bash
      git worktree add ../myproject-hotfix hotfix
      git worktree add ../myproject-feature-a feature-a
      ```
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "9.12 Git Best Practices & Workflows"
      anchor: "#git-worktrees-for-parallel-development"

  - id: "09-017"
    difficulty: "intermediate"
    profiles: ["senior", "power"]
    question: "What is SDD (Spec-Driven Development) and its key claim?"
    options:
      a: "Speed-based Development - fastest approach"
      b: "Spec-Driven Development - one well-structured iteration equals 8 unstructured ones"
      c: "Standard Driven Development - follows industry standards"
      d: "Sequential Driven Development - linear workflow"
    correct: "b"
    explanation: |
      SDD (Spec-Driven Development) means specifications BEFORE code. The key claim: one well-structured iteration equals 8 unstructured ones. CLAUDE.md IS your spec file. Best for APIs and contracts. High Claude fit (⭐⭐⭐).
    doc_reference:
      file: "guide/methodologies.md"
      section: "Tier 2: Specification & Architecture"
      anchor: "#tier-2-specification--architecture"

  - id: "09-018"
    difficulty: "intermediate"
    profiles: ["senior", "power"]
    question: "What format does BDD (Behavior-Driven Development) use for test scenarios?"
    options:
      a: "Arrange-Act-Assert"
      b: "Given-When-Then (Gherkin)"
      c: "Setup-Execute-Verify"
      d: "Input-Process-Output"
    correct: "b"
    explanation: |
      BDD uses Given-When-Then format (Gherkin). BDD is beyond testing - it's a collaboration process: (1) Discovery with devs/business, (2) Formulation with examples, (3) Automation via Cucumber. Example: Given product with 0 stock → When customer attempts purchase → Then system refuses.
    doc_reference:
      file: "guide/methodologies.md"
      section: "Tier 3: Behavior & Acceptance"
      anchor: "#tier-3-behavior--acceptance"

  - id: "09-019"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What are the three steps of the TDD cycle?"
    options:
      a: "Plan-Develop-Test"
      b: "Red-Green-Refactor"
      c: "Write-Run-Fix"
      d: "Design-Code-Review"
    correct: "b"
    explanation: |
      The classic TDD cycle: (1) Red - write failing test, (2) Green - minimal code to pass, (3) Refactor - clean up while tests stay green. With Claude: be explicit "Write FAILING tests that don't exist yet." TDD is a core workflow (⭐⭐⭐).
    doc_reference:
      file: "guide/methodologies.md"
      section: "Tier 5: Implementation"
      anchor: "#tier-5-implementation"

  - id: "09-020"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "How many development methodologies are documented in the methodologies reference?"
    options:
      a: "5 methodologies"
      b: "10 methodologies"
      c: "15 methodologies"
      d: "20 methodologies"
    correct: "c"
    explanation: |
      15 methodologies organized in a 6-tier pyramid: Tier 1 (Strategic - BMAD), Tier 2 (Specification - SDD, Doc-Driven, Req-Driven, DDD), Tier 3 (Behavior - BDD, ATDD, CDD), Tier 4 (Feature - FDD, Context Engineering), Tier 5 (Implementation - TDD, Eval-Driven, Multi-Agent), Tier 6 (Optimization).
    doc_reference:
      file: "guide/methodologies.md"
      section: "The 15 Methodologies"
      anchor: "#the-15-methodologies"

  - id: "09-021"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is 'Context Engineering' as a methodology?"
    options:
      a: "Engineering team context"
      b: "Treating context as first-class design element: progressive disclosure, memory management, dynamic refresh"
      c: "Building context menus"
      d: "Managing environment variables"
    correct: "b"
    explanation: |
      Context Engineering treats context as a design element. Key concepts: Progressive Disclosure (let agent discover incrementally), Memory Management (conversation vs persistent memory), Dynamic Refresh (rewrite TODO list before response). High Claude fit (⭐⭐⭐) for long sessions.
    doc_reference:
      file: "guide/methodologies.md"
      section: "Tier 4: Feature Delivery"
      anchor: "#tier-4-feature-delivery"

  - id: "09-022"
    difficulty: "power"
    profiles: ["power"]
    question: "What are the 5 layers of 'Mechanic Stacking'?"
    options:
      a: "Plan Mode, Extended Thinking, Rev the Engine, Split-Role, Permutation"
      b: "Plan Mode, Sequential Thinking, Context7, Serena, Playwright"
      c: "CLAUDE.md, Plan Mode, Extended Thinking, MCP Servers, Hooks"
      d: "Plan Mode, Extended Thinking, Rev the Engine, Multi-Agent, Hooks"
    correct: "a"
    explanation: |
      Mechanic Stacking layers 5 techniques for maximum Claude Code power:

      1. **Plan Mode** - Safe exploration without changes
      2. **Extended Thinking** - Deep internal reasoning
      3. **Rev the Engine** - Progressive warm-up prompts
      4. **Split-Role** - Separate architect/implementer/reviewer
      5. **Permutation** - Systematic variation testing

      Each layer compounds the previous one's effectiveness.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Mechanic Stacking"
      anchor: "#mechanic-stacking"

  - id: "09-023"
    difficulty: "power"
    profiles: ["power"]
    question: "What is a 'Permutation Framework' in Claude Code?"
    options:
      a: "A/B testing of UI variants"
      b: "CLAUDE.md-driven systematic variation testing: define dimensions, generate variants, implement, evaluate"
      c: "Random code generation for benchmarks"
      d: "Automated regression test suite"
    correct: "b"
    explanation: |
      A Permutation Framework uses CLAUDE.md to drive systematic variation testing. The workflow: define variation dimensions (e.g., algorithm choice, data structure, caching strategy), generate all combinations, implement each variant, evaluate with metrics. This ensures you explore the solution space methodically rather than picking the first approach.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Permutation Frameworks"
      anchor: "#permutation-frameworks"

  - id: "09-024"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What mental model describes the developer as an orchestrator of Claude instances?"
    options:
      a: "Pipeline Manager"
      b: "Agent Supervisor"
      c: "You Are the Main Thread - CPU scheduler analogy where developer dispatches tasks to agents"
      d: "Task Router"
    correct: "c"
    explanation: |
      "You Are the Main Thread" uses the CPU scheduler analogy: the developer is the main thread dispatching work to Claude instances (worker threads). You manage priorities, context switches, and synchronization. Key insight: you don't write code - you manage the agents that write code. This shifts the skill from coding to orchestration.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "You Are the Main Thread"
      anchor: "#you-are-the-main-thread"

  - id: "09-025"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "When task list items consistently diverge from actual work done, what does the guide recommend?"
    options:
      a: "Delete the task list and start over"
      b: "Add more granular detail to each task"
      c: "Use divergence patterns as diagnostic: too broad = break down, too narrow = step back, wrong priorities = re-align with goals"
      d: "Ignore the divergence and continue"
    correct: "c"
    explanation: |
      Task list divergence is diagnostic, not failure. Patterns reveal issues:

      - **Too broad** tasks → break down into smaller pieces
      - **Too narrow** tasks → step back and think bigger
      - **Wrong priorities** → re-align tasks with actual goals
      - **Consistent drift** → your mental model of the problem is wrong

      Use divergence as signal, not noise.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Task Management Patterns"
      anchor: "#task-management-patterns"

  - id: "09-026"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is the 'occurrence rule' for claiming established patterns in code reviews?"
    options:
      a: ">5 occurrences = established, 2-5 = emerging, <2 = not established"
      b: ">10 occurrences = established, 3-10 = emerging, <3 = not established"
      c: "Based on file count, not occurrences"
      d: ">20 occurrences = established, 5-20 = emerging, <5 = not established"
    correct: "b"
    explanation: |
      Anti-hallucination safeguards for code reviews define the occurrence rule:

      - **>10 occurrences** = established pattern (safe to reference)
      - **3-10 occurrences** = emerging pattern (mention cautiously)
      - **<3 occurrences** = NOT an established pattern (don't claim it is)

      This prevents Claude from hallucinating "established conventions" from a few examples.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Anti-Hallucination Safeguards"
      anchor: "#anti-hallucination-safeguards"

  - id: "09-027"
    difficulty: "power"
    profiles: ["power"]
    question: "What are the 3 specialized agents in multi-agent code review?"
    options:
      a: "Security Reviewer, Performance Analyst, UX Reviewer"
      b: "Linter, Type Checker, Test Runner"
      c: "Consistency Auditor, SOLID Analyst, Defensive Code Auditor"
      d: "Junior Reviewer, Senior Reviewer, Architect Reviewer"
    correct: "c"
    explanation: |
      Multi-agent PR review uses 3 specialized agents:

      1. **Consistency Auditor** - Checks naming conventions, import patterns, code style adherence
      2. **SOLID Analyst** - Reviews architectural principles, dependency injection, single responsibility
      3. **Defensive Code Auditor** - Validates error handling, input validation, edge cases

      Each agent has anti-hallucination safeguards (occurrence rule, file-scoped claims).
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Multi-Agent PR Review"
      anchor: "#multi-agent-pr-review"

  - id: "09-028"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is 'comprehension debt' according to Addy Osmani's '80% Problem'?"
    options:
      a: "Documentation debt - missing docs"
      b: "Code you shipped but don't fully understand - distinct from technical debt"
      c: "Review debt - unreviewed PRs"
      d: "Design debt - skipped design phase"
    correct: "b"
    explanation: |
      Comprehension debt is code you shipped but don't fully understand. It's distinct from technical debt (code you understand but know is suboptimal). With AI-generated code, comprehension debt grows silently: you accept suggestions without deep understanding. The fix: always be able to explain WHY, not just WHAT.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Practitioner Insights"
      anchor: "#practitioner-insights"

  - id: "09-029"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is the '4-step cycle' for CLAUDE.md as compounding memory (Boris Cherny)?"
    options:
      a: "Write, Test, Deploy, Monitor"
      b: "Plan, Execute, Review, Commit"
      c: "Error, Rule, Read, Never repeated"
      d: "Ask, Implement, Validate, Ship"
    correct: "c"
    explanation: |
      Boris Cherny's mental model for CLAUDE.md as compounding memory:

      1. **Error** - Claude makes a mistake
      2. **Rule** - You add a rule to CLAUDE.md preventing it
      3. **Read** - Claude reads CLAUDE.md on every session start
      4. **Never repeated** - The mistake never happens again

      Goal: never correct Claude twice for the same mistake. CLAUDE.md compounds over time.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "Boris Cherny Mental Models"
      anchor: "#boris-cherny-mental-models"