claude-code-ultimate-guide/quiz/questions/06-commands.yaml

category: "Commands"
category_id: 6
source_file: "guide/ultimate-guide.md"

questions:
  - id: "06-001"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "Where should custom commands be placed to make them available in Claude Code?"
    options:
      a: "~/.claude/commands/"
      b: ".claude/commands/"
      c: "/usr/local/claude/commands/"
      d: ".claude/config/commands/"
    correct: "b"
    explanation: |
      Custom commands are placed in `.claude/commands/` within your project directory.

      This allows project-specific commands that can be committed with your codebase.
      The global directory `~/.claude/` is for personal settings, not project commands.

      Commands are organized in subdirectories:
      - `.claude/commands/tech/` for development workflows
      - `.claude/commands/product/` for product workflows
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.2 Creating Custom Commands"
      anchor: "#62-creating-custom-commands"

  - id: "06-002"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "How do you invoke a custom command named `commit.md` located in `.claude/commands/tech/`?"
    options:
      a: "/commit"
      b: "/tech-commit"
      c: "/tech:commit"
      d: "!tech/commit"
    correct: "c"
    explanation: |
      Custom commands use the format `/folder:filename` (without the .md extension).

      So `.claude/commands/tech/commit.md` becomes `/tech:commit`.
      This naming convention allows organizing commands by domain while keeping invocation intuitive.

      Examples:
      - `.claude/commands/tech/pr.md` -> `/tech:pr`
      - `.claude/commands/product/scope.md` -> `/product:scope`
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.2 Creating Custom Commands"
      anchor: "#command-naming"

  - id: "06-003"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What variable is used in command files to access arguments passed to the command?"
    options:
      a: "$ARGS"
      b: "$INPUT"
      c: "$ARGUMENTS"
      d: "$PARAMS"
    correct: "c"
    explanation: |
      The `$ARGUMENTS` variable contains any text passed after the command invocation.

      For example, when you run `/tech:deploy production`, the variable `$ARGUMENTS`
      will contain `production`.

      This enables dynamic commands that can adapt based on user input.
      Commands should document how they handle arguments and what happens if none are provided.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.2 Creating Custom Commands"
      anchor: "#variable-interpolation"

  - id: "06-004"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "Which built-in command shows all available commands including custom ones?"
    options:
      a: "/commands"
      b: "/list"
      c: "/help"
      d: "/show"
    correct: "c"
    explanation: |
      The `/help` command displays all available commands, both built-in and custom.

      Built-in commands include:
      - `/clear` - Clear conversation
      - `/compact` - Summarize context
      - `/status` - Show session info
      - `/plan` - Enter Plan Mode
      - `/rewind` - Undo changes

      Custom commands from `.claude/commands/` are also listed here.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.1 Slash Commands"
      anchor: "#61-slash-commands"

  - id: "06-005"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What sections should a well-structured command template include according to best practices?"
    options:
      a: "Purpose, Steps, Output"
      b: "Purpose, Process, Arguments, Output Format, Examples, Error Handling"
      c: "Name, Description, Code"
      d: "Title, Body, Footer"
    correct: "b"
    explanation: |
      A complete command template should include:

      1. **Purpose** - Brief description of what the command does
      2. **Process** - Step-by-step instructions Claude should follow
      3. **Arguments** - How to handle $ARGUMENTS (if provided/not provided)
      4. **Output Format** - Expected structure of the output
      5. **Examples** - Concrete usage examples
      6. **Error Handling** - How to handle edge cases and failures

      This comprehensive structure ensures consistent, reliable command execution.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.3 Command Template"
      anchor: "#63-command-template"

  - id: "06-006"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "Which command enters Plan Mode for safe, read-only exploration?"
    options:
      a: "/safe"
      b: "/readonly"
      c: "/plan"
      d: "/explore"
    correct: "c"
    explanation: |
      The `/plan` command enters Plan Mode, where Claude can analyze and explore
      the codebase without making any changes.

      This is ideal for:
      - Understanding unfamiliar codebases
      - Architectural analysis before changes
      - Safe exploration of risky operations

      Use `/execute` to exit Plan Mode when ready to make changes.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.1 Slash Commands"
      anchor: "#built-in-commands"

  - id: "06-007"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "In the commit command example, what is the recommended commit message format?"
    options:
      a: "Simple description"
      b: "Conventional Commits: type(scope): description"
      c: "Date - Author - Message"
      d: "JIRA-123: Message"
    correct: "b"
    explanation: |
      The guide recommends Conventional Commits format: `type(scope): description`

      Common types:
      - `feat`: New feature
      - `fix`: Bug fix
      - `refactor`: Code restructuring
      - `docs`: Documentation
      - `test`: Test changes
      - `chore`: Maintenance

      This provides consistent, parseable commit history useful for changelogs and releases.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.4 Command Examples"
      anchor: "#example-1-commit-command"

  - id: "06-008"
    difficulty: "power"
    profiles: ["power"]
    question: "What technique does the Problem Framer command use to find root causes?"
    options:
      a: "SWOT Analysis"
      b: "5 Whys Analysis"
      c: "Pareto Analysis"
      d: "Fishbone Diagram"
    correct: "b"
    explanation: |
      The Problem Framer command uses the "5 Whys Analysis" technique.

      This involves asking "Why?" five times to drill down to the root cause:
      - Why 1: First answer
      - Why 2: Deeper answer
      - Why 3: Even deeper
      - Why 4: Getting to root
      - Why 5: Root cause

      The command then reframes the problem as: "How might we [action] for [user] so that [outcome]?"
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.4 Command Examples"
      anchor: "#example-3-problem-framer-command"

  - id: "06-009"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "What does the `/rewind` command do?"
    options:
      a: "Restores a previous git commit"
      b: "Undoes Claude's recent changes in the current session"
      c: "Clears the entire conversation history"
      d: "Rolls back the last command execution"
    correct: "b"
    explanation: |
      The `/rewind` command undoes Claude's recent changes in the current session.

      Key points:
      - Works only for uncommitted changes made by Claude
      - Does NOT create git commits
      - Use when Claude made a mistake and you want to try a different approach

      For committed changes, use `git revert` instead.
      The keyboard shortcut `Esc×2` (double-tap Escape) also triggers rewind.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.1 Slash Commands"
      anchor: "#built-in-commands"

  - id: "06-010"
    difficulty: "senior"
    profiles: ["senior", "power"]
    question: "What should a PR command's error handling do if the user is NOT on a feature branch?"
    options:
      a: "Automatically create a feature branch"
      b: "Proceed anyway with warnings"
      c: "WARN: Create a feature branch first"
      d: "Exit silently"
    correct: "c"
    explanation: |
      According to the PR command example, if the user is not on a feature branch,
      the command should WARN: "Create a feature branch first".

      Similarly, if the working directory is dirty, it should ASK: "Commit changes first?"

      Good command design includes clear error handling that:
      - Warns users about prerequisites
      - Suggests corrective actions
      - Prevents accidental mistakes
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.4 Command Examples"
      anchor: "#example-2-pr-command"

  - id: "06-011"
    difficulty: "power"
    profiles: ["power"]
    question: "What is the recommended order of git commands in a PR creation workflow?"
    options:
      a: "push, diff, create PR"
      b: "status, branch, log, diff, push if needed, create PR"
      c: "add, commit, push, create PR"
      d: "checkout, status, push, create PR"
    correct: "b"
    explanation: |
      The recommended PR workflow order is:

      1. `git status` - Verify clean working directory
      2. `git branch` - Confirm on feature branch
      3. `git log main..HEAD` - Review all commits
      4. `git diff main...HEAD` - See all changes vs main
      5. `git push -u origin [branch]` - Push if not already pushed
      6. `gh pr create` - Create the PR

      This thorough process ensures quality PRs with proper context.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "6.4 Command Examples"
      anchor: "#example-2-pr-command"

  - id: "06-012"
    difficulty: "junior"
    profiles: ["junior", "senior", "power"]
    question: "How do you reference a file when talking to Claude Code?"
    options:
      a: "#filename"
      b: "@filename"
      c: "!filename"
      d: "$filename"
    correct: "b"
    explanation: |
      The `@filename` syntax references a file in your conversation with Claude.

      Quick actions:
      - `@file` - Reference a file
      - `!command` - Run a shell command
      - `Ctrl+C` - Cancel operation
      - `Ctrl+R` - Retry last

      This allows you to easily bring specific files into context for Claude to analyze.
    doc_reference:
      file: "guide/ultimate-guide.md"
      section: "10.1 Commands Table"
      anchor: "#quick-actions"