Search

PythonReactSEOPDF
GitHub Skill

creating-subagents

Guide for creating custom Claude Code subagents (Task tool agents). Use when building specialized autonomous agents for specific domains or workflows. Covers agent definition, frontmatter options, tool restrictions, and spawning patterns.

hgeldenhuys☆ 2 Repository stars0 Repository forks

Installation

Follow the repository instructions for this skill and your agent. Review the files and dependencies before adding it to your workflow.

View source ↗Guides

Skill instructions

Creating Subagents

Build specialized AI agents for Claude Code that handle domain-specific tasks with custom configurations, tools, and system prompts.

Quick Reference

Element Requirement
Location .claude/agents/ (project) or ~/.claude/agents/ (user)
Filename agent-name.md
Name Lowercase, hyphens only (e.g., code-reviewer)
Required Fields name, description
Optional Fields tools, model, permissionMode, skills, hooks

What Are Subagents?

Subagents are specialized AI assistants that Claude Code delegates tasks to. They provide:

  • Separate Context - Own context window, prevents main conversation pollution
  • Custom Tools - Restricted or expanded tool access
  • Specialized Prompts - Domain-specific instructions and expertise
  • Flexible Models - Can use different models (opus, sonnet, haiku)

When Claude encounters a task matching a subagent's expertise, it spawns the subagent via the Task tool, which works independently and returns results.

Built-in vs Custom Agents

Built-in Agents

Claude Code includes several built-in agents:

Agent Model Mode Purpose
Explore Haiku Read-only Fast codebase search and analysis
Plan Inherits Read-only Research for plan mode
General-purpose Inherits Read/Write Complex multi-step tasks
Bash Inherits Commands Running terminal commands in separate context
statusline-setup Sonnet Config Configuring status line via /statusline
Claude Code Guide Haiku Read-only Answering questions about Claude Code features
When to Create Custom Agents

Create custom agents when you need:

  • Domain expertise - Security audit, database migration, API design
  • Workflow automation - Test runner, deployment, documentation
  • Tool restrictions - Read-only reviewers, sandboxed explorers
  • Team consistency - Shared agents for common workflows

Agent Definition Structure

Agents are Markdown files with YAML frontmatter:

---
name: agent-name
description: When this agent should be invoked
tools: Tool1, Tool2, Tool3
model: sonnet
permissionMode: default
skills: skill1, skill2
---

System prompt content here.

Detailed instructions for the agent's behavior,
expertise area, and approach to problem-solving.

Frontmatter Fields

Field Required Type Description
name Yes string Unique identifier (lowercase, hyphens)
description Yes string When to invoke (include "PROACTIVELY" for auto-use)
tools No string Comma-separated tool list (allowlist). Omit to inherit all tools
disallowedTools No string Comma-separated tools to deny (denylist), removed from inherited list
model No string sonnet, opus, haiku, or inherit
permissionMode No string Permission handling mode
skills No string Skills to load into subagent's context at startup
hooks No object Agent-scoped hooks (2.1.0+)

Note on skills: The full skill content is injected into the subagent, not just made available for invocation. Subagents don't inherit skills from the parent conversation.

Model Options
Value Description
sonnet Default. Balanced capability and speed
opus Most capable. Use for complex reasoning
haiku Fastest. Use for simple, quick tasks
inherit Use main conversation's model
Permission Modes

Subagents inherit permission context from the main conversation but can override the mode.

Mode Description
default Standard permission checking with prompts
acceptEdits Auto-accept file edits
dontAsk Auto-deny permission prompts (explicitly allowed tools still work)
bypassPermissions Skip all permission checks (use with caution)
plan Plan mode (read-only exploration)

Important: If the parent uses bypassPermissions, this takes precedence and cannot be overridden by subagents.

Critical Constraint

Subagents cannot spawn other subagents. This prevents infinite nesting. Design your agents to be self-contained.

Hooks in Agent Frontmatter (2.1.0+)

Agents can define hooks scoped to their lifecycle. These hooks are:

  • Lifecycle-scoped - Only active while the agent executes
  • Auto-cleanup - Removed when the agent finishes
  • Portable - Packaged with the agent for distribution
---
name: secure-agent
description: Security-focused agent with audit logging
hooks:
  PreToolUse:
    - matcher: "Bash|Write|Edit"
      hooks:
        - type: command
          command: "$CLAUDE_PROJECT_DIR/.claude/hooks/audit-log.sh"
  Stop:
    - hooks:
        - type: command
          command: "$CLAUDE_PROJECT_DIR/.claude/hooks/agent-complete.sh"
---

Supported hook events in agent frontmatter:

  • PreToolUse - Before tool execution
  • PostToolUse - After tool completion
  • Stop - When agent finishes
Conditional Rules with Hooks

For dynamic control over tool usage, use PreToolUse hooks to validate operations. This is useful when you need to allow some operations of a tool while blocking others.

Example: Read-only database agent

---
name: db-reader
description: Execute read-only database queries
tools: Bash
hooks:
  PreToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "./scripts/validate-readonly-query.sh"
---

The validation script reads JSON from stdin, extracts the command, and exits with code 2 to block:

#!/bin/bash
# ./scripts/validate-readonly-query.sh

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Block SQL write operations (case-insensitive)
if echo "$COMMAND" | grep -iE '\b(INSERT|UPDATE|DELETE|DROP|CREATE|ALTER|TRUNCATE)\b' > /dev/null; then
  echo "Blocked: Only SELECT queries are allowed" >&2
  exit 2
