Complete specification for Claude Code agent frontmatter fields (January 2026).
Documents Claude Code agent configuration fields and validation rules for custom subagents.
/plugin marketplace add jamie-bitflight/claude_skills/plugin install plugin-creator@jamie-bitflight-skillsagent-creator/references/Complete specification for Claude Code agent frontmatter fields (January 2026).
For plugin agent integration, see Claude Plugins Reference
name: code-reviewer # Good
name: Code_Reviewer # Invalid - uppercase, underscores
name: my-super-awesome-long-agent-name-that-exceeds-the-limit # Invalid - too long
Follow the official Anthropic guidance in the write-frontmatter-description skill.
Must be complete and informative, explaining what the agent does and when to use it. Include trigger scenarios, file types, or tasks.
# Good - complete and informative
description: 'Review Python code for security vulnerabilities, performance issues, and PEP 8 compliance. Handles code reviews after changes complete or when reviewing pull requests. Specializes in async/await patterns.'
# Bad - too vague
description: Helps with Python
Do NOT use YAML multiline indicators (>-, |, |-) for descriptions. Claude Code's indexer does not parse them correctly - the description appears as ">-" instead of actual content.
# WRONG - will show ">-" as description
description: >-
This is a multiline
description that breaks.
# CORRECT - single quoted string
description: 'This works correctly. Use single quotes for descriptions with special characters or keep on one line.'
sonnet, opus, haiku, inherit| Value | Use Case |
|---|---|
haiku | Fast, simple operations (search, read) |
sonnet | Balanced - most agents (default) |
opus | Complex reasoning, difficult debugging |
inherit | Match parent conversation model |
model: sonnet
model: inheritThe inherit option makes the agent use the same model as the parent conversation rather than a fixed model.
Use model: inherit when:
Context-appropriate capability - Agent should match user's model choice
User-controlled cost/capability trade-off - Let user decide model via conversation settings
Flexible workflows - Agent is used in multiple contexts with different needs
Use explicit model (sonnet, opus, haiku) when:
Task requires specific capability - Agent needs minimum model capability
opushaikuCost control - Prevent unexpected high costs
haiku even if parent uses OpusConsistent behavior - Agent must perform the same way every time
Decision Tree:
Does the task REQUIRE a specific model capability?
├─ Yes → Use explicit model (opus/sonnet/haiku)
└─ No → Should the agent adapt to user's choice?
├─ Yes → Use `inherit`
└─ No → Use `sonnet` (safe default)
Examples:
# Inherit - adapts to conversation context
name: general-helper
model: inherit
description: Helps with various tasks matching conversation complexity
# Explicit Haiku - always fast and cheap
name: file-searcher
model: haiku
description: Search files for patterns (simple task)
# Explicit Opus - always maximum capability
name: architecture-reviewer
model: opus
description: Review system architecture for flaws (complex task)
# Explicit Sonnet - balanced default
name: code-writer
model: sonnet
description: Write production code (moderate complexity)
# CORRECT: comma-separated string format
tools: Read, Grep, Glob, Bash
# Pattern matching for specific commands
tools: Bash(git:*), Bash(npm:install)
Available Tools: Read, Write, Edit, Bash, Grep, Glob, NotebookEdit, AskUserQuestion, WebSearch, Task, ToolSearch, Skill
Note: MCP tools from installed servers are also available and follow pattern mcp__server-name__tool-name
Pattern Matching Examples:
# Allow only specific git commands
tools: Bash(git:status), Bash(git:log), Bash(git:diff)
# Allow git read operations only
tools: Bash(git:status|log|diff|show)
# Allow all git commands
tools: Bash(git:*)
# Combine with other tools
tools: Read, Grep, Bash(git:*), Bash(npm:install)
disallowedTools: Write, Edit, Bash
default| Mode | File Edits | Bash Commands | Description |
|---|---|---|---|
default | Prompts user | Prompts user | Normal permission behavior |
acceptEdits | Auto-accepts | Prompts destructive | Good for documentation |
dontAsk | Auto-denies | Auto-denies | Read-only operation |
bypassPermissions | Skips all | Skips all | Dangerous - trusted only |
plan | Disabled | Disabled | Planning mode, no writes |
permissionMode: acceptEdits
# CORRECT: comma-separated string
skills: python-development, testing-patterns, security-best-practices
Important: Agents do NOT inherit skills from parent conversation. Must explicitly list needed skills.
hooks:
PreToolUse:
- matcher: "Bash"
hooks:
- type: command
command: "./scripts/validate.sh"
timeout: 5000
PostToolUse:
- matcher: "Write|Edit"
hooks:
- type: command
command: "./scripts/lint.sh"
Stop:
- hooks:
- type: command
command: "./scripts/cleanup.sh"
Hook Events:
PreToolUse - Before tool executes (can block with exit 2)PostToolUse - After tool succeedsPostToolUseFailure - After tool failsPermissionRequest - When permission neededUserPromptSubmit - When user submits promptNotification - When notifications are sentStop - When agent completesSubagentStart - When child agent startsSubagentStop - When child agent completesSetup - During initializationSessionStart - At session beginningSessionEnd - At session endPreCompact - Before conversation compactionFor complete hook reference, see Claude Hooks Reference
Notes:
https://code.claude.com/docs/en/sub-agents.mdcolor: cyan # Analysis agents
color: yellow # Warning/optimization
color: green # Success/validation
color: orange # Audit/review
color: red # Error handling
argumentHint: '<file-path> [options]'
alwaysLoadSkills: true
---
name: security-auditor
description: 'Audit code for security vulnerabilities including OWASP Top 10, injection risks, and authentication flaws. Use when reviewing security-sensitive code or before production deployment. Proactively invoked after changes to auth or data handling code.'
model: opus
tools: Read, Grep, Glob, Bash(git:log), Bash(git:diff)
disallowedTools: Write, Edit
permissionMode: dontAsk
skills: security-best-practices, owasp-guidelines
hooks:
Stop:
- hooks:
- type: command
command: "./scripts/log-audit.sh"
color: red
---
When creating agents for plugins, additional considerations apply:
Location: {plugin-root}/agents/ directory
Registration: Agents must be listed in plugin.json:
{
"name": "my-plugin",
"agents": ["./agents/security-reviewer.md", "./agents/code-formatter.md"]
}
Important: The agents field in plugin.json must be an array of individual file paths, NOT a directory string:
// CORRECT
"agents": ["./agents/reviewer.md", "./agents/tester.md"]
// INCORRECT - will fail validation
"agents": "./agents/"
Validation: After creating plugin agents:
# Validate frontmatter
uv run plugins/plugin-creator/scripts/validate_frontmatter.py validate ./agents/my-agent.md
# Validate complete plugin
claude plugin validate ./path/to/plugin
For complete plugin reference, see Claude Plugins Reference
Before saving an agent, verify:
name
description
model (if specified)
tools (if specified)
skills (if specified)
permissionMode (if specified)
YAML syntax
>-, |-) in description fieldUse the validation script for comprehensive checks:
# Validate single agent
uv run plugins/plugin-creator/scripts/validate_frontmatter.py validate ./agents/my-agent.md
# Auto-fix common issues (dry-run first)
uv run plugins/plugin-creator/scripts/validate_frontmatter.py fix ./agents/my-agent.md --dry-run
# Batch validation
uv run plugins/plugin-creator/scripts/validate_frontmatter.py batch ./agents/
# Batch fix
uv run plugins/plugin-creator/scripts/validate_frontmatter.py fix-batch ./agents/
What the validator checks:
What the validator auto-fixes:
SOURCE: validate_frontmatter.py lines 103-187