create-agent

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create 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: $2
text
Agent名称: $1
描述: $2

What 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
ConceptAgentCommand
TriggerClaude decides based on descriptionUser invokes with
/name
PurposeAutonomous workUser-initiated actions
ContextIsolated subprocessShared conversation
File format
agents/*.md
commands/*.md
Agent是通过Task工具生成的自主子进程,具备以下特性:
  • 独立处理复杂、多步骤任务
  • 拥有独立的上下文窗口
  • 向父对话返回结果
  • 可针对特定领域进行专业化定制
概念Agent命令
触发方式Claude根据描述自主决定用户通过
/name
调用
用途自主执行任务用户发起的操作
上下文独立子进程共享对话上下文
文件格式
agents/*.md
commands/*.md

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)

name
(必填)

Format: 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
ValidInvalidReason
code-reviewer
helper
Too generic
test-generator
-agent-
Starts/ends with hyphen
api-docs-writer
my_agent
Underscores not allowed
security-analyzer
ag
Too short (<3 chars)
pr-quality-reviewer
MyAgent
Uppercase not allowed
格式: 仅使用小写字母和连字符 长度: 3-50个字符 规则:
  • 必须以字母或数字开头和结尾
  • 仅允许小写字母、数字和连字符
  • 不允许下划线、空格或特殊字符
有效示例无效示例原因
code-reviewer
helper
过于通用
test-generator
-agent-
以连字符开头/结尾
api-docs-writer
my_agent
使用了下划线
security-analyzer
ag
过短(少于3个字符)
pr-quality-reviewer
MyAgent
使用了大写字母

description
(Required, Critical)

description
(必填,关键字段)

The 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:
    <example>
    blocks showing usage patterns
  • 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)

model
(必填)

Values:
inherit
,
sonnet
,
opus
,
haiku
Default:
inherit
(recommended)
ValueUse CaseCost
inherit
Use parent conversation modelDefault
haiku
Fast, simple tasksLowest
sonnet
Balanced performanceMedium
opus
Maximum capability, complex reasoningHighest
Recommendation: Use
inherit
unless you have a specific reason to override.
可选值:
inherit
,
sonnet
,
opus
,
haiku
默认值:
inherit
(推荐)
使用场景成本
inherit
使用父对话的模型默认
haiku
快速处理简单任务最低
sonnet
性能均衡中等
opus
最大能力,处理复杂推理最高
建议: 除非有特殊需求,否则使用
inherit

color
(Required)

color
(必填)

Purpose: Visual indicator in UI to distinguish agents
Values:
blue
,
cyan
,
green
,
yellow
,
magenta
,
red
Best Practice: Use different colors for different agents in the same plugin to distinguish them visually.
用途: 在UI中作为视觉标识区分不同Agent
可选值:
blue
,
cyan
,
green
,
yellow
,
magenta
,
red
最佳实践: 在同一插件中为不同Agent使用不同颜色,以便视觉区分。

Optional Fields

可选字段

tools
(Optional)

tools
(可选)

Purpose: Restrict available tools (principle of least privilege) Format: Array of tool names Default: All tools available
yaml
undefined
用途: 限制可用工具(最小权限原则) 格式: 工具名称数组 默认值: 所有工具可用
yaml
undefined

Common 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

系统提示原则

PrincipleGoodBad
Be specific"Check for SQL injection in query strings""Look for security issues"
Include examples"Format:
## Critical Issues\n- Issue 1
"
"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注入问题""查找安全问题"
包含示例"格式:
## 关键问题\n- 问题1
"
"使用正确格式"
定义边界"请勿修改文件,仅进行分析"未说明边界
提供回退方案"如有疑问,请请求澄清"直接假设并继续
质量机制"用证据验证每个发现"无验证机制

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:
  1. Extract Core Intent: Identify fundamental purpose, key responsibilities, success criteria
  2. Design Expert Persona: Create compelling expert identity with domain knowledge
  3. Architect Comprehensive Instructions: Behavioral boundaries, methodologies, edge cases, output formats
  4. Optimize for Performance: Decision frameworks, quality control, workflow patterns, fallback strategies
  5. Create Identifier: Concise, descriptive, 2-4 words with hyphens
  6. Generate Examples: Triggering scenarios with context, user/assistant dialogue, commentary
创建Agent时,请遵循以下6步流程:
  1. 提取核心意图: 确定基本用途、关键职责、成功标准
  2. 设计专家角色: 创建具备领域知识的专业身份
  3. 构建全面指令: 行为边界、方法、边缘情况、输出格式
  4. 优化性能: 决策框架、质量控制、工作流模式、回退策略
  5. 创建标识符: 简洁描述性的2-4个单词,用连字符连接
  6. 生成示例: 包含场景、用户/助手对话、注释的触发场景

Default Agent Standards

默认Agent标准

Frontmatter Rules

前置元数据规则

  • description
    : Keep to ONE sentence - descriptions load into parent context, every token counts
  • Do NOT add verbose
    <example>
    blocks in description - they waste context tokens
  • description
    : 保持为一句话 - 描述会加载到父上下文,每个token都很重要
  • 请勿在描述中添加冗长的
    <example>
    块 - 会浪费上下文token

Required Agent Sections (in order)

必填Agent章节(按顺序)

  1. Title -
    # <Role Title>
    with strong identity statement
  2. Identity - Quality expectations and motivation (consequences for poor work)
  3. Goal - Clear single-paragraph objective
  4. Input - What files/data the agent receives
  5. CRITICAL: Load Context - Explicit requirement to read ALL relevant files BEFORE analysis
  6. Process/Stages - Step-by-step workflow with proper ordering
  1. 标题 -
    # <角色标题>
    ,包含明确的身份声明
  2. 身份 - 质量期望和动机(工作不佳的后果)
  3. 目标 - 清晰的单段落目标
  4. 输入 - Agent接收的文件/数据
  5. 关键:加载上下文 - 明确要求在分析前读取所有相关文件
  6. 流程/阶段 - 按正确顺序排列的分步工作流

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

结构验证

ComponentRuleValidInvalid
Name3-50 chars, lowercase, hyphens
code-reviewer
Code_Reviewer
Description10-5000 chars, starts "Use this agent when"
Use this agent when reviewing code...
Reviews code
ModelOne of: inherit, sonnet, opus, haiku
inherit
gpt-4
ColorOne of: blue, cyan, green, yellow, magenta, red
blue
purple
System prompt20-10000 chars500+ char promptEmpty body
ExamplesAt least one
<example>
block
Has examplesNo examples
组件规则有效示例无效示例
名称3-50字符,小写,连字符
code-reviewer
Code_Reviewer
描述10-5000字符,以"在...情况下使用此Agent"开头
在审核代码时使用此Agent...
审核代码
模型以下值之一:inherit, sonnet, opus, haiku
inherit
gpt-4
颜色以下值之一:blue, cyan, green, yellow, magenta, red
blue
purple
系统提示20-10000字符500+字符的提示空内容
示例至少一个
<example>
包含示例无示例

Validation Script

验证脚本

bash
undefined
bash
undefined

Validate agent structure

验证Agent结构

scripts/validate-agent.sh agents/your-agent.md
undefined
scripts/validate-agent.sh agents/your-agent.md
undefined

Quality Checklist

质量检查表

Before deployment:
  • Name follows conventions (lowercase, hyphens, 3-50 chars)
  • Description starts with "Use this agent when..."
  • Description includes 2-4
    <example>
    blocks
  • 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
[通过/需要改进/不通过及理由]
质量标准:
  • 每个问题必须包含具体位置(文件:行号)
  • 每个问题必须包含建议修复方案
  • 优先处理安全问题而非样式问题
  • 认可良好模式,不只是指出问题
undefined

Test 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 interdependencies
markdown
---
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):
  1. Agent name: What should the agent be called? (kebab-case)
  2. Purpose: What problem does this agent solve?
  3. Triggers: When should Claude use this agent?
  4. Responsibilities: What are the core tasks?
  5. Tools needed: Read-only? Can modify files?
  6. Model: Need maximum capability (opus) or balanced (sonnet/inherit)?
如果用户未提供,询问以下内容:
  1. Agent名称: Agent应如何命名?(短横线命名法)
  2. 用途: 此Agent解决什么问题?
  3. 触发时机: Claude应何时使用此Agent?
  4. 职责: 核心任务是什么?
  5. 所需工具: 只读?可修改文件?
  6. 模型: 需要最大能力(opus)还是均衡性能(sonnet/inherit)?

Step 2: Create Agent File

步骤2:创建Agent文件

bash
undefined
bash
undefined

Create 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
undefined
touch ${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md
undefined

Step 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:
  1. Role statement with specialization
  2. Core responsibilities (numbered list)
  3. Analysis/work process (step-by-step)
  4. Quality standards (measurable criteria)
  5. Output format (specific structure)
  6. Edge cases (how to handle special situations)
遵循以下模板创建系统提示:
  1. 包含专业领域的角色声明
  2. 核心职责(编号列表)
  3. 分析/工作流程(分步)
  4. 质量标准(可衡量标准)
  5. 输出格式(具体结构)
  6. 边缘情况(特殊情况处理方式)

Step 5: Validate

步骤5:验证

Run validation:
bash
scripts/validate-agent.sh agents/<agent-name>.md
Check:
  • 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:
  1. Explicit requests matching examples
  2. Implicit needs where agent should activate
  3. Scenarios where agent should NOT activate
  4. Edge cases and variations
用各种场景测试:
  1. 匹配示例的显式请求
  2. 应激活Agent的隐式需求
  3. 不应激活Agent的场景
  4. 边缘情况和变体

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:
  1. Phase 5: Component Implementation uses agent-creator to generate agents
  2. Validation phase uses validate-agent.sh script
  3. Testing phase verifies triggering across scenarios
For comprehensive plugin development, use:
  • /plugin-dev:create-plugin
    for full plugin workflow
  • This command for individual agent creation/refinement
Agent与插件工作流集成:
  1. 阶段5:组件实现使用agent-creator生成Agent
  2. 验证阶段使用validate-agent.sh脚本
  3. 测试阶段验证跨场景的触发情况
如需全面插件开发,请使用:
  • /plugin-dev:create-plugin
    用于完整插件工作流
  • 本命令用于单个Agent的创建/优化

Create the Agent

创建Agent

Based on user input, create:
  1. Directory structure:
    ${CLAUDE_PLUGIN_ROOT}/agents/
  2. Agent file: Complete markdown with frontmatter + system prompt
  3. Validation: Run validation script
  4. Testing suggestions: Scenarios to verify triggering
After creation, suggest testing with
/customaize-agent:test-prompt
command to verify agent behavior under various scenarios.
根据用户输入,创建:
  1. 目录结构:
    ${CLAUDE_PLUGIN_ROOT}/agents/
  2. Agent文件: 包含前置元数据+系统提示的完整Markdown文件
  3. 验证: 运行验证脚本
  4. 测试建议: 用于验证触发的场景
创建完成后,建议使用
/customaize-agent:test-prompt
命令测试,验证Agent在各种场景下的行为。