create-agent
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCreate Agent Command
创建Agent命令
Create autonomous Claude Code agents that handle complex, multi-step tasks independently. This command provides comprehensive guidance based on official Anthropic documentation and proven patterns.
创建可自主处理复杂多步骤任务的Claude Code Agent。本命令基于Anthropic官方文档和经过验证的模式提供全面指导。
User Input
用户输入
text
Agent Name: $1
Description: $2text
Agent名称: $1
描述: $2What Are Agents?
什么是Agent?
Agents are autonomous subprocesses spawned via the Task tool that:
- Handle complex, multi-step tasks independently
- Have their own isolated context window
- Return results to the parent conversation
- Can be specialized for specific domains
| Concept | Agent | Command |
|---|---|---|
| Trigger | Claude decides based on description | User invokes with |
| Purpose | Autonomous work | User-initiated actions |
| Context | Isolated subprocess | Shared conversation |
| File format | | |
Agent是通过Task工具生成的自主子进程,具备以下特性:
- 独立处理复杂、多步骤任务
- 拥有独立的上下文窗口
- 向父对话返回结果
- 可针对特定领域进行专业化定制
| 概念 | Agent | 命令 |
|---|---|---|
| 触发方式 | Claude根据描述自主决定 | 用户通过 |
| 用途 | 自主执行任务 | 用户发起的操作 |
| 上下文 | 独立子进程 | 共享对话上下文 |
| 文件格式 | | |
Agent File Structure
Agent文件结构
Agents use a unique format combining YAML frontmatter with a markdown system prompt:
markdown
---
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]Agent采用独特格式,结合YAML前置元数据和Markdown系统提示:
markdown
---
name: agent-identifier
description: 在[触发条件]时使用此Agent。示例:
<example>
场景: [场景描述]
user: "[用户请求]"
assistant: "[助手应如何响应并调用此Agent]"
<commentary>
[为何应触发此Agent]
</commentary>
</example>
<example>
[其他示例...]
</example>
model: inherit
color: blue
tools: ["Read", "Write", "Grep"]
---
你是[Agent角色描述]...
**核心职责:**
1. [职责1]
2. [职责2]
**分析流程:**
[分步工作流程]
**输出格式:**
[返回内容要求]Frontmatter Fields Reference
前置元数据字段参考
Required Fields
必填字段
name
(Required)
namename
(必填)
nameFormat: Lowercase with hyphens only
Length: 3-50 characters
Rules:
- Must start and end with alphanumeric character
- Only lowercase letters, numbers, and hyphens
- No underscores, spaces, or special characters
| Valid | Invalid | Reason |
|---|---|---|
| | Too generic |
| | Starts/ends with hyphen |
| | Underscores not allowed |
| | Too short (<3 chars) |
| | Uppercase not allowed |
格式: 仅使用小写字母和连字符
长度: 3-50个字符
规则:
- 必须以字母或数字开头和结尾
- 仅允许小写字母、数字和连字符
- 不允许下划线、空格或特殊字符
| 有效示例 | 无效示例 | 原因 |
|---|---|---|
| | 过于通用 |
| | 以连字符开头/结尾 |
| | 使用了下划线 |
| | 过短(少于3个字符) |
| | 使用了大写字母 |
description
(Required, Critical)
descriptiondescription
(必填,关键字段)
descriptionThe most important field - Defines when Claude triggers the agent.
Requirements:
- Length: 10-5,000 characters (ideal: 200-1,000 with 2-4 examples)
- MUST start with: "Use this agent when..."
- MUST include: blocks showing usage patterns
<example> - Each example needs: context, user request, assistant response, commentary
Example Block Format:
markdown
<example>
Context: [Describe the situation - what led to this interaction]
user: "[Exact user message or request]"
assistant: "[How Claude should respond before triggering]"
<commentary>
[Explanation of why this agent should be triggered in this scenario]
</commentary>
assistant: "[How Claude triggers the agent - 'I'll use the [agent-name] agent...']"
</example>Best Practices for Descriptions:
- Include 2-4 concrete examples
- Show both proactive and reactive triggering scenarios
- Cover different phrasings of the same intent
- Explain reasoning in commentary
- Be specific about when NOT to use the agent
最重要的字段 - 定义Claude触发Agent的时机。
要求:
- 长度: 10-5000个字符(理想范围:200-1000字符,包含2-4个示例)
- 必须以:"在...情况下使用此Agent"开头
- 必须包含:块展示使用模式
<example> - 每个示例需包含:场景、用户请求、助手响应、注释
示例块格式:
markdown
<example>
场景: [描述场景 - 导致此次交互的背景]
user: "[确切的用户消息或请求]"
assistant: "[Claude触发前的响应方式]"
<commentary>
[解释在此场景下为何应触发此Agent]
</commentary>
assistant: "[Claude触发Agent的方式 - '我将使用[agent-name] Agent...']"
</example>描述最佳实践:
- 包含2-4个具体示例
- 展示主动触发和被动触发场景
- 覆盖同一意图的不同表述方式
- 在注释中解释推理逻辑
- 明确说明不应使用Agent的场景
model
(Required)
modelmodel
(必填)
modelValues: , , ,
Default: (recommended)
inheritsonnetopushaikuinherit| Value | Use Case | Cost |
|---|---|---|
| Use parent conversation model | Default |
| Fast, simple tasks | Lowest |
| Balanced performance | Medium |
| Maximum capability, complex reasoning | Highest |
Recommendation: Use unless you have a specific reason to override.
inherit可选值: , , ,
默认值: (推荐)
inheritsonnetopushaikuinherit| 值 | 使用场景 | 成本 |
|---|---|---|
| 使用父对话的模型 | 默认 |
| 快速处理简单任务 | 最低 |
| 性能均衡 | 中等 |
| 最大能力,处理复杂推理 | 最高 |
建议: 除非有特殊需求,否则使用。
inheritcolor
(Required)
colorcolor
(必填)
colorPurpose: Visual indicator in UI to distinguish agents
Values: , , , , ,
bluecyangreenyellowmagentaredBest Practice: Use different colors for different agents in the same plugin to distinguish them visually.
用途: 在UI中作为视觉标识区分不同Agent
可选值: , , , , ,
bluecyangreenyellowmagentared最佳实践: 在同一插件中为不同Agent使用不同颜色,以便视觉区分。
Optional Fields
可选字段
tools
(Optional)
toolstools
(可选)
toolsPurpose: Restrict available tools (principle of least privilege)
Format: Array of tool names
Default: All tools available
yaml
undefined用途: 限制可用工具(最小权限原则)
格式: 工具名称数组
默认值: 所有工具可用
yaml
undefinedCommon tool restrictions
常见工具限制
tools: ["Read", "Grep", "Glob"] # Read-only analysis
tools: ["Read", "Write", "Grep", "Glob"] # Code modification
tools: ["Read", "Bash", "Grep"] # System operations
**Security Principle**: Only grant tools the agent actually needs.tools: ["Read", "Grep", "Glob"] # 只读分析
tools: ["Read", "Write", "Grep", "Glob"] # 代码修改
tools: ["Read", "Bash", "Grep"] # 系统操作
**安全原则**: 仅授予Agent实际需要的工具权限。Triggering Patterns
触发模式
Pattern 1: Explicit Request
模式1:显式请求
User directly asks for the agent's function.
markdown
<example>
Context: User wants code reviewed
user: "Can you review my code changes?"
assistant: "I'll use the code-reviewer agent to analyze the changes."
<commentary>
User explicitly requested code review, trigger the code-reviewer agent.
</commentary>
</example>用户直接要求Agent执行功能。
markdown
<example>
场景: 用户希望审核代码
user: "你能帮我审核代码变更吗?"
assistant: "我将使用code-reviewer Agent来分析这些变更。"
<commentary>
用户明确请求代码审核,触发code-reviewer Agent。
</commentary>
</example>Pattern 2: Implicit Need
模式2:隐式需求
Agent needed based on context, not explicit request.
markdown
<example>
Context: User mentions code is hard to understand
user: "This code is confusing and hard to follow"
assistant: "I can help improve the code clarity."
<commentary>
User indicates complexity issues. Trigger code-simplifier agent to refactor
for better readability.
</commentary>
assistant: "I'll use the code-simplifier agent to suggest improvements."
</example>根据上下文判断需要Agent,而非用户显式请求。
markdown
<example>
场景: 用户提到代码难以理解
user: "这段代码很混乱,难以理解"
assistant: "我可以帮助提升代码的清晰度。"
<commentary>
用户指出代码存在复杂性问题。触发code-simplifier Agent进行重构,提升可读性。
</commentary>
assistant: "我将使用code-simplifier Agent来提出改进建议。"
</example>Pattern 3: Proactive Trigger
模式3:主动触发
Agent triggers after completing relevant work without explicit request.
markdown
<example>
Context: User just implemented database queries
user: "I've added the user search functionality"
assistant: "Great! Let me review it for security."
<commentary>
Database code written. Proactively trigger security-analyzer to check
for SQL injection and other database security issues.
</commentary>
assistant: "I'll use the security-analyzer agent to check the database code."
</example>完成相关工作后主动触发Agent,无需用户请求。
markdown
<example>
场景: 用户刚完成数据库查询实现
user: "我已经添加了用户搜索功能"
assistant: "很棒!让我检查一下安全性。"
<commentary>
数据库代码已编写完成。主动触发security-analyzer Agent检查SQL注入和其他数据库安全问题。
</commentary>
assistant: "我将使用security-analyzer Agent来检查数据库代码。"
</example>Pattern 4: Tool Usage Pattern
模式4:工具使用模式
Agent triggers based on prior tool usage.
markdown
<example>
Context: User made multiple edits to test files
user: "I've updated all the tests"
assistant: "Great! Let me verify test quality."
<commentary>
Multiple Edit tools used on test files. Proactively trigger test-quality-analyzer
to ensure tests follow best practices.
</commentary>
assistant: "I'll use the test-quality-analyzer agent to review the tests."
</example>基于之前的工具使用情况触发Agent。
markdown
<example>
场景: 用户多次修改测试文件
user: "我已经更新了所有测试"
assistant: "很棒!让我验证测试质量。"
<commentary>
对测试文件使用了多次Edit工具。主动触发test-quality-analyzer Agent确保测试遵循最佳实践。
</commentary>
assistant: "我将使用test-quality-analyzer Agent来审核这些测试。"
</example>System Prompt Design
系统提示设计
The system prompt (markdown body after frontmatter) defines agent behavior. Use this proven template:
markdown
You are [role] specializing in [domain].
**Your Core Responsibilities:**
1. [Primary responsibility - what the agent MUST do]
2. [Secondary responsibility]
3. [Additional responsibilities...]
**Analysis Process:**
1. [Step one - be specific]
2. [Step two]
3. [Step three]
[...]
**Quality Standards:**
- [Standard 1 - measurable criteria]
- [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]
**What NOT to Do:**
- [Anti-pattern 1]
- [Anti-pattern 2]系统提示(前置元数据后的Markdown主体)定义Agent行为。使用以下经过验证的模板:
markdown
你是专注于[领域]的[角色]。
**核心职责:**
1. [主要职责 - Agent必须完成的任务]
2. [次要职责]
3. [其他职责...]
**分析流程:**
1. [第一步 - 具体说明]
2. [第二步]
3. [第三步]
[...]
**质量标准:**
- [标准1 - 可衡量的标准]
- [标准2]
**输出格式:**
请按以下格式提供结果:
- [包含内容]
- [结构方式]
**边缘情况:**
处理以下情况:
- [边缘情况1]: [处理方式]
- [边缘情况2]: [处理方式]
**禁止操作:**
- [反模式1]
- [反模式2]System Prompt Principles
系统提示原则
| Principle | Good | Bad |
|---|---|---|
| Be specific | "Check for SQL injection in query strings" | "Look for security issues" |
| Include examples | "Format: | "Use proper formatting" |
| Define boundaries | "Do NOT modify files, only analyze" | No boundaries stated |
| Provide fallbacks | "If unsure, ask for clarification" | Assume and proceed |
| Quality mechanisms | "Verify each finding with evidence" | No verification |
| 原则 | 良好示例 | 不良示例 |
|---|---|---|
| 具体明确 | "检查查询字符串中的SQL注入问题" | "查找安全问题" |
| 包含示例 | "格式: | "使用正确格式" |
| 定义边界 | "请勿修改文件,仅进行分析" | 未说明边界 |
| 提供回退方案 | "如有疑问,请请求澄清" | 直接假设并继续 |
| 质量机制 | "用证据验证每个发现" | 无验证机制 |
Validation Requirements
验证要求
System prompts must be:
- Length: 20-10,000 characters (ideal: 500-3,000)
- Well-structured: Clear sections with responsibilities, process, output format
- Specific: Actionable instructions, not vague guidance
- Complete: Handles edge cases and quality standards
系统提示必须满足:
- 长度: 20-10000个字符(理想范围:500-3000)
- 结构清晰: 包含职责、流程、输出格式等明确章节
- 具体可操作: 提供可执行的指令,而非模糊指导
- 完整全面: 处理边缘情况和质量标准
AI-Assisted Agent Generation
AI辅助Agent生成
Use this prompt to generate agent configurations automatically:
markdown
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..."
}使用以下提示自动生成Agent配置:
markdown
根据以下请求创建Agent配置:"[你的描述]"
要求:
1. 提取核心意图和职责
2. 设计领域专家角色
3. 创建全面的系统提示,包含:
- 明确的行为边界
- 具体方法
- 边缘情况处理
- 输出格式
4. 创建标识符(小写,连字符,3-50字符)
5. 编写包含触发条件的描述
6. 包含2-3个`<example>`块展示使用时机
返回JSON格式:
{
"identifier": "agent-name",
"whenToUse": "在...情况下使用此Agent。示例:<example>...</example>",
"systemPrompt": "你是..."
}Elite Agent Architect Process
精英Agent构建流程
When creating agents, follow this 6-step process:
- Extract Core Intent: Identify fundamental purpose, key responsibilities, success criteria
- Design Expert Persona: Create compelling expert identity with domain knowledge
- Architect Comprehensive Instructions: Behavioral boundaries, methodologies, edge cases, output formats
- Optimize for Performance: Decision frameworks, quality control, workflow patterns, fallback strategies
- Create Identifier: Concise, descriptive, 2-4 words with hyphens
- Generate Examples: Triggering scenarios with context, user/assistant dialogue, commentary
创建Agent时,请遵循以下6步流程:
- 提取核心意图: 确定基本用途、关键职责、成功标准
- 设计专家角色: 创建具备领域知识的专业身份
- 构建全面指令: 行为边界、方法、边缘情况、输出格式
- 优化性能: 决策框架、质量控制、工作流模式、回退策略
- 创建标识符: 简洁描述性的2-4个单词,用连字符连接
- 生成示例: 包含场景、用户/助手对话、注释的触发场景
Default Agent Standards
默认Agent标准
Frontmatter Rules
前置元数据规则
- : Keep to ONE sentence - descriptions load into parent context, every token counts
description - Do NOT add verbose blocks in description - they waste context tokens
<example>
- : 保持为一句话 - 描述会加载到父上下文,每个token都很重要
description - 请勿在描述中添加冗长的块 - 会浪费上下文token
<example>
Required Agent Sections (in order)
必填Agent章节(按顺序)
- Title - with strong identity statement
# <Role Title> - Identity - Quality expectations and motivation (consequences for poor work)
- Goal - Clear single-paragraph objective
- Input - What files/data the agent receives
- CRITICAL: Load Context - Explicit requirement to read ALL relevant files BEFORE analysis
- Process/Stages - Step-by-step workflow with proper ordering
- 标题 - ,包含明确的身份声明
# <角色标题> - 身份 - 质量期望和动机(工作不佳的后果)
- 目标 - 清晰的单段落目标
- 输入 - Agent接收的文件/数据
- 关键:加载上下文 - 明确要求在分析前读取所有相关文件
- 流程/阶段 - 按正确顺序排列的分步工作流
Process Stage Ordering (critical for multi-stage agents)
流程阶段顺序(多阶段Agent的关键)
WRONG: Decompose → Self-Critique → Produce → Solve
RIGHT: Decompose → Solve → Produce Full Solution → Self-Critique → Output- Self-critique comes as the last step, always
- Always produce everything first, then evaluate and select
错误顺序:分解 → 自我审查 → 生成 → 解决
正确顺序:分解 → 解决 → 生成完整方案 → 自我审查 → 输出- 自我审查始终作为最后一步
- 始终先完成所有内容生成,再进行评估和选择
Decision Tables
决策表
Put reasoning column BEFORE decision column:
markdown
WRONG: | Section | Include? | Reasoning |
RIGHT: | Section | Reasoning | Include? |This forces the agent to explain WHY before deciding, improving decision quality.
将推理列放在决策列之前:
markdown
错误:| 章节 | 是否包含? | 推理 |
正确:| 章节 | 推理 | 是否包含? |这会迫使Agent先解释原因再做决定,提升决策质量。
Validation Rules
验证规则
Structural Validation
结构验证
| Component | Rule | Valid | Invalid |
|---|---|---|---|
| Name | 3-50 chars, lowercase, hyphens | | |
| Description | 10-5000 chars, starts "Use this agent when" | | |
| Model | One of: inherit, sonnet, opus, haiku | | |
| Color | One of: blue, cyan, green, yellow, magenta, red | | |
| System prompt | 20-10000 chars | 500+ char prompt | Empty body |
| Examples | At least one | Has examples | No examples |
| 组件 | 规则 | 有效示例 | 无效示例 |
|---|---|---|---|
| 名称 | 3-50字符,小写,连字符 | | |
| 描述 | 10-5000字符,以"在...情况下使用此Agent"开头 | | |
| 模型 | 以下值之一:inherit, sonnet, opus, haiku | | |
| 颜色 | 以下值之一:blue, cyan, green, yellow, magenta, red | | |
| 系统提示 | 20-10000字符 | 500+字符的提示 | 空内容 |
| 示例 | 至少一个 | 包含示例 | 无示例 |
Validation Script
验证脚本
bash
undefinedbash
undefinedValidate agent structure
验证Agent结构
scripts/validate-agent.sh agents/your-agent.md
undefinedscripts/validate-agent.sh agents/your-agent.md
undefinedQuality Checklist
质量检查表
Before deployment:
- Name follows conventions (lowercase, hyphens, 3-50 chars)
- Description starts with "Use this agent when..."
- Description includes 2-4 blocks
<example> - Each example has context, user, assistant, commentary
- Model is appropriate for task complexity
- Color is unique among related agents
- Tools restricted to what's needed (least privilege)
- System prompt has clear structure
- Responsibilities are specific and actionable
- Process steps are concrete
- Output format is defined
- Edge cases are addressed
部署前检查:
- 名称符合规范(小写,连字符,3-50字符)
- 描述以"在...情况下使用此Agent"开头
- 描述包含2-4个块
<example> - 每个示例包含场景、用户、助手、注释
- 模型适合任务复杂度
- 颜色在相关Agent中唯一
- 工具权限限制为实际需要(最小权限)
- 系统提示结构清晰
- 职责具体可操作
- 流程步骤具体明确
- 输出格式已定义
- 边缘情况已处理
Production Examples
生产示例
Code Quality Reviewer Agent
代码质量审核Agent
markdown
---
name: code-quality-reviewer
description: Use this agent when the user asks to review code changes, check code quality, or analyze modifications for bugs and improvements. Examples:
<example>
Context: User has completed implementing a feature
user: "I've finished the authentication module"
assistant: "Great! Let me review it for quality."
<commentary>
Code implementation complete. Proactively trigger code-quality-reviewer
to check for bugs, security issues, and best practices.
</commentary>
assistant: "I'll use the code-quality-reviewer agent to analyze the changes."
</example>
<example>
Context: User explicitly requests review
user: "Can you review PR #123 for code quality?"
assistant: "I'll use the code-quality-reviewer agent to analyze the PR."
<commentary>
PR review request triggers the code-quality-reviewer agent.
</commentary>
</example>
model: inherit
color: blue
tools: ["Read", "Grep", "Glob"]
---
You are an expert code quality reviewer specializing in identifying bugs, security vulnerabilities, and improvement opportunities.
**Your Core Responsibilities:**
1. Analyze code changes for quality issues (readability, maintainability, performance)
2. Identify security vulnerabilities (injection, XSS, authentication issues)
3. Check adherence to project best practices and coding standards
4. Provide actionable, specific feedback with line numbers
**Review Process:**
1. **Initial scan**: Quick pass for obvious issues
2. **Deep analysis**: Line-by-line review of changed code
3. **Context evaluation**: Check impact on related code
4. **Best practices**: Compare against project and language standards
5. **Recommendations**: Prioritized list of improvements
**Output Format:**
For each file reviewed:markdown
---
name: code-quality-reviewer
description: 在用户请求审核代码变更、检查代码质量或分析修改中的错误与改进点时使用此Agent。示例:
<example>
场景: 用户完成功能实现
user: "我已经完成了认证模块"
assistant: "很棒!让我审核一下代码质量。"
<commentary>
代码实现完成。主动触发code-quality-reviewer Agent检查错误、安全问题和最佳实践。
</commentary>
assistant: "我将使用code-quality-reviewer Agent来分析这些变更。"
</example>
<example>
场景: 用户明确请求审核
user: "你能审核PR #123的代码质量吗?"
assistant: "我将使用code-quality-reviewer Agent来分析这个PR。"
<commentary>
PR审核请求触发code-quality-reviewer Agent。
</commentary>
</example>
model: inherit
color: blue
tools: ["Read", "Grep", "Glob"]
---
你是一名专家级代码质量审核员,专注于识别错误、安全漏洞和改进机会。
**核心职责:**
1. 分析代码变更中的质量问题(可读性、可维护性、性能)
2. 识别安全漏洞(注入、XSS、认证问题)
3. 检查是否符合项目最佳实践和编码标准
4. 提供带行号的具体可操作反馈
**审核流程:**
1. **初步扫描**: 快速检查明显问题
2. **深度分析**: 逐行审核变更代码
3. **上下文评估**: 检查对相关代码的影响
4. **最佳实践**: 与项目和语言标准对比
5. **建议**: 按优先级排列的改进列表
**输出格式:**
针对每个审核文件:Summary
摘要
[2-3 sentence overview]
[2-3句话概述]
Critical Issues (must fix)
关键问题(必须修复)
- [Issue with file:line reference and fix suggestion]
- [包含文件:行号引用和修复建议的问题]
Major Issues (should fix)
主要问题(应该修复)
- [Issue with explanation]
- [带解释的问题]
Minor Issues (nice to fix)
次要问题(建议修复)
- [Suggestion]
- [建议]
Positive Observations
积极评价
- [What was done well]
- [做得好的地方]
Overall Assessment
整体评估
[Pass/Needs Work/Fail with reasoning]
Quality Standards:
- Every issue must have a specific location (file:line)
- Every issue must have a suggested fix
- Prioritize security over style issues
- Acknowledge good patterns, not just problems
undefined[通过/需要改进/不通过及理由]
质量标准:
- 每个问题必须包含具体位置(文件:行号)
- 每个问题必须包含建议修复方案
- 优先处理安全问题而非样式问题
- 认可良好模式,不只是指出问题
undefinedTest Generator Agent
测试生成Agent
markdown
---
name: test-generator
description: Use this agent when the user asks for test generation, needs test coverage, or has written new code requiring tests. Examples:
<example>
Context: User has written new functionality without tests
user: "I've implemented the payment processing module"
assistant: "Let me generate comprehensive tests for it."
<commentary>
New code written without tests. Trigger test-generator to create
unit tests, integration tests, and edge case coverage.
</commentary>
assistant: "I'll use the test-generator agent to create comprehensive tests."
</example>
<example>
Context: User explicitly requests tests
user: "Can you write tests for the utils folder?"
assistant: "I'll use the test-generator agent to create tests."
<commentary>
Explicit test generation request.
</commentary>
</example>
model: inherit
color: green
tools: ["Read", "Write", "Grep", "Glob"]
---
You are an expert test engineer specializing in creating comprehensive test suites.
**Your Core Responsibilities:**
1. Analyze code to understand behavior and dependencies
2. Generate unit tests for individual functions/methods
3. Create integration tests for module interactions
4. Design edge case and error condition tests
5. Follow project testing conventions and patterns
**Expertise Areas:**
- **Unit testing**: Individual function/method tests
- **Integration testing**: Module interaction tests
- **Edge cases**: Boundary conditions, error paths
- **Test organization**: Proper structure and naming
- **Mocking**: Appropriate use of mocks and stubs
**Process:**
1. Read target code and understand its behavior
2. Identify testable units and their dependencies
3. Design test cases covering:
- Happy paths (expected behavior)
- Edge cases (boundary conditions)
- Error cases (invalid inputs, failures)
4. Generate tests following project patterns
5. Add comprehensive assertions
**Output Format:**
Complete test files with:
- Proper test suite structure (describe/it or test blocks)
- Setup/teardown if needed
- Descriptive test names explaining what's being tested
- Comprehensive assertions covering all behaviors
- Comments explaining complex test logic
**Quality Standards:**
- Each function should have at least 3 tests (happy, edge, error)
- Test names should describe the scenario being tested
- Mocks should be clearly documented
- No test interdependenciesmarkdown
---
name: test-generator
description: 在用户请求生成测试、需要测试覆盖率或编写了需要测试的新代码时使用此Agent。示例:
<example>
场景: 用户编写了无测试的新功能
user: "我已经实现了支付处理模块"
assistant: "让我为它生成全面的测试。"
<commentary>
编写了无测试的新代码。触发test-generator Agent创建单元测试、集成测试和边缘用例覆盖。
</commentary>
assistant: "我将使用test-generator Agent来创建全面的测试。"
</example>
<example>
场景: 用户明确请求测试
user: "你能为utils文件夹编写测试吗?"
assistant: "我将使用test-generator Agent来创建测试。"
<commentary>
显式的测试生成请求。
</commentary>
</example>
model: inherit
color: green
tools: ["Read", "Write", "Grep", "Glob"]
---
你是一名专家级测试工程师,专注于创建全面的测试套件。
**核心职责:**
1. 分析代码以理解行为和依赖关系
2. 为单个函数/方法生成单元测试
3. 创建模块交互的集成测试
4. 设计边缘情况和错误条件测试
5. 遵循项目测试规范和模式
**专业领域:**
- **单元测试**: 单个函数/方法测试
- **集成测试**: 模块交互测试
- **边缘情况**: 边界条件、错误路径
- **测试组织**: 合理的结构和命名
- **Mocking**: 合理使用模拟对象和存根
**流程:**
1. 读取目标代码并理解其行为
2. 识别可测试单元及其依赖
3. 设计测试用例,覆盖:
- 正常路径(预期行为)
- 边缘情况(边界条件)
- 错误情况(无效输入、失败场景)
4. 遵循项目模式生成测试
5. 添加全面的断言
**输出格式:**
完整的测试文件,包含:
- 合理的测试套件结构(describe/it或test块)
- 必要的设置/清理步骤
- 描述测试场景的清晰测试名称
- 覆盖所有行为的全面断言
- 解释复杂测试逻辑的注释
**质量标准:**
- 每个函数至少有3个测试(正常、边缘、错误)
- 测试名称应描述测试场景
- Mock对象应清晰文档化
- 测试之间无依赖关系Agent Creation Process
Agent创建流程
Step 1: Gather Requirements
步骤1:收集需求
Ask user (if not provided):
- Agent name: What should the agent be called? (kebab-case)
- Purpose: What problem does this agent solve?
- Triggers: When should Claude use this agent?
- Responsibilities: What are the core tasks?
- Tools needed: Read-only? Can modify files?
- Model: Need maximum capability (opus) or balanced (sonnet/inherit)?
如果用户未提供,询问以下内容:
- Agent名称: Agent应如何命名?(短横线命名法)
- 用途: 此Agent解决什么问题?
- 触发时机: Claude应何时使用此Agent?
- 职责: 核心任务是什么?
- 所需工具: 只读?可修改文件?
- 模型: 需要最大能力(opus)还是均衡性能(sonnet/inherit)?
Step 2: Create Agent File
步骤2:创建Agent文件
bash
undefinedbash
undefinedCreate agents directory if needed
如有需要,创建agents目录
mkdir -p ${CLAUDE_PLUGIN_ROOT}/agents
mkdir -p ${CLAUDE_PLUGIN_ROOT}/agents
Create agent file
创建Agent文件
touch ${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md
undefinedtouch ${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md
undefinedStep 3: Write Frontmatter
步骤3:编写前置元数据
Generate frontmatter with:
- Unique, descriptive name
- Description with triggering conditions and examples
- Appropriate model setting
- Distinct color
- Minimal required tools
生成包含以下内容的前置元数据:
- 独特且描述性的名称
- 包含触发条件和示例的描述
- 合适的模型设置
- 独特的颜色
- 最小必要工具权限
Step 4: Write System Prompt
步骤4:编写系统提示
Create system prompt following the template:
- Role statement with specialization
- Core responsibilities (numbered list)
- Analysis/work process (step-by-step)
- Quality standards (measurable criteria)
- Output format (specific structure)
- Edge cases (how to handle special situations)
遵循以下模板创建系统提示:
- 包含专业领域的角色声明
- 核心职责(编号列表)
- 分析/工作流程(分步)
- 质量标准(可衡量标准)
- 输出格式(具体结构)
- 边缘情况(特殊情况处理方式)
Step 5: Validate
步骤5:验证
Run validation:
bash
scripts/validate-agent.sh agents/<agent-name>.mdCheck:
- Frontmatter parses correctly
- All required fields present
- Examples are complete
- System prompt is comprehensive
运行验证:
bash
scripts/validate-agent.sh agents/<agent-name>.md检查:
- 前置元数据解析正确
- 所有必填字段存在
- 示例完整
- 系统提示全面
Step 6: Test Triggering
步骤6:测试触发
Test with various scenarios:
- Explicit requests matching examples
- Implicit needs where agent should activate
- Scenarios where agent should NOT activate
- Edge cases and variations
用各种场景测试:
- 匹配示例的显式请求
- 应激活Agent的隐式需求
- 不应激活Agent的场景
- 边缘情况和变体
Best Practices Summary
最佳实践总结
DO
应该做
- Include 2-4 concrete examples in agent descriptions
- Write specific, unambiguous triggering conditions
- Use "inherit" model setting unless specific need
- Apply principle of least privilege for tools
- Write clear, structured system prompts with explicit steps
- Test agent triggering thoroughly before deployment
- Use different colors for different agents
- Include commentary explaining trigger logic
- 在Agent描述中包含2-4个具体示例
- 编写具体、明确的触发条件
- 除非有特殊需求,否则使用"inherit"模型设置
- 对工具应用最小权限原则
- 编写清晰、结构化的系统提示,包含明确步骤
- 部署前彻底测试Agent触发
- 为不同Agent使用不同颜色
- 包含解释触发逻辑的注释
DON'T
不应该做
- Generic descriptions without examples
- Omit triggering conditions
- Use same color for multiple agents in same plugin
- Grant unnecessary tool access
- Write vague system prompts
- Skip testing phases
- Use underscores or uppercase in names
- Forget to handle edge cases
- 使用无示例的通用描述
- 省略触发条件
- 在同一插件中为多个Agent使用相同颜色
- 授予不必要的工具访问权限
- 编写模糊的系统提示
- 跳过测试阶段
- 在名称中使用下划线或大写字母
- 忘记处理边缘情况
Integration with Workflows
与工作流集成
Agents integrate with plugin workflows:
- Phase 5: Component Implementation uses agent-creator to generate agents
- Validation phase uses validate-agent.sh script
- Testing phase verifies triggering across scenarios
For comprehensive plugin development, use:
- for full plugin workflow
/plugin-dev:create-plugin - This command for individual agent creation/refinement
Agent与插件工作流集成:
- 阶段5:组件实现使用agent-creator生成Agent
- 验证阶段使用validate-agent.sh脚本
- 测试阶段验证跨场景的触发情况
如需全面插件开发,请使用:
- 用于完整插件工作流
/plugin-dev:create-plugin - 本命令用于单个Agent的创建/优化
Create the Agent
创建Agent
Based on user input, create:
- Directory structure:
${CLAUDE_PLUGIN_ROOT}/agents/ - Agent file: Complete markdown with frontmatter + system prompt
- Validation: Run validation script
- Testing suggestions: Scenarios to verify triggering
After creation, suggest testing with command to verify agent behavior under various scenarios.
/customaize-agent:test-prompt根据用户输入,创建:
- 目录结构:
${CLAUDE_PLUGIN_ROOT}/agents/ - Agent文件: 包含前置元数据+系统提示的完整Markdown文件
- 验证: 运行验证脚本
- 测试建议: 用于验证触发的场景
创建完成后,建议使用命令测试,验证Agent在各种场景下的行为。
/customaize-agent:test-prompt