fi

exit 0

Hook exit codes:

  • 0 - Allow operation
  • 2 - Block operation (with message to stderr)

Creating an Agent

Via /agents Command (Recommended)
/agents

Interactive interface to:

  • View all available subagents (built-in, user, project, plugin)
  • Create new subagents with guided setup or Claude generation
  • Edit existing subagent configuration and tool access
  • Delete custom subagents
  • See active subagents when duplicates exist (higher priority wins)

Generate with Claude: Select "Generate with Claude" and describe your subagent. Claude generates the system prompt and configuration. Press e to open in your editor.

Via File Creation
# Project agent
mkdir -p .claude/agents
cat > .claude/agents/test-runner.md << 'EOF'
---
name: test-runner
description: Run tests and fix failures. Use PROACTIVELY after code changes.
tools: Bash, Read, Glob, Grep, Edit
---

You are a test automation expert.

When invoked:
1. Identify test files related to changes
2. Run appropriate test suite
3. Analyze failures
4. Fix issues while preserving test intent
5. Re-run to verify fixes

Test frameworks to check:
- Jest/Vitest for TypeScript/JavaScript
- pytest for Python
- go test for Go
- cargo test for Rust

Always run tests before reporting completion.
EOF
Via CLI Flag
claude --agents '{
  "test-runner": {
    "description": "Run tests and fix failures",
    "prompt": "You are a test automation expert...",
    "tools": ["Bash", "Read", "Glob", "Grep", "Edit"],
    "model": "sonnet"
  }
}'

Using Agents

Automatic Delegation

Claude automatically delegates based on:

  • Task matching description field
  • Current context and available tools
  • Phrases like "PROACTIVELY" or "MUST BE USED"
Explicit Invocation
> Use the code-reviewer agent to check my changes
> Have the security-audit agent scan for vulnerabilities
> Ask the database-migration agent to create the schema
Chaining Agents
> First use test-runner to find failures, then have debugger fix them
Resuming Agents

Agents can be resumed to continue previous work:

> Resume agent abc123 and continue the analysis

Each execution gets a unique agentId stored in agent-{agentId}.jsonl.

Tool Restrictions

Read-Only Agent
tools: Read, Glob, Grep
Execution-Safe Agent
tools: Bash, Read, Glob, Grep

Note: Bash in this context is still full Bash. For truly safe execution, use hooks to validate commands.

Write-Capable Agent
tools: Read, Write, Edit, Bash, Glob, Grep
Inherit All Tools

Omit the tools field entirely to inherit all tools from main thread, including MCP tools.

Workflow: Creating a Custom Agent

Prerequisites
  • Identify the domain/expertise area
  • Determine required tools
  • Plan the system prompt
Steps
  1. Define the agent

    • Choose descriptive name (lowercase, hyphens)
    • Write clear description with trigger phrases
    • Select minimum necessary tools
    • Choose appropriate model
  2. Write system prompt

    • Define role and expertise
    • List step-by-step process
    • Include constraints and best practices
    • Add output format expectations
  3. Configure location

    • Project (.claude/agents/) for team sharing
    • User (~/.claude/agents/) for personal use
  4. Test

    • Invoke explicitly: "Use the X agent to..."
    • Check /agents menu for registration
    • Verify tool restrictions work
Validation
  • Name is lowercase with hyphens
  • Description explains when to use
  • Tools are minimum necessary
  • System prompt is clear and actionable

Priority Order

When agent names conflict, higher priority wins:

Priority Location Scope
1 (highest) --agents CLI flag Current session only
2 .claude/agents/ Current project
3 ~/.claude/agents/ All your projects
4 (lowest) Plugin's agents/ directory Where plugin is enabled

Project agents (.claude/agents/) are ideal for team sharing - check them into version control.

User agents (~/.claude/agents/) are personal agents available in all your projects.

CLI agents exist only for that session - useful for quick testing or automation scripts.

Disabling Specific Subagents

Disable built-in or custom subagents using permission rules or CLI flags.

Via settings.json
{
  "permissions": {
    "deny": ["Task(Explore)", "Task(Plan)"]
  }
}
Via CLI
claude --disallowedTools "Task(Explore)"
Permission Rule Syntax
Pattern Effect
Task(Explore) Disable built-in Explore agent
Task(Plan) Disable built-in Plan agent
Task(code-reviewer) Disable custom code-reviewer agent
Task(*) Disable all subagents
Use Cases
  • Security - Prevent delegation to agents with write access
  • Workflow control - Force specific agents for certain tasks
  • Debugging - Isolate main thread behavior without subagents
  • Cost management - Disable expensive opus-based agents
Example: Read-Only Mode

Disable all write-capable agents for safe exploration:

{
  "permissions": {
    "deny": ["Task(general-purpose)", "Task(code-reviewer)"],
    "allow": ["Task(Explore)"]
  }
}

Reference Files

File Contents
DEFINITION.md Complete frontmatter reference and file structure
EXAMPLES.md Real-world agent examples
PATTERNS.md Best practices and composition patterns

Examples

Read the usage examples in the source repository.

View source ↗

Source history

Indexed on
2026-01-20
Index updated
2026-01-30
Branch
main

Index and sync dates describe this directory. View the source repository for code history.

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!