An agent (Claude Code calls them subagents) is a separate Claude with its own fresh context, its own instructions, and a limited set of tools.
The main conversation hands it a job. It reads whatever it needs, does the work, and returns only a short report.
That solves two problems SDD used to work around with separate sessions:
✓ context stays small
Reading files and running commands fills Claude's context, and quality drops as it fills. When every task runs in its own agent, the main conversation only ever holds the plan and short reports, even across a twenty-task feature.
✓ review without bias
A reviewer that watched the code being written tends to agree with it. sdd-reviewer sees only the spec and the changes, so it judges the result on its own terms.
Who delegates to whom
YOU → /sdd-feature · /sdd-implement · /sdd-validate
│
MAIN CONVERSATIONasks you questions · plans · runs checks · commits
│
├── Explorebuilt in · read-only · research for bootstrap, feature, checkup
├── sdd-implementerone per task · edits code · runs the task's check · no commits
├── sdd-reviewerone per validation · read-only · pass/fail with evidence
└── feature agentbuilt in (general-purpose) · one per feature in parallel mode
│ runs in its own worktree
└── sdd-implementerone per task, inside that worktree
A·01
sdd-implementer
Builds exactly one task from tasks.md and runs its check · Sonnet · used by /sdd-implement
Checks the feature against its acceptance criteria, with evidence · read-only · Opus · used by /sdd-validate
+
tools: Read, Glob, Grep, Bashmodel: opusno Edit or Write tools
in
Receives only the feature folder and the commit range, never the coordinator's opinion of the work.
1
Reads the spec, confirms there's one commit per task, and looks at what changed.
2
Checks each acceptance criterion by finding the code and the test that cover it and running the test. Every verdict cites evidence.
3
Checks scope: did anything change that no task asked for, and was anything out of scope built anyway?
4
Runs the full test suite. The overall result is PASS only if every criterion and the suite pass.
Tuned to avoid nitpicking: a reviewer asked to find problems will usually find some. sdd-reviewer fails a feature only for gaps that affect correctness or a stated requirement. Anything else goes under "Optional notes", so you don't chase style findings.
A·03
Built-in agents the skills use
Part of Claude Code itself · nothing to install
+
E
Explore: a fast, read-only agent for searching and understanding code. /sdd-bootstrap runs three at once, and /sdd-feature and /sdd-checkup use it for research, so file contents stay out of your conversation.
G
general-purpose: used by /sdd-implement in parallel mode, one per feature, each in its own worktree. Inside it, every task still goes to sdd-implementer.
R
/code-review: a built-in skill that reviews the current changes for bugs, in its own agent. /sdd-implement offers it when a feature's tasks are done. It complements sdd-reviewer, which checks the spec rather than looking for bugs.
A·04
Customizing and limits
Change a model · override an agent for one project · what agents can't do
+
1
Change the model by editing model: in the agent file. inherit makes it follow the main conversation's model.
2
Override for one project by copying the file into that project's .claude/agents/. A project agent wins over one with the same name in ~/.claude/agents/.
3
Edits take effect immediately. Claude Code notices changed agent files within a few seconds. The one exception is the first file in a brand-new agents folder, which needs a new session.
✗
Agents can't ask you questions. That's why sdd-implementer reports BLOCKED and the coordinator asks you instead.
✗
Agents don't see your conversation. That's why tasks have to be complete on their own, with files, steps, a check and the criteria they cover.
!
Every report adds to the main context. That's why both agents keep their reports short.