CCA-F Domain 3 Study Guide: Claude Code Configuration & Workflows

A custom slash command is a Markdown file whose body is a reusable prompt. Save it and you invoke it on demand by typing /name. Where you save it decides who can use it, and that placement decision is the whole point of this objective.

• Project commands live in .claude/commands/ inside the repo. They are committed to version control, so every teammate who clones the repo gets them. Use this for shared, project-specific workflows.
• User (personal) commands live in ~/.claude/commands/ in your home directory. They follow you across every project on your machine but are invisible to teammates. Use this for personal habits.
• The filename becomes the command name: .claude/commands/deploy.md creates /deploy.

Commands can take arguments. $ARGUMENTS expands to everything typed after the command name; positional placeholders capture individual arguments. Optional frontmatter (description, argument-hint, and tool/model controls) tunes how the command appears and runs.

---
description: Triage and fix a GitHub issue by number
argument-hint: <issue-number>
---
Fetch issue #$ARGUMENTS with `gh issue view`.
Reproduce it, write a failing test, then implement the fix.
Keep the change minimal and reference the issue in the commit.

Note that Claude Code has merged custom commands into Skills: a file at .claude/skills/deploy/SKILL.md also creates /deploy and works the same way when invoked. Existing .claude/commands/*.md files keep working. The difference is that a Skill can also be loaded autonomously by Claude when relevant, whereas a plain command is invoked on demand.

When Claude's first attempt misses, how you ask for changes matters more than how many times you ask. Effective refinement is structured, not a stream of vague 'still not right' replies.

• Concrete input-output examples anchor the target better than adjectives. 'For input 2026-07-24, output Jul 24, 2026' removes ambiguity that 'format the date nicely' leaves open.
• Targeted feedback on specific failures — 'the null case on line 42 throws' — lets Claude fix the actual defect instead of rewriting working code and introducing new regressions.
• Batched issue descriptions consolidate several problems into one message so Claude can evaluate them together, weigh interactions, and fix them in a single coherent pass.

Batching matters because fixing issues one at a time can make Claude 'whack-a-mole' — re-fix A while breaking B. Presenting the full set lets it reason about them holistically. It also spends fewer turns and less context than a long back-and-forth.

Plan mode is a read-only mode: Claude investigates and proposes an approach but does not edit files, run mutating commands, or commit until you approve the plan. Direct execution lets it act immediately. Choosing between them is a risk judgment across four axes.

Plan mode shines when the cost of a wrong direction is high: a database migration, a broad refactor, or work where a reviewer needs to approve how before any code is written. For a one-line typo fix or a well-scoped, reversible edit, plan mode is overhead that slows the loop.

This is the conceptual heart of Domain 3. CLAUDE.md is auto-loaded guidance — memory the model reads and usually follows, but may not, especially in a long or distracted session. Settings permissions and hooks are deterministic: the harness applies them mechanically, independent of the model's cooperation.

So the test for where an instruction belongs is: what happens if the model ignores it? If the answer is 'mild annoyance' (a naming preference, a tone, a conventions reminder), CLAUDE.md is right. If the answer is 'security breach, data loss, or a broken build' — anything that must hold every single time — it belongs in permissions or a hook.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(git push:*)"
    ],
    "ask": ["Bash(rm:*)"],
    "allow": ["Bash(npm run test:*)"]
  }
}

• 'Never read the .env file' in CLAUDE.md is a request; as a deny rule it is a guarantee the tool call cannot even fire.
• 'Always run the formatter after editing' in CLAUDE.md will be forgotten eventually; as a PostToolUse hook it runs every time.
• Rules are evaluated deny first, then ask, then allow — the first match wins, so a deny always overrides a matching allow.

Claude Code offers several places to put guidance, and objective 16 is about matching the mechanism to the kind of guidance and when it should apply.

Two axes disambiguate: scope (does this apply always, or only to certain files?) and enforcement (is this a suggestion or a rule?). Always-on convention → CLAUDE.md. Path-specific convention → .claude/rules/ with a glob. A long procedure you do not want bloating every prompt → a Skill. A step that must happen mechanically → a hook. A boundary that must never be crossed → permissions.

A PostToolUse hook runs a shell command after a tool completes. Scoped to the file-editing tools with a matcher like "Edit|Write", it becomes your enforcement point for code quality: format, lint, or test after every edit, no matter whether the model 'remembered' to.

This is the practical payoff of objective 15's principle. Telling Claude in CLAUDE.md to 'run Prettier after editing' is discretionary. A PostToolUse hook makes it structural — the formatter runs on the edited file every single time, independent of instruction-following.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

• The matcher filters on tool name; "Edit|Write" targets file modifications.
• The hook receives JSON on stdin (including tool_input.file_path), so it can act on exactly the file that changed.
• A hook that exits non-zero (or returns blocking feedback) can surface a lint/test failure back to Claude, prompting it to fix the issue rather than move on.

Understanding an unfamiliar codebase is a context-budget problem. The built-in tools form a funnel: Glob finds files by name pattern, Grep finds content across many files, and Read pulls the full contents of a specific file into context. The skill is ordering them to build understanding incrementally without flooding the window.

1. 01Glob to map structure — Glob **/*.test.ts shows where tests live before you read any of them.
2. 02Grep to locate — search for a symbol, route, or error string across the repo to find which files matter. Grep returns matching lines/files, not whole files, so it is cheap.
3. 03Read to understand — open only the handful of files Grep pointed you to, and read targeted line ranges rather than 2,000-line files wholesale.

The anti-pattern is reading many large files up front 'to get oriented.' That burns the context window fast and buries the relevant detail. Search first to narrow, then read narrowly. Delegating a broad search to a subagent is another way to keep raw file dumps out of your main context — you keep the conclusion, not the noise.

There are three ways to get project context in front of Claude, and they differ on reusability, specificity, and whether the context is needed across sessions.

Decision rule: if you will need it again next session, it belongs in CLAUDE.md. If you need one particular file's real contents this time, @-reference it — that is more precise and current than describing it from memory. If it is a throwaway detail, just say it inline.