Samples — CLAUDE.md, Skills, Hooks, MCP, Settings
Nothing makes config click like a real file you can copy. Every sample here is minimal but production-shaped — adapt freely. They map to Domain 2 (Claude Code) and Domain 4 (MCP), and each one ends with why it scores on the exam.
A team CLAUDE.md (project memory)
# CLAUDE.md — acme-billing-service
## Commands
- Build: `npm run build` · Test: `npm test` (Jest) · Single test: `npx jest path/to.test.ts`
- Local stack: `./start.sh` (API :8080 + Postgres via docker compose)
## Architecture
- Hexagonal: `src/domain` (pure logic, no IO) · `src/adapters` (DB, HTTP) · `src/api` (routes).
- All money is integer cents. Never floats. Timestamps are UTC ISO-8601.
## Conventions
- TypeScript strict; no `any` without a `// justified:` comment.
- Errors: never swallow; wrap with context and rethrow typed errors from `src/errors.ts`.
- Every new endpoint needs: zod schema, unit test, and an entry in `docs/api.md`.
## Etiquette
- Never commit directly to `main`; branch + PR.
- Do not modify `migrations/` files that already shipped — create new migrations.Why it scores: short, imperative, durable knowledge only — commands, architecture facts, hard rules. No task instructions, no essays. (The specifics here — Hexagonal layering, zod schemas, typed errors — are illustrative for readers who know TypeScript service architecture; the transferable lesson is what kind of facts belong in CLAUDE.md, not this stack.)
A skill (.claude/skills/release-check/SKILL.md)
---
name: release-check
description: Pre-release verification checklist for acme-billing-service.
Use before tagging any release or when the user says "release check".
---
# Release check
Run, in order, and report each as pass/fail:
1. `npm test` — all green, no skipped tests.
2. `npm run build` — zero warnings.
3. `git log --oneline v$(cat VERSION)..HEAD` — summarize changes; flag any commit
touching `migrations/` and verify a new migration file exists.
4. Confirm `CHANGELOG.md` has an entry for the new version.
5. If ANY step fails: stop, list failures, do NOT tag.
On full pass: propose the `git tag` command but do not run it — tagging requires the human.Why it scores: model-invokable expertise (description says when to use), deterministic steps, an explicit HITL boundary at the risky action.
Hooks (.claude/settings.json)
{
"permissions": {
"allow": ["Bash(npm run test:*)", "Bash(npm run build)", "Read(**)", "Edit(src/**)"],
"deny": ["Read(.env*)", "Read(secrets/**)", "Bash(rm -rf*)"]
},
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [{ "type": "command",
"command": "python3 .claude/hooks/block_dangerous.py" }]
}],
"PostToolUse": [{
"matcher": "Write|Edit",
"hooks": [{ "type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATHS\"" }]
}]
}
}# .claude/hooks/block_dangerous.py — exit 2 blocks the action; stderr goes to Claude
import json, re, sys
cmd = json.load(sys.stdin).get("tool_input", {}).get("command", "")
BANNED = [r"rm\s+-rf\s+/", r"git\s+push\s+--force", r"DROP\s+TABLE", r"curl[^|]*\|\s*sh"]
for pat in BANNED:
if re.search(pat, cmd, re.I):
print(f"Blocked by policy: matches '{pat}'. Propose a safer alternative.", file=sys.stderr)
sys.exit(2)
sys.exit(0)Why it scores: allow/deny lists limit how much damage a bad command can do (the blast radius); the PreToolUse guard is deterministic enforcement; the formatter hook applies style on every write without burning instructions — and because it drops the || true, a formatter failure surfaces instead of passing silently. Note the deny patterns are defense-in-depth, not the real boundary: the boundary is the default-deny allowlist, because shell syntax has many equivalent destructive forms a blocklist can't fully enumerate.
Project MCP config (.mcp.json — checked into git)
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"//": "pin an exact version in real projects (…@x.y.z) — vet MCP servers like dependencies",
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
},
"tickets": {
"type": "http",
"url": "https://mcp.internal.acme.com/tickets",
"headers": { "Authorization": "Bearer ${TICKETS_TOKEN}" }
}
}
}Why it scores: env interpolation (no secrets in git), plus one server of each of MCP's two transport types — a stdio server (a local subprocess Claude Code launches and talks to over standard input/output) for local tooling, and an HTTP server for a shared remote service — showing you know the transports and scopes. The "//" line is a reminder, not config: npx -y runs whatever version resolves today, so pin an exact version and vet MCP servers like any other dependency.
A slash command (.claude/commands/fix-issue.md)
---
description: Fix a GitHub issue end to end
argument-hint: <issue-number>
---
Fetch issue #$ARGUMENTS with the github MCP server. Restate the problem in two
sentences. Locate the responsible code. Write a failing test reproducing it.
Fix, run the full test suite, and prepare a PR description referencing #$ARGUMENTS.
Stop before pushing — show me the diff first.A subagent (.claude/agents/reviewer.md)
---
name: reviewer
description: Read-only code reviewer. Use after significant edits or before PRs.
tools: Read, Grep, Glob
---
You are a strict senior reviewer. Never edit files. Review the diff for:
correctness, security (injection, secrets, authorization), performance, and test coverage.
Output: a numbered list of findings, each with file:line, severity, and a concrete fix.
End with a verdict: APPROVE or REQUEST_CHANGES.Why it scores: own context window, read-only tool policy, explicit output contract — the subagent pattern done canonically.