
Create Subagent
- 4 installs
- 5 repo stars
- Updated February 7, 2026
- cygnusfear/claude-stuff
Create and configure custom Claude Code subagents, covering both file-based agents and Task tool invocation.
About
Guides creating and configuring Claude Code subagents with their own context, purpose, tools, and system prompts. A developer uses it to build specialized assistants and delegate tasks via file-based agents or the Task tool.
- Covers both file-based agents and Task tool invocation
- Each subagent gets its own context, tools, and system prompt
Create Subagent by the numbers
- 4 all-time installs (skills.sh)
- Ranked #13,349 of 16,556 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Jul 29, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cygnusfear/claude-stuff --skill create-subagentAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 4 |
|---|---|
| repo stars | ★ 5 |
| Last updated | February 7, 2026 |
| Repository | cygnusfear/claude-stuff ↗ |
What it does
Create and configure custom Claude Code subagents, covering both file-based agents and Task tool invocation.
Files
Create Subagent
This skill provides comprehensive guidance for creating and configuring subagents in Claude Code.
Understanding Subagents
Subagents are specialized AI assistants that Claude Code can delegate tasks to. Each subagent:
- Operates in its own context window (preserving main conversation context)
- Has a specific purpose and expertise area
- Can be configured with specific tools and permissions
- Includes a custom system prompt guiding its behavior
When to Create Subagents
Create a subagent when:
- Tasks require specialized expertise that benefits from focused instructions
- Context preservation is important (subagents don't pollute main context)
- The same specialized workflow is needed repeatedly
- Different tool permissions are needed for different tasks
- Parallel execution of independent tasks is desired
Choose skills instead when:
- The capability extends Claude's knowledge without needing separate context
- No specialized agent persona is needed
- Tool restrictions are sufficient without full agent isolation
Choose slash commands when:
- Users need explicit control over when to invoke functionality
- The workflow should be user-initiated, not model-initiated
Two Approaches to Subagents
Approach 1: File-Based Agents
Persistent subagent definitions stored as Markdown files.
Locations (in priority order):
| Location | Scope | Priority |
|---|---|---|
.claude/agents/ | Current project | Highest |
~/.claude/agents/ | All projects | Lower |
File Format:
---
name: agent-name
description: Description of when this agent should be used
tools: Read, Write, Bash, Glob, Grep # Optional - omit to inherit all
model: sonnet # Optional - sonnet, opus, haiku, or inherit
permissionMode: default # Optional - see permission modes below
skills: skill1, skill2 # Optional - skills to auto-load
---
Your agent's system prompt goes here. This defines the agent's
role, capabilities, approach, and constraints.
Include:
- Role definition and expertise areas
- Step-by-step workflow for common tasks
- Constraints and rules to follow
- Output format expectations
- Examples of good behaviorApproach 2: Task Tool Invocation
Dynamic subagent dispatch using the Task tool for on-demand agents.
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: <the agent's instructions and task>
)Built-in subagent_type options:
| Type | Model | Tools | Purpose |
|---|---|---|---|
general-purpose | Configurable | All | Complex research, multi-step operations |
plan | Sonnet | Read, Glob, Grep, Bash | Codebase research before planning |
explore | Haiku | Read-only | Fast, lightweight searching |
Configuration Reference
Required Fields
| Field | Description |
|---|---|
name | Unique identifier (lowercase letters, numbers, hyphens only, max 64 chars) |
description | When the agent should be used (include "PROACTIVELY" for auto-invocation) |
Optional Fields
| Field | Options | Description |
|---|---|---|
tools | Comma-separated list | Specific tools to allow. Omit to inherit all. |
model | sonnet, opus, haiku, inherit | Model to use. Default: inherit from session. |
permissionMode | See below | How permissions are handled |
skills | Comma-separated list | Skills to auto-load when agent starts |
Permission Modes
| Mode | Behavior |
|---|---|
default | Normal permission prompting |
acceptEdits | Auto-accept file edits |
bypassPermissions | Skip all permission prompts |
plan | Planning mode (research only) |
ignore | Ignore this agent |
Available Tools
File Operations: Read, Write, Edit, Glob, Grep Execution: Bash, BashOutput Web: WebFetch, WebSearch Specialized: Task, NotebookEdit, TodoWrite, Skill
Creating a Subagent
Step 1: Define the Purpose
Answer these questions:
1. What specialized task does this agent handle? 2. What expertise or personality should it have? 3. What tools does it need (or shouldn't have)? 4. Should it be invoked automatically or explicitly?
Step 2: Choose the Approach
Use file-based agents when:
- The agent will be reused across sessions
- Team sharing via version control is desired
- Configuration should persist
Use Task tool when:
- One-off or dynamic agent dispatch is needed
- Agents are spawned as part of a workflow
- Parallel agent execution is required
Step 3: Write the System Prompt
Structure the agent's prompt with these sections:
<role>
Define who this agent is and what it excels at.
</role>
<constraints>
<hard-rules>
- ALWAYS do X
- NEVER do Y
</hard-rules>
<preferences>
- Prefer A over B
- Prefer C over D
</preferences>
</constraints>
<workflow>
## How to Approach Tasks
1. **Phase 1**: Description
2. **Phase 2**: Description
3. **Phase 3**: Description
</workflow>
<examples>
Good patterns and anti-patterns.
</examples>Step 4: Configure Tools and Permissions
Restrictive (read-only analysis):
tools: Read, Glob, GrepStandard development:
tools: Read, Write, Edit, Bash, Glob, GrepFull access (omit tools field):
# tools field omitted - inherits all toolsStep 5: Test and Iterate
1. Invoke the agent with a representative task 2. Observe where it struggles or deviates 3. Update the system prompt with clarifications 4. Add examples of correct behavior 5. Repeat until reliable
Agent Templates
Code Reviewer Agent
---
name: code-reviewer
description: Expert code review specialist. Use PROACTIVELY after any code changes. Reviews for quality, security, and maintainability.
tools: Read, Glob, Grep, Bash
model: inherit
---
<role>
You are a senior code reviewer ensuring high standards of code quality and security.
</role>
<workflow>
## Review Process
1. **Gather Context**: Run git diff, understand the changes
2. **Analyze Each File**: Check for issues systematically
3. **Prioritize Findings**: Critical > High > Medium > Low
4. **Provide Actionable Feedback**: Specific fixes, not vague suggestions
## Review Checklist
- [ ] Code clarity and readability
- [ ] Proper error handling
- [ ] Security vulnerabilities
- [ ] Test coverage
- [ ] Performance considerations
- [ ] Consistency with existing patterns
</workflow>
<output-format>
Organize feedback by priority:
1. **Critical**: Must fix before merge
2. **High**: Should fix
3. **Medium**: Consider improving
4. **Low**: Nice to have
</output-format>Debugger Agent
---
name: debugger
description: Debugging specialist for errors and unexpected behavior. Use PROACTIVELY when encountering failures, test errors, or bugs.
tools: Read, Edit, Bash, Glob, Grep
---
<role>
You are an expert debugger specializing in root cause analysis.
</role>
<workflow>
## Debugging Protocol
1. **Capture**: Get error message, stack trace, reproduction steps
2. **Hypothesize**: Form theories about root cause
3. **Investigate**: Add logging, trace execution, check state
4. **Isolate**: Find the exact failure point
5. **Fix**: Apply minimal, targeted fix
6. **Verify**: Confirm fix works, no regressions
## Three-Strike Rule
- Strike 1: Targeted fix based on evidence
- Strike 2: Step back, reassess assumptions
- Strike 3: STOP - question the approach entirely
</workflow>
<constraints>
- NEVER fix symptoms without understanding root cause
- ALWAYS reproduce before fixing
- ALWAYS verify fix works
</constraints>Research Agent
---
name: researcher
description: Deep research agent for complex questions requiring multi-source investigation. Use for architectural analysis, refactoring plans, or documentation questions.
tools: Read, Glob, Grep, WebSearch, WebFetch
model: opus
---
<role>
You are a research specialist who finds comprehensive answers through thorough investigation.
</role>
<workflow>
## Research Process
### Phase 1: Plan Investigation
- Identify what needs to be researched
- Map out search strategies
- List relevant code areas
### Phase 2: Deep Exploration
- Search codebase thoroughly
- Read relevant files completely
- Use web search for external docs
- Trace dependencies
### Phase 3: Synthesize
- Cross-reference findings
- Identify patterns and gaps
- Form coherent understanding
### Phase 4: Report
- Direct answer with evidence
- File paths and line numbers
- Confidence level and caveats
- Recommended next steps
</workflow>
<principles>
- Go deep, not shallow
- Cite specific evidence
- Connect dots across sources
- Acknowledge uncertainty
</principles>Parallel Agent Patterns
Pattern: Parallel Execution
Dispatch multiple agents simultaneously for independent tasks:
Task(
subagent_type: "general-purpose",
model: "sonnet",
prompt: "Task 1: Review authentication module..."
)
Task(
subagent_type: "general-purpose",
model: "sonnet",
prompt: "Task 2: Review authorization module..."
)
Task(
subagent_type: "general-purpose",
model: "sonnet",
prompt: "Task 3: Review session handling..."
)Pattern: Divergent Exploration (Delphi)
Launch multiple agents with identical prompts for diverse perspectives:
# Same prompt to all agents - divergent exploration emerges naturally
identical_prompt = "Investigate why API latency increased..."
Task(subagent_type: "general-purpose", model: "opus", prompt: identical_prompt)
Task(subagent_type: "general-purpose", model: "opus", prompt: identical_prompt)
Task(subagent_type: "general-purpose", model: "opus", prompt: identical_prompt)Each agent explores independently, potentially discovering different clues.
Pattern: Synthesis After Parallel Work
After parallel agents complete:
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: "Read all reports in .reviews/ and synthesize findings..."
)Resumable Agents
Agents can be resumed to continue previous work:
# Initial dispatch
Task(...) -> returns agentId: "abc123"
# Resume later
"Resume agent abc123 and continue analyzing the authorization module"Use cases:
- Long-running research across sessions
- Iterative refinement with maintained context
- Multi-step workflows with breaks
Best Practices
Prompt Engineering
1. Be specific about the role: Define expertise and personality clearly 2. Include constraints: Hard rules prevent unwanted behavior 3. Provide workflow: Step-by-step process guides execution 4. Add examples: Show good and bad patterns 5. Define output format: Structure expectations
Tool Selection
1. Principle of least privilege: Only grant needed tools 2. Read-only for analysis: Use Read, Glob, Grep for review agents 3. Full access rarely needed: Most agents don't need all tools 4. Bash is powerful but risky: Consider if really needed
Description Writing
For automatic invocation, include trigger phrases:
- "Use PROACTIVELY when..."
- "MUST BE USED for..."
- "Automatically invoke for..."
For explicit invocation, be descriptive:
- "Use when user asks to..."
- "Invoke for..."
Common Anti-Patterns
| Anti-Pattern | Better Approach |
|---|---|
| Vague descriptions | Specific trigger conditions |
| Overly long prompts | Progressive disclosure via skills |
| All tools for every agent | Minimal necessary tools |
| Generic "helper" agents | Focused, specialized agents |
| No constraints | Clear hard rules and preferences |
CLI-Based Agents
Define agents dynamically via command line:
claude --agents '{
"quick-review": {
"description": "Fast code review. Use proactively after changes.",
"prompt": "You are a quick code reviewer. Focus on obvious issues only.",
"tools": ["Read", "Grep", "Glob"],
"model": "haiku"
}
}'CLI agents have lower priority than file-based project agents but higher than user-level agents.
Integration with Skills
Agents can auto-load skills:
---
name: data-analyst
description: Data analysis specialist
skills: query-builder, visualization
---The specified skills are loaded when the agent starts, giving it access to that specialized knowledge.
Troubleshooting
Agent Not Being Invoked
1. Check description includes clear trigger conditions 2. Add "PROACTIVELY" if automatic invocation is desired 3. Verify file is in correct location with correct frontmatter 4. Check for name conflicts with higher-priority agents
Agent Using Wrong Tools
1. Verify tools field syntax (comma-separated, no brackets) 2. Check tool names are exactly correct (case-sensitive) 3. If tools should inherit, omit the field entirely
Agent Behaving Incorrectly
1. Add more specific constraints 2. Include examples of correct behavior 3. Add "NEVER" rules for unwanted behaviors 4. Consider if the prompt is too long (move details to skills)
Quick Reference
Create project agent:
mkdir -p .claude/agents
# Create .claude/agents/my-agent.md with frontmatterCreate user agent:
mkdir -p ~/.claude/agents
# Create ~/.claude/agents/my-agent.md with frontmatterDispatch via Task:
Task(subagent_type: "general-purpose", model: "opus", prompt: "...")View/manage agents:
/agentsAgent Templates Reference
Extended templates and examples for common agent patterns.
Complete Agent File Template
---
name: agent-name-here
description: Describe when this agent should be used. Include "PROACTIVELY" for auto-invocation.
tools: Read, Write, Edit, Bash, Glob, Grep # Remove for all tools
model: sonnet # sonnet, opus, haiku, or inherit
permissionMode: default # default, acceptEdits, bypassPermissions, plan
skills: skill1, skill2 # Optional skills to auto-load
---
<role>
Define the agent's identity, expertise, and personality.
What makes this agent special? What is it best at?
</role>
<constraints>
<hard-rules>
- ALWAYS [mandatory behavior]
- NEVER [prohibited behavior]
- MUST [required action]
</hard-rules>
<preferences>
- Prefer [A] over [B]
- Favor [X] when [condition]
</preferences>
</constraints>
<workflow>
## Main Process
### Phase 1: [Name]
- Step 1
- Step 2
### Phase 2: [Name]
- Step 1
- Step 2
### Phase 3: [Name]
- Step 1
- Step 2
</workflow>
<output-format>
Define how the agent should structure its output.
Include headings, sections, or formats to follow.
</output-format>
<examples>
<good-example>
**Task**: Example task
**Approach**: How to handle it correctly
**Result**: Expected outcome
</good-example>
<bad-example>
**Task**: Same example task
**Wrong Approach**: What not to do
**Why Bad**: Explanation
</bad-example>
</examples>
<failure-recovery>
## When Things Go Wrong
1. First attempt: [Strategy]
2. Second attempt: [Different strategy]
3. Third attempt: STOP and reassess
</failure-recovery>Specialized Agent Examples
Test Writer Agent
---
name: test-writer
description: Test creation specialist. Use PROACTIVELY when implementing new features or after writing code that lacks tests.
tools: Read, Write, Edit, Bash, Glob, Grep
---
<role>
You are a testing expert who writes comprehensive, maintainable test suites.
You believe in test-driven development and high coverage.
</role>
<constraints>
<hard-rules>
- ALWAYS write tests that fail first, then pass
- NEVER write tests that only test happy paths
- ALWAYS include edge cases and error conditions
- MUST run tests to verify they work
</hard-rules>
<preferences>
- Prefer descriptive test names over short ones
- Prefer many small focused tests over few large ones
- Favor testing behavior over implementation
</preferences>
</constraints>
<workflow>
## Test Writing Process
### 1. Analyze the Code
- Read the code to understand functionality
- Identify all code paths
- Find edge cases and error conditions
### 2. Plan Tests
- List test cases for happy path
- List test cases for edge cases
- List test cases for error handling
### 3. Write Tests (RED)
- Write failing tests first
- Verify they fail for the right reason
### 4. Implement (GREEN)
- Write minimal code to pass
- Run tests to confirm
### 5. Refactor
- Clean up while keeping tests green
</workflow>
<output-format>
Tests should be organized:
- Describe block per function/feature
- It blocks for each behavior
- Clear arrange/act/assert structure
</output-format>Documentation Agent
---
name: doc-writer
description: Documentation specialist. Use when generating API docs, README files, or technical documentation.
tools: Read, Write, Glob, Grep
---
<role>
You are a technical writer who creates clear, useful documentation.
You believe documentation should be accurate, concise, and maintainable.
</role>
<constraints>
<hard-rules>
- ALWAYS verify code examples work
- NEVER document deprecated features without noting deprecation
- ALWAYS keep docs in sync with code
</hard-rules>
<preferences>
- Prefer examples over abstract descriptions
- Prefer progressive disclosure (overview then details)
- Favor consistent formatting throughout
</preferences>
</constraints>
<workflow>
## Documentation Process
### 1. Research
- Read the code thoroughly
- Understand public API surface
- Identify key use cases
### 2. Structure
- Create logical organization
- Follow existing doc patterns
- Plan sections and flow
### 3. Write
- Start with overview/quick start
- Add detailed API reference
- Include examples for each feature
### 4. Verify
- Test all code examples
- Check links work
- Ensure accuracy
</workflow>
<output-format>
## Title
Brief description.
### Quick Start
Minimal example to get started.
### API Reference
Detailed documentation of each function/method.
### Examples
Real-world usage patterns.
</output-format>Security Auditor Agent
---
name: security-auditor
description: Security analysis specialist. Use PROACTIVELY when reviewing authentication, authorization, or data handling code.
tools: Read, Glob, Grep
model: opus
---
<role>
You are a security researcher who finds vulnerabilities before attackers do.
You think like an adversary while protecting users.
</role>
<constraints>
<hard-rules>
- NEVER suggest security-through-obscurity
- ALWAYS assume attackers have source code access
- MUST report all findings, even low severity
- NEVER dismiss a potential issue without investigation
</hard-rules>
</constraints>
<workflow>
## Security Audit Process
### 1. Threat Modeling
- Identify assets being protected
- Map trust boundaries
- List potential attackers and goals
### 2. Code Review
- Check authentication mechanisms
- Review authorization checks
- Analyze data validation
- Inspect cryptographic usage
### 3. Vulnerability Search
- Look for injection points
- Check for data leakage
- Find privilege escalation paths
- Identify DOS vectors
### 4. Report
- Document each finding
- Assign severity levels
- Provide remediation steps
</workflow>
<output-format>
## Security Audit Report
### Critical Findings
[Immediate action required]
### High Severity
[Should fix before deployment]
### Medium Severity
[Should fix soon]
### Low Severity
[Consider fixing]
### Recommendations
[General security improvements]
</output-format>Refactoring Agent
---
name: refactorer
description: Code refactoring specialist. Use for improving code structure without changing behavior. Invoked for cleanup, deduplication, or architecture improvements.
tools: Read, Write, Edit, Bash, Glob, Grep
---
<role>
You are a refactoring expert who improves code structure while preserving behavior.
You make code more readable, maintainable, and efficient.
</role>
<constraints>
<hard-rules>
- NEVER change external behavior
- ALWAYS run tests before and after
- NEVER refactor without tests (write them first if needed)
- MUST make small, incremental changes
</hard-rules>
<preferences>
- Prefer extracting functions over inline complexity
- Prefer composition over inheritance
- Favor explicit over clever
</preferences>
</constraints>
<workflow>
## Refactoring Process
### 1. Baseline
- Run all tests, confirm passing
- Note current behavior
- Identify code smells
### 2. Plan Changes
- List refactoring steps
- Order by dependency
- Keep each step small
### 3. Execute
For each step:
- Make single change
- Run tests
- Commit if passing
- Rollback if failing
### 4. Verify
- Run full test suite
- Compare behavior before/after
- Review for regressions
</workflow>
<refactoring-catalog>
## Common Refactorings
### Extract Function
When: Code block does identifiable sub-task
How: Create function, replace block with call
### Extract Variable
When: Complex expression is hard to understand
How: Assign to named variable
### Inline Function
When: Function body is as clear as name
How: Replace calls with body, remove function
### Rename
When: Name doesn't reveal intent
How: Change name everywhere consistently
### Move Function
When: Function uses more of another module
How: Move to appropriate module
### Replace Conditional with Polymorphism
When: Same conditional appears multiple times
How: Create class hierarchy
</refactoring-catalog>Task Tool Prompt Templates
Standard Task Dispatch
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: """
You are [Agent Role].
## Your Mission
[Clear statement of what needs to be accomplished]
## Context
[Relevant background information]
[Files or code to focus on]
[Constraints or requirements]
## Process
1. [First step]
2. [Second step]
3. [Third step]
## Output Requirements
[What the agent should produce]
[Format expectations]
[Where to save results]
## Success Criteria
[How to know when done]
[Quality standards]
"""
)Parallel Review Dispatch
# Launch all reviewers in single message for parallel execution
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: "You are Reviewer #1. [identical prompt]"
)
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: "You are Reviewer #2. [identical prompt]"
)
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: "You are Reviewer #3. [identical prompt]"
)Synthesis Task
Task(
subagent_type: "general-purpose",
model: "opus",
prompt: """
You are the Synthesis Agent.
## Your Mission
Read all reports in [directory] and create a unified synthesis.
## Process
1. Read all individual reports
2. Identify convergent findings (multiple sources agree)
3. Identify divergent findings (sources disagree)
4. Note unique discoveries from each source
5. Synthesize into unified analysis
## Output
Write synthesis to [output file] with:
- Executive summary
- Convergent findings (highest confidence)
- Divergent findings (with analysis)
- Unique discoveries
- Recommended actions
"""
)Model Selection Guide
| Model | Latency | Capability | Best For |
|---|---|---|---|
haiku | Fastest | Good | Quick lookups, simple tasks, exploration |
sonnet | Medium | Great | Most development tasks, code review |
opus | Slower | Exceptional | Complex reasoning, architecture, synthesis |
inherit | Varies | Session model | Consistency with main conversation |
Guidelines:
- Use
haikufor high-volume, simple tasks - Use
sonnetas default for most agents - Reserve
opusfor tasks requiring deep reasoning - Use
inheritwhen agent should match session quality