claude-code-ultimate-guide/quiz/questions/04-agents.yaml

category: "Agents"
category_id: 4
source_file: "guide/ultimate-guide.md"

questions:
  - id: "04-001"
    difficulty: "junior"
    profiles: ["junior", "senior", "power", "pm"]
    question: "What are agents in Claude Code?"
    options:
      a: "External software programs"
      b: "Specialized AI personas for specific tasks that Claude can delegate to"
      c: "Human assistants"
      d: "Automated scripts"
    correct: "b"
    explanation: |
      Agents are specialized sub-processes (AI personas) that Claude can delegate tasks to. They encapsulate domain expertise, like a security reviewer knowing OWASP Top 10 or a backend architect understanding API design. Think of them as "expert consultants" - instead of explaining everything in your prompt, you invoke an agent that already has that expertise.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.1 What Are Agents"
      anchor: "#41-what-are-agents"

  - id: "04-002"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "Where should custom agent files be stored?"
    options:
      a: "~/.claude/agents/"
      b: ".claude/agents/"
      c: "/agents/"
      d: ".claude/commands/"
    correct: "b"
    explanation: |
      Custom agent files should be stored in `.claude/agents/` within your project directory. They are markdown files with YAML frontmatter. For example: `.claude/agents/backend-architect.md`, `.claude/agents/code-reviewer.md`. These can be committed to version control to share with your team.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.2 Creating Custom Agents"
      anchor: "#42-creating-custom-agents"

  - id: "04-003"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What fields are REQUIRED in an agent's YAML frontmatter?"
    options:
      a: "name, model, tools"
      b: "name, description"
      c: "name, description, model, tools"
      d: "name, role, skills"
    correct: "b"
    explanation: |
      Only `name` and `description` are required in agent frontmatter. Optional fields include: model (sonnet default, opus, or haiku), tools (comma-separated list), skills (to inherit), and disallowedTools. The description is crucial - it determines when Claude auto-activates the agent, so make it clear and specific.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.2 Creating Custom Agents"
      anchor: "#frontmatter-fields"

  - id: "04-004"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is the advantage of using agents over direct prompts?"
    options:
      a: "Agents are faster"
      b: "Agents encapsulate expertise so you don't need to explain everything each time"
      c: "Agents cost less"
      d: "Agents can access more files"
    correct: "b"
    explanation: |
      Agents encapsulate expertise. Without agents, you'd write: "Review this code for security issues, focusing on OWASP Top 10, checking for SQL injection, XSS, CSRF..." With agents: "Use the security-reviewer agent to audit this code." The agent already has that expertise, making your prompts shorter and more consistent.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.1 What Are Agents"
      anchor: "#agent-vs-direct-prompt"

  - id: "04-005"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "Which model should you use for agents performing complex architectural analysis?"
    options:
      a: "haiku - for speed"
      b: "sonnet - for balance"
      c: "opus - for maximum reasoning"
      d: "Any model works equally well"
    correct: "c"
    explanation: |
      Use opus for complex reasoning and architecture tasks. Model selection guidelines: haiku (fast, low cost) for quick tasks and simple changes; sonnet (balanced, default) for most tasks; opus (slow, high cost) for complex reasoning, architecture decisions, and critical security reviews. Match the model to the task's complexity.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.2 Creating Custom Agents"
      anchor: "#model-selection"

  - id: "04-006"
    difficulty: "power"
    profiles: ["power"]
    question: "What is 'Tool SEO' in agent design?"
    options:
      a: "Making tools searchable online"
      b: "Optimizing the description field to improve when Claude auto-activates the agent"
      c: "SEO for documentation"
      d: "A marketing technique"
    correct: "b"
    explanation: |
      Tool SEO optimizes the agent's description field to improve auto-activation. Techniques include: using "use PROACTIVELY" to encourage automatic activation, listing explicit trigger keywords, describing specific contexts, and adding short nicknames. A good description: "Security code reviewer - use PROACTIVELY when: reviewing auth code, analyzing API endpoints... Triggers: security, auth, vulnerability, OWASP"
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#tool-seo---optimizing-agent-descriptions"

  - id: "04-007"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is the best practice for agent design: specialization or generalization?"
    options:
      a: "Create one generalist agent that does everything"
      b: "Create specialized agents for each domain (security, testing, backend, etc.)"
      c: "Mix specialized and generalist agents"
      d: "Avoid agents entirely"
    correct: "b"
    explanation: |
      Always prefer specialization over generalization. Good: separate agents for backend-architect (API, database, performance), security-reviewer (OWASP, auth, encryption), test-engineer (test strategy, coverage, TDD). Bad: one full-stack-expert that "does everything (poorly)". Specialized agents have focused context and domain-specific expertise.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.4 Best Practices"
      anchor: "#specialization-over-generalization"

  - id: "04-008"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "How can agents inherit knowledge from skills?"
    options:
      a: "By copying skill content into the agent"
      b: "Using the 'skills' field in the frontmatter"
      c: "Skills and agents cannot be combined"
      d: "By importing skill files"
    correct: "b"
    explanation: |
      Agents inherit skills using the `skills` field in frontmatter. For example: `skills: [security-guardian]`. This composes expertise without duplication - instead of copying OWASP knowledge into every security-related agent, they all inherit from the security-guardian skill. This follows DRY principles for knowledge organization.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.4 Best Practices"
      anchor: "#skill-composition"

  - id: "04-009"
    difficulty: "power"
    profiles: ["power"]
    question: "What is the '7-Parallel-Task Method'?"
    options:
      a: "Running 7 Claude instances simultaneously"
      b: "Launching 7 specialized sub-agents in parallel to implement complete features"
      c: "A debugging technique"
      d: "A code review checklist"
    correct: "b"
    explanation: |
      The 7-Parallel-Task Method launches 7 specialized sub-agents in parallel: 1) Components, 2) Styles, 3) Tests, 4) Types, 5) Hooks, 6) Integration, 7) Config. All run in parallel, then results are consolidated. This dramatically speeds up feature implementation by parallelizing independent work streams.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#the-7-parallel-task-method"

  - id: "04-010"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is the recommended agent weight for frequently-used tasks?"
    options:
      a: "Heavy (25K+ tokens) for thoroughness"
      b: "Medium (10-15K tokens) for balance"
      c: "Lightweight (<3K tokens) for speed"
      d: "Weight doesn't matter"
    correct: "c"
    explanation: |
      Use lightweight agents (<3K tokens, <1s init time) for frequent tasks and workers. Golden Rule: "A lightweight agent used 100x > A heavy agent used 10x." Agent weight categories: Lightweight (<3K tokens) for frequent tasks, Medium (10-15K) for analysis/reviews, Heavy (25K+) for architecture/full audits. Match weight to task frequency.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#agent-weight-classification"

  - id: "04-011"
    difficulty: "power"
    profiles: ["power"]
    question: "In multi-agent orchestration, what model combination is recommended?"
    options:
      a: "Opus everywhere for quality"
      b: "Haiku everywhere for cost savings"
      c: "Sonnet orchestrator + Haiku workers + Sonnet validator"
      d: "Use the same model for all agents"
    correct: "c"
    explanation: |
      The recommended pattern is: Sonnet as orchestrator (coordinates), Haiku workers (parallel execution), Sonnet validator (final check). This is 2-2.5x cheaper than using Opus everywhere with equivalent quality for 90% of tasks. For example, refactoring 100 files: Sonnet analyzes and plans, Haiku does parallel edits, Sonnet validates - saving 80-90% cost.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#multi-agent-orchestration-pattern"

  - id: "04-012"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What should an agent's output format section include?"
    options:
      a: "Only code examples"
      b: "Structured deliverables like reports with sections, severity levels, and recommendations"
      c: "Raw text output"
      d: "JSON only"
    correct: "b"
    explanation: |
      An agent's output format should specify structured deliverables. For example, a code reviewer agent outputs: Summary, Critical Issues (Must Fix) with file:line references, Warnings (Should Fix), Suggestions (Nice to Have), and Positive Notes. Clear output format ensures consistent, actionable results across all invocations.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.5 Agent Examples"
      anchor: "#example-1-code-reviewer-agent"

  - id: "04-013"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What is the purpose of the 'disallowedTools' field in agent frontmatter?"
    options:
      a: "To list tools the agent must use"
      b: "To block specific tools from being used by the agent"
      c: "To disable the agent"
      d: "To list deprecated tools"
    correct: "b"
    explanation: |
      The disallowedTools field blocks specific tools from being used by the agent. For example, a code reviewer agent might have `disallowedTools: [WebSearch]` to ensure it focuses on the actual code rather than searching the web. This provides security boundaries and focuses the agent on its core purpose.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.2 Creating Custom Agents"
      anchor: "#agent-file-structure"

  - id: "04-014"
    difficulty: "power"
    profiles: ["power"]
    question: "What is the 'Split Role Sub-Agents' pattern?"
    options:
      a: "Dividing one agent into multiple files"
      b: "Multi-perspective analysis using parallel agents with different expert roles"
      c: "Splitting code review into phases"
      d: "Assigning agents to different team members"
    correct: "b"
    explanation: |
      Split Role Sub-Agents provide multi-perspective analysis in parallel. Process: 1) Activate Plan Mode (thinking enabled by default in Opus 4.5), 2) Ask "What expert roles would analyze this?", 3) Select roles (e.g., Security Expert, Senior Dev, Code Reviewer), 4) Run parallel analysis from each perspective, 5) Consolidate reports into recommendations. Great for comprehensive code and UX reviews.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#split-role-sub-agents"

  - id: "04-015"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "When should parallel execution of agents be avoided?"
    options:
      a: "When tasks are read-only"
      b: "When tasks are destructive (write operations) and dependent on each other"
      c: "When using haiku model"
      d: "When more than 3 agents are involved"
    correct: "b"
    explanation: |
      Avoid parallel execution for destructive (write) operations that are dependent on each other. The decision matrix: Independent + Non-destructive = Parallel (max efficiency); Independent + Destructive = Sequential with Plan Mode first; Dependent operations = Sequential (order matters). Parallel writes risk conflicts if files share imports/exports.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.6 Advanced Agent Patterns"
      anchor: "#parallelization-decision-matrix"

  - id: "04-016"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What does a Debugger agent's methodology typically include?"
    options:
      a: "Only fixing code"
      b: "Reproduce, Isolate, Analyze, Hypothesize, Test, Fix, Verify"
      c: "Just running tests"
      d: "Deleting problematic code"
    correct: "b"
    explanation: |
      A systematic Debugger agent follows: 1) Reproduce - confirm the issue exists, 2) Isolate - narrow down to smallest reproducible case, 3) Analyze - read code, check logs, trace execution, 4) Hypothesize - form theories about cause, 5) Test - verify hypothesis with minimal changes, 6) Fix - implement solution, 7) Verify - confirm fix works without breaking other things. Never guess - always verify.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.5 Agent Examples"
      anchor: "#example-2-debugger-agent"

  - id: "04-017"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What is an example of a BAD agent description?"
    options:
      a: "'Use when designing APIs, reviewing database schemas, or optimizing backend performance'"
      b: "'Backend stuff'"
      c: "'Security code reviewer - use PROACTIVELY when reviewing auth code'"
      d: "'Use when encountering errors, test failures, or unexpected behavior'"
    correct: "b"
    explanation: |
      "Backend stuff" is a bad description - it's too vague to help Claude know when to activate the agent. Good descriptions are specific: "Use when designing APIs, reviewing database schemas, or optimizing backend performance" or "Security code reviewer - use PROACTIVELY when reviewing auth code." Clear activation triggers improve agent utilization.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "4.4 Best Practices"
      anchor: "#explicit-activation-triggers"