Interpretive guidance for designing Claude Code sub-agents. Helps apply official documentation effectively and avoid common pitfalls. ALWAYS use when creating or reviewing sub-agents (aka agents or subagents).
/plugin marketplace add racurry/neat-little-package/plugin install box-factory@neat-little-packageThis skill inherits all available tools. When active, it can use any tool Claude has access to.
gotchas.mdThis skill provides interpretive guidance for creating Claude Code sub-agents (aka Subagents aka Agents). It helps you understand what the docs mean and how to create excellent sub-agents.
Everything in this skill is built on top of the box-factory-architecture skill. Load that first!
This skill adds sub-agent-specific guidance on top of that foundation.
| If you need to... | Go to... |
|---|---|
| Understand sub-agent isolation model | box-factory-architecture skill (load first) |
| Decide sub-agent vs command vs skill | box-factory-architecture skill (component selection) |
| Decide what goes in sub-agent vs skill | Sub-agent-Skill Relationship |
| Structure the agent body | Agent Body Structure |
| Auto-load skills in a sub-agent | The skills Field |
| Write Skill Usage section | Skill Usage Section Pattern |
| Inline validation checklist | Inlining Quality Checklists |
| Pick tools for a sub-agent | Tool Selection Philosophy |
| Know which tool is forbidden | Never Include AskUserQuestion |
| Understand why creators need Bash | Bash is Foundational for Creators |
| Pair WebFetch with skills | WebFetch Pairs with Skills |
| Determine file path for new sub-agent | box-factory-architecture skill (component-paths) |
| Write the description field | Description Field Design |
| Avoid common mistakes | Common Gotchas |
| Check color for status line | Color Selection |
| Validate before completing | Quality Checklist |
Sub-agent file structure:
---
name: my-agent
description: Does X when Y. ALWAYS use when Z.
tools: Read, Grep, Glob, Skill
skills: my-plugin:my-design-skill
color: green
---
# My Agent
This sub-agent [purpose].
## Process
1. [Step one]
2. [Step two]
## Constraints
- Never include "ask the user" phrases (sub-agents can't interact with users)
Critical: Sub-agents operate in isolated context and return results. They cannot ask users questions.
The body of a sub-agent (everything after YAML frontmatter) defines its system prompt.
Required:
| Section | Purpose |
|---|---|
| H1 Title | Agent identity. Single H1 only. |
| Process | Numbered steps the agent follows. |
Optional:
| Section | When to Include |
|---|---|
| Opening line | Brief statement of purpose (one sentence after H1) |
| Prerequisites | Skills or conditions required before starting |
| Skill Usage | When agent loads skills via skills field (see below) |
| Constraints | Behavioral rules during execution |
| Error Handling | Table of edge cases and responses |
Section naming:
Minimal agent:
# Agent Name
## Process
1. **Step one**
2. **Step two**
Full agent (with skills):
# Agent Name
This sub-agent [purpose].
## Prerequisites
The following skills must be available. If they are not, report failure and stop:
- skill-one
- skill-two
## Skill Usage
Follow the **Workflow Selection** table in each loaded skill to navigate to the right guidance.
**skill-one** - Consult for:
- [Aspect A] (Section Name)
- [Aspect B] (Section Name)
**skill-two** - Consult for:
- [Aspect C] (Section Name)
- [Aspect D] (Section Name)
## Process
1. **Understand requirements** from the caller
2. **Design** by navigating loaded skills:
- Follow skill-one for [specific decisions]
- Consult skill-two for [other decisions]
3. **Execute** the task
4. **Validate** - ALL items must pass before completing:
- [ ] Checklist item one
- [ ] Checklist item two
- [ ] Checklist item three
**If ANY item fails:** Fix before reporting results.
5. **Report results**
## Error Handling
| Situation | Action |
| --- | --- |
| Required skills not loaded | Report failure, do not attempt task |
| Unclear requirements | Make reasonable assumptions, document them |
Why this structure works:
skills Field (Best Practice)The skills YAML field auto-loads skills when the sub-agent starts. This is especially valuable for Box Factory sub-agents that need design skills.
---
name: agent-writer
description: Creates sub-agents. ALWAYS use when creating sub-agents.
tools: Read, Write, Edit, Glob, Grep, Skill, WebFetch
skills: box-factory:sub-agent-design
---
When to use:
| Pattern | Choose When | Avoid When |
|---|---|---|
skills field | Domain is fixed; always needs same skill | Different skills needed based on context |
| Skill tool in body | Domain varies; skill depends on runtime context | Same skill always needed (use skills field) |
| No skill | No relevant skill exists | A skill exists with guidance Claude needs |
Box Factory pattern: Writer sub-agents should declare their design skill dependency:
agent-writer → skills: box-factory:sub-agent-designskill-writer → skills: box-factory:skill-designcommand-writer → skills: box-factory:slash-command-designNote: Still include Skill in your tools list - the sub-agent may need to load additional skills during execution.
Example of conditional skill loading (Skill tool in body pattern):
---
name: component-validator
description: Validates Claude Code components. MUST BE USED when validating plugins or components.
tools: Read, Grep, Glob, Skill, WebFetch
---
# Component Validator
## Process
1. **Identify component type** from file structure
2. **Load relevant design skill:**
- Plugin → `Skill box-factory:plugin-design`
- Sub-agent → `Skill box-factory:sub-agent-design`
- Skill → `Skill box-factory:skill-design`
- Command → `Skill box-factory:slash-command-design`
3. **Validate** against loaded skill's patterns
This sub-agent can't declare a single skill upfront because which skill it needs depends on what component type it discovers at runtime.
When an agent loads skills via the skills field, include a Skill Usage section. This teaches the agent HOW to traverse the loaded skills, not just THAT they're loaded.
Problem it solves: Skills auto-load content, but the agent might not know which parts to consult for which decisions. Generic instructions like "use the skill" don't guide navigation.
Structure:
## Skill Usage
Follow the **Workflow Selection** table in each loaded skill to navigate to the right guidance.
**skill-name** - Consult for:
- [What to look up] (Section Name in skill)
- [Another aspect] (Another Section)
Key principles:
| Principle | Why It Matters |
|---|---|
| Navigation pointers, not content | Avoids duplication; skill remains single source of truth |
| Reference section names | Stable pointers; section names change rarely |
| Specific aspects per skill | Agent knows which skill answers which question |
| No cross-component file paths | Skill internals are implementation details from agent's perspective |
Critical prohibition: When an agent references a skill it loads, use indirect references (section names, concept names) NOT the skill's internal file paths. A skill's internal file structure is an implementation detail from the agent's perspective.
(Quick Start) - section name in skill(Tool Selection Philosophy) - section name in skill(the skill's guidance on X) - indirect reference(gotchas.md) - skill's internal file (agent shouldn't know this)(skill-structure.md) - skill's internal fileExample (concrete):
## Skill Usage
Follow the **Workflow Selection** table in each loaded skill.
**box-factory-architecture** - Consult for:
- Component paths (where to put files)
- Isolation model (why agents can't ask questions)
- Communication patterns (CAN/CANNOT matrix)
**sub-agent-design** - Consult for:
- YAML frontmatter structure (Quick Start)
- Tool selection (Tool Selection Philosophy)
- Color selection (Color Selection)
When to skip: If agent loads no skills or loads them conditionally via Skill tool (runtime decision), Skill Usage section is not needed.
For critical validation, inline the checklist in the Process section. Don't just reference a skill's checklist—agents may skip the reference.
Problem it solves: "Validate against the skill's checklist" is easy to skip or satisfy superficially. Inlined checklists force explicit verification.
Pattern:
4. **Validate** - ALL items must pass before completing:
- [ ] Item one
- [ ] Item two
- [ ] Item three
**If ANY item fails:** Fix before reporting results.
What to inline:
| Inline | Reference (don't inline) |
|---|---|
| Validation checklists (blocking) | Guidance and context (informational) |
| Required checks before completion | Decision frameworks (for understanding) |
| Items that MUST NOT be skipped | Examples and patterns (for learning) |
Balance: Inline only the checklist items themselves (1-2 lines each). Keep explanations and rationale in the skill. This maintains single source of truth while ensuring validation happens.
Example (from sub-agent creation):
7. **Validate** - ALL items must pass before completing:
- [ ] Fetched official docs (or noted why skipped)
- [ ] Valid YAML frontmatter with required fields
- [ ] No forbidden language ("ask the user", "confirm with")
- [ ] Tools match autonomous responsibilities
- [ ] Description has specific triggering conditions
- [ ] Color set with semantic meaning
**If ANY item fails:** Fix before reporting results.
Claude Code changes rapidly and is post-training knowledge. Fetch these docs when creating sub-agents to ensure current syntax:
Core principle: When a sub-agent loads a skill, knowledge lives in the skill; the sub-agent focuses on process.
Decision logic:
| Sub-agent has backing skill? | Where knowledge goes | Sub-agent contains |
|---|---|---|
| Yes, loads a skill | Skill contains domain knowledge | Process, mechanics, validation steps |
| No backing skill | Sub-agent contains it | Both process AND knowledge |
Why this matters:
Pattern for skill-backed sub-agents:
Prefer the skills YAML field (see The skills Field) to auto-load skills at startup. The sub-agent body then focuses on process, with a Skill Usage section providing navigation:
## Skill Usage
Follow the **Workflow Selection** table in each loaded skill.
**my-skill** - Consult for:
- [Aspect A] (Section Name)
- [Aspect B] (Section Name)
## Process
1. **Design** by navigating loaded skills:
- Consult my-skill for [specific decisions]
2. **Execute task**
3. **Validate** - ALL items must pass:
- [ ] Checklist item from skill
- [ ] Another item
**If ANY fails:** Fix before reporting.
See Skill Usage Section Pattern and Inlining Quality Checklists for detailed guidance.
Pattern for standalone sub-agents (no skill):
## Process
1. **Understand requirements** [process step]
2. **Apply domain knowledge** [embedded in sub-agent]:
- Guideline one
- Guideline two
- Decision framework here
3. **Execute task** [process step]
Anti-pattern: Sub-agent loads skill but also embeds same knowledge inline. This causes:
General principle: Match tools to the sub-agent's job. Reviewers should be read-only; builders need write access.
Sub-agents operate in isolation and cannot interact with users. The AskUserQuestion tool will fail silently or cause unexpected behavior. If your sub-agent needs clarification, it must infer from context or make reasonable assumptions.
Any sub-agent with creative responsibilities needs Bash, regardless of output type. Even a sub-agent that only produces markdown files needs shell operations:
| Operation | Why Bash |
|---|---|
| Directory scaffolding | mkdir -p for nested structures (Write doesn't create parents) |
| File organization | mv, cp for restructuring |
| Post-write formatting | mdformat, linters, formatters |
| Structure inspection | ls to understand existing layout |
| Git operations | git mv for tracked renames |
Rule of thumb: If a sub-agent creates files, include Bash. The Write tool handles file content; Bash handles the filesystem orchestration around it.
When a sub-agent loads skills via the skills field (especially for specifications or rapidly-changing domains), also include WebFetch:
tools: Read, Write, Edit, Glob, Grep, Skill, WebFetch
skills: box-factory:sub-agent-design
Why: Skills encode knowledge delta (interpretive guidance beyond docs), but the underlying specifications change. Sub-agents should verify current official docs against skill guidance when uncertain.
Pattern: The sub-agent's process should include a step like:
"If uncertain about current spec, fetch official documentation to verify"
This maintains the low-maintenance-first philosophy—skills provide stable interpretive guidance while WebFetch catches spec drift.
The color field sets visual distinction for sub-agents in the status line.
Note: Color support is not documented officially. The following was verified through testing—Claude often guesses wrong colors that don't render.
Supported colors (7 total): red, green, blue, yellow, cyan, purple, orange
Not supported: magenta, white, black, gray, grey, *Bright variants
Semantic mapping:
| Color | Category | Use For |
|---|---|---|
blue | Creators | Sub-agents that create/write files, components, code |
green | Quality | Validators, reviewers, checkers, analyzers |
yellow | Operations | Git, deployment, CI/CD, system tasks |
purple | Meta | Sub-agents that create other sub-agents |
cyan | Research | Exploration, documentation, research sub-agents |
red | Safety | Security checks, destructive operations, warnings |
orange | Other | Sub-agents that don't fit other categories (reserved) |
Example:
---
name: code-reviewer
color: green
---
Guidelines:
orange for sub-agents that don't fit established categoriesThe description field determines when Main Claude delegates to your sub-agent. This is critical for autonomous invocation.
Official requirement: "Natural language explanation of when to invoke the subagent"
Quality test: Would Main Claude invoke this sub-agent based on context alone, or only when explicitly asked?
Guidelines:
Before finalizing a sub-agent:
skills field: