agent-development
npx machina-cli add skill OshanKHZ/cc-swiss-knife/agent-development --openclawAgent Development for Claude Code Plugins
Overview
Agents are autonomous subprocesses that handle complex, multi-step tasks independently. Understanding agent structure, triggering conditions, and system prompt design enables creating powerful autonomous capabilities.
Key concepts:
- Agents are FOR autonomous work, commands are FOR user-initiated actions
- Markdown file format with YAML frontmatter
- Triggering via description field with examples
- System prompt defines agent behavior
- Model and color customization
Agent File Structure
Complete Format
---
name: agent-identifier
description: Use this agent when [triggering conditions]. Examples:
<example>
Context: [Situation description]
user: "[User request]"
assistant: "[How assistant should respond and use this agent]"
<commentary>
[Why this agent should be triggered]
</commentary>
</example>
<example>
[Additional example...]
</example>
model: inherit
color: blue
tools: ["Read", "Write", "Grep"]
---
You are [agent role description]...
**Your Core Responsibilities:**
1. [Responsibility 1]
2. [Responsibility 2]
**Analysis Process:**
[Step-by-step workflow]
**Output Format:**
[What to return]
Frontmatter Fields
name (required)
Agent identifier used for namespacing and invocation.
Format: lowercase, numbers, hyphens only Length: 3-50 characters Pattern: Must start and end with alphanumeric
Good examples:
code-reviewertest-generatorapi-docs-writersecurity-analyzer
Bad examples:
helper(too generic)-agent-(starts/ends with hyphen)my_agent(underscores not allowed)ag(too short, < 3 chars)
description (required)
Defines when Claude should trigger this agent. This is the most critical field.
Must include:
- Triggering conditions ("Use this agent when...")
- Multiple
<example>blocks showing usage - Context, user request, and assistant response in each example
<commentary>explaining why agent triggers
Format:
Use this agent when [conditions]. Examples:
<example>
Context: [Scenario description]
user: "[What user says]"
assistant: "[How Claude should respond]"
<commentary>
[Why this agent is appropriate]
</commentary>
</example>
[More examples...]
Best practices:
- Include 2-4 concrete examples
- Show proactive and reactive triggering
- Cover different phrasings of same intent
- Explain reasoning in commentary
- Be specific about when NOT to use the agent
model (required)
Which model the agent should use.
Options:
inherit- Use same model as parent (recommended)sonnet- Claude Sonnet (balanced)opus- Claude Opus (most capable, expensive)haiku- Claude Haiku (fast, cheap)
Recommendation: Use inherit unless agent needs specific model capabilities.
color (required)
Visual identifier for agent in UI.
Options: blue, cyan, green, yellow, magenta, red
Guidelines:
- Choose distinct colors for different agents in same plugin
- Use consistent colors for similar agent types
- Blue/cyan: Analysis, review
- Green: Success-oriented tasks
- Yellow: Caution, validation
- Red: Critical, security
- Magenta: Creative, generation
tools (optional)
Restrict agent to specific tools.
Format: Array of tool names
tools: ["Read", "Write", "Grep", "Bash"]
Default: If omitted, agent has access to all tools
Best practice: Limit tools to minimum needed (principle of least privilege)
Common tool sets:
- Read-only analysis:
["Read", "Grep", "Glob"] - Code generation:
["Read", "Write", "Grep"] - Testing:
["Read", "Bash", "Grep"] - Full access: Omit field or use
["*"]
hooks (optional)
Agent-level hooks scoped to agent lifecycle.
Format: Array of hook configurations
hooks:
- type: PreToolUse
once: true
- type: PostToolUse
- type: Stop
Supported hook types:
PreToolUse: Validate before agent uses toolsPostToolUse: React to agent's tool resultsStop: Cleanup when agent completes
When to use:
- Validation specific to agent operations
- Logging/tracking agent actions
- Setup/teardown within agent lifecycle
- Per-agent permission enforcement
Key features:
once: trueruns hook only once per agent invocation- Hooks inherit agent context
- No command/prompt field needed
Example use cases:
hooks:
- type: PreToolUse
once: true # One-time setup check for agent
- type: PostToolUse # React to every tool agent uses
- type: Stop # Cleanup when agent finishes
See ../hook-development/ for complete hooks documentation.
disallowedTools (optional)
Disable specific agents from being invoked.
Format: Array with Task(AgentName) syntax
disallowedTools: ["Task(SWEAgent)", "Task(ExperimentalAgent)"]
Use when:
- Preventing specific agents from running
- Testing without certain agents
- Security/policy enforcement
Note: Also configurable in settings.json and via --disallowedTools CLI flag.
System Prompt Design
The markdown body becomes the agent's system prompt. Write in second person, addressing the agent directly.
Structure
Standard template:
You are [role] specializing in [domain].
**Your Core Responsibilities:**
1. [Primary responsibility]
2. [Secondary responsibility]
3. [Additional responsibilities...]
**Analysis Process:**
1. [Step one]
2. [Step two]
3. [Step three]
[...]
**Quality Standards:**
- [Standard 1]
- [Standard 2]
**Output Format:**
Provide results in this format:
- [What to include]
- [How to structure]
**Edge Cases:**
Handle these situations:
- [Edge case 1]: [How to handle]
- [Edge case 2]: [How to handle]
Best Practices
✅ DO:
- Write in second person ("You are...", "You will...")
- Be specific about responsibilities
- Provide step-by-step process
- Define output format
- Include quality standards
- Address edge cases
- Keep under 10,000 characters
❌ DON'T:
- Write in first person ("I am...", "I will...")
- Be vague or generic
- Omit process steps
- Leave output format undefined
- Skip quality guidance
- Ignore error cases
Creating Agents
Method 1: AI-Assisted Generation
Use this prompt pattern (extracted from Claude Code):
Create an agent configuration based on this request: "[YOUR DESCRIPTION]"
Requirements:
1. Extract core intent and responsibilities
2. Design expert persona for the domain
3. Create comprehensive system prompt with:
- Clear behavioral boundaries
- Specific methodologies
- Edge case handling
- Output format
4. Create identifier (lowercase, hyphens, 3-50 chars)
5. Write description with triggering conditions
6. Include 2-3 <example> blocks showing when to use
Return JSON with:
{
"identifier": "agent-name",
"whenToUse": "Use this agent when... Examples: <example>...</example>",
"systemPrompt": "You are..."
}
Then convert to agent file format with frontmatter.
See examples/agent-creation-prompt.md for complete template.
Method 2: Manual Creation
- Choose agent identifier (3-50 chars, lowercase, hyphens)
- Write description with examples
- Select model (usually
inherit) - Choose color for visual identification
- Define tools (if restricting access)
- Write system prompt with structure above
- Save as
agents/agent-name.md
Validation Rules
Identifier Validation
✅ Valid: code-reviewer, test-gen, api-analyzer-v2
❌ Invalid: ag (too short), -start (starts with hyphen), my_agent (underscore)
Rules:
- 3-50 characters
- Lowercase letters, numbers, hyphens only
- Must start and end with alphanumeric
- No underscores, spaces, or special characters
Description Validation
Length: 10-5,000 characters Must include: Triggering conditions and examples Best: 200-1,000 characters with 2-4 examples
System Prompt Validation
Length: 20-10,000 characters Best: 500-3,000 characters Structure: Clear responsibilities, process, output format
Agent Organization
Plugin Agents Directory
plugin-name/
└── agents/
├── analyzer.md
├── reviewer.md
└── generator.md
All .md files in agents/ are auto-discovered.
Namespacing
Agents are namespaced automatically:
- Single plugin:
agent-name - With subdirectories:
plugin:subdir:agent-name
Testing Agents
Test Triggering
Create test scenarios to verify agent triggers correctly:
- Write agent with specific triggering examples
- Use similar phrasing to examples in test
- Check Claude loads the agent
- Verify agent provides expected functionality
Test System Prompt
Ensure system prompt is complete:
- Give agent typical task
- Check it follows process steps
- Verify output format is correct
- Test edge cases mentioned in prompt
- Confirm quality standards are met
Quick Reference
Minimal Agent
---
name: simple-agent
description: Use this agent when... Examples: <example>...</example>
model: inherit
color: blue
---
You are an agent that [does X].
Process:
1. [Step 1]
2. [Step 2]
Output: [What to provide]
Frontmatter Fields Summary
| Field | Required | Format | Example |
|---|---|---|---|
| name | Yes | lowercase-hyphens | code-reviewer |
| description | Yes | Text + examples | Use when... <example>... |
| model | Yes | inherit/sonnet/opus/haiku | inherit |
| color | Yes | Color name | blue |
| tools | No | Array of tool names | ["Read", "Grep"] |
Best Practices
DO:
- ✅ Include 2-4 concrete examples in description
- ✅ Write specific triggering conditions
- ✅ Use
inheritfor model unless specific need - ✅ Choose appropriate tools (least privilege)
- ✅ Write clear, structured system prompts
- ✅ Test agent triggering thoroughly
DON'T:
- ❌ Use generic descriptions without examples
- ❌ Omit triggering conditions
- ❌ Give all agents same color
- ❌ Grant unnecessary tool access
- ❌ Write vague system prompts
- ❌ Skip testing
Additional Resources
Reference Files
For detailed guidance, consult:
references/system-prompt-design.md- Complete system prompt patternsreferences/triggering-examples.md- Example formats and best practicesreferences/agent-creation-system-prompt.md- The exact prompt from Claude Code
Example Files
Working examples in examples/:
agent-creation-prompt.md- AI-assisted agent generation templatecomplete-agent-examples.md- Full agent examples for different use cases
Utility Scripts
Development tools in scripts/:
validate-agent.sh- Validate agent file structuretest-agent-trigger.sh- Test if agent triggers correctly
Implementation Workflow
To create an agent for a plugin:
- Define agent purpose and triggering conditions
- Choose creation method (AI-assisted or manual)
- Create
agents/agent-name.mdfile - Write frontmatter with all required fields
- Write system prompt following best practices
- Include 2-4 triggering examples in description
- Validate with
scripts/validate-agent.sh - Test triggering with real scenarios
- Document agent in plugin README
Focus on clear triggering conditions and comprehensive system prompts for autonomous operation.
Source
git clone https://github.com/OshanKHZ/cc-swiss-knife/blob/main/plugins/claude-code-forge/skills/agent-development/SKILL.mdView on GitHub Overview
This skill guides building autonomous agents for Claude Code plugins, covering structure, triggering logic, system prompts, and best practices. It explains frontmatter, tool access, color-coding, and how to design agents that can handle complex, multi-step tasks.
How This Skill Works
Agents are Markdown files with YAML frontmatter that define model, color, and tools. They trigger via the description field, which includes <example> blocks showing Context, user, assistant, and a commentary on why the agent is appropriate. The agent includes Core Responsibilities, an Analysis Process, and an Output Format to standardize behavior and results.
When to Use It
- When you need to create a new autonomous agent for a Claude Code plugin.
- When you are adding or rewriting a subagent or agent frontmatter.
- When you want to define triggering conditions via the description field with concrete examples.
- When configuring agent color and tools to match UI conventions and least-privilege access.
- When seeking guidance on agent structure, system prompts, triggering conditions, or development best practices.
Quick Start
- Step 1: Define the agent's goal, a unique name, and triggering conditions in the description frontmatter.
- Step 2: Specify model (prefer inherit), color, and a minimal tools list; add 2–4 <example> blocks illustrating use cases.
- Step 3: Outline Core Responsibilities, Analysis Process, and Output Format to guide behavior and outputs.
Best Practices
- Define 2–4 concrete <example> blocks showing different phrasings and scenarios.
- Be explicit about when NOT to trigger the agent to avoid false positives.
- Follow the complete frontmatter format (name, description, model, color, tools) and naming rules.
- Restrict tools to the minimum needed (principle of least privilege).
- Clearly document the Output Format and Analysis Process to ensure consistent results.
Example Use Cases
- An agent that reads a codebase and generates API documentation with examples.
- A subagent that validates and reformats user input before processing.
- An agent that selects UI colors and themes based on a given context.
- An agent triggered by error descriptions to propose fixes.
- An agent that converts user stories into structured, testable examples.