name: new-agent description: 创建自定义Claude Code子代理。交互式向导，收集需求，生成具有适当frontmatter和系统提示的代理.md文件。在创建新代理、添加子代理或使自定义代理全局可用时使用。关键词：代理, 子代理, 创建代理, 新代理, 自定义代理 disable-model-invocation: true argument-hint: “[代理描述或留空以进行交互]”
新代理创建器
创建自定义Claude Code子代理作为具有YAML frontmatter和系统提示的.md文件。
代理存储位置
| 位置 | 范围 | 何时使用 |
|---|---|---|
.claude/agents/ |
当前项目 | 团队共享，检查到版本控制 |
~/.claude/agents/ |
所有项目 | 跨机器的个人代理 |
在创建代理之前，列出目标目录中的现有代理以避免名称冲突。
代理文件格式
---
name: 代理名称
description: 当Claude应该使用此代理时。包括2-3个<example>块。
color: green
model: inherit
memory: user
---
系统提示内容在这里 — 这成为代理的整个个性和指令。
Frontmatter字段
| 字段 | 必需 | 默认 | 描述 |
|---|---|---|---|
name |
是 | — | 仅小写字母、数字、连字符。必须在所有代理中唯一。 |
description |
是 | — | 对于委托至关重要。必须包括<example>块。 |
tools |
否 | 所有工具 | 逗号分隔的允许列表：Read, Grep, Glob, Bash, Write, Edit等。 |
disallowedTools |
否 | — | 明确拒绝的工具（从继承集中移除）。 |
model |
否 | inherit |
其中之一：sonnet, opus, haiku, inherit。 |
color |
否 | — | UI颜色：green, cyan, bright_red, yellow, blue, magenta, 等。 |
permissionMode |
否 | default |
default, acceptEdits, dontAsk, bypassPermissions, plan。 |
maxTurns |
否 | — | 停止前的最大代理轮次。 |
memory |
否 | — | 持久内存范围：user, project, 或 local。 |
skills |
否 | — | 预加载到代理上下文中的技能。 |
mcpServers |
否 | — | 此代理可用的MCP服务器。 |
hooks |
否 | — | 作用于此代理的生命周期钩子。 |
指令
步骤1：收集需求
如果提供$ARGUMENTS，将其用作代理概念。否则，询问用户：
- 此代理专精于什么领域？（例如，“数据库优化”、“可访问性审计”、“Rust开发”）
- 调用时应做什么？（例如，“审查查询性能”、“审计HTML以符合WCAG”）
- 应该是只读还是能够修改文件？
- 应使用什么模型？（
inherit适用于大多数，haiku用于快速/廉价任务，sonnet用于平衡，opus用于复杂推理） - 应在会话间具有持久内存吗？（推荐用于随时间学习模式的代理）
- 应存放在哪里？（
.claude/agents/用于项目级，~/.claude/agents/用于用户级）
步骤2：选择名称
规则：
- 仅小写字母、数字、连字符
- 描述角色，而不是任务（例如，
accessibility-auditor而不是check-accessibility） - 检查与目标目录中现有代理的冲突
- 保持简短但明确
步骤3：制作描述
描述至关重要 — Claude使用它来决定何时将任务委托给此代理。
必需结构：
当[触发场景]时使用此代理。此代理擅长[能力]。示例：
<example>
上下文：[情况]
用户：“[用户说什么]”
助手：“[Claude如何委托]”
<commentary>
[为什么此代理是正确选择]
</commentary>
</example>
包括2-3个<example>块显示现实的委托场景。这些是必不可少的 — Claude依赖它们进行模式匹配。
最佳实践：
- 以“当…时使用此代理”开始
- 列出具体的触发场景，而不是模糊的领域
- 包括用户可能自然说的关键词
- 如果代理应自动触发（例如，代码更改后），添加“主动使用”
步骤4：编写系统提示
frontmatter后的markdown正文成为代理的系统提示。它只接收此提示（加上基本环境细节），而不是完整的Claude Code系统提示。
结构：
- 开场人设（1-2句话）：代理是谁以及它重视什么
- 核心心态/原则（项目符号）：驱动决策的心智模型
- 详细方法论：领域特定的检查表、框架或过程
- 输出格式：发现/结果应如何结构化
- 沟通风格：语气和演示指南
- 内存指南（如果启用内存）：跨会话记录什么
质量标准：
- 具体且可操作，不模糊
- 包括与专长相关的领域特定框架
- 定义输出结构以使结果一致
- 包括反模式（不应做什么）
- 保持在150行以下 — 提示臃肿的代理会失去焦点
步骤5：选择工具访问
常见模式：
| 代理类型 | 工具 | 理由 |
|---|---|---|
| 只读审查者 | Read, Grep, Glob, Bash |
可以探索和运行只读命令 |
| 代码修改者 | 所有工具（默认） | 完全访问以进行更改 |
| 仅研究 | Read, Grep, Glob, WebSearch, WebFetch |
可以搜索代码和网络，不执行 |
| 限制执行者 | Bash + 钩子 |
带有PreToolUse钩子的Bash以验证命令 |
如果代理应具有所有工具（常见情况），完全省略tools字段。
步骤6：创建代理文件
将代理.md文件写入在步骤1中选择的目标目录。
步骤7：验证和报告
创建文件后：
- 显示文件 — 显示完整内容
- 确认无名称冲突 — 检查与目标目录中现有代理的冲突
- 显示示例调用 — 2-3种触发代理的方式
- 提醒加载 — 新代理在会话开始时加载；重新启动会话或使用
/agents立即加载 - 建议测试 — 尝试匹配描述的请求以验证委托
示例代理（参考）
一个结构良好的代理：
---
name: accessibility-auditor
description: 当您需要评估UI代码以符合可访问性、WCAG一致性或包容性设计时使用此代理。擅长识别缺失的ARIA属性、键盘导航问题、颜色对比问题和屏幕阅读器兼容性。
<example>
上下文：用户刚刚构建了一个新的表单组件。
用户：“你能检查这个表单是否可访问吗？”
助手：“我将使用accessibility-auditor代理来评估您的表单以符合WCAG。”
<commentary>
表单可访问性涉及标签、错误公告、焦点管理 — accessibility-auditor提供的专业知识。
</commentary>
</example>
color: yellow
memory: user
---
您是一位确保数字界面为每个人工作的可访问性专家。
## 核心心态
- **默认包容**：每个用户都应有平等的功能访问权
- **编程优先**：如果辅助技术无法解析，它就是坏的
- **渐进增强**：从可访问开始，层叠交互性
## 方法论
当审计代码时：
1. 检查语义HTML结构（标题、地标、角色）
2. 验证所有交互元素是否键盘可访问
3. 确认ARIA属性正确且完整
4. 评估颜色对比比率（WCAG AA最低要求）
5. 测试动态内容的焦点管理
## 输出格式
按影响组织发现：
### 关键（完全阻止访问）
### 主要（显著降低体验）
### 次要（改进机会）
对于每个发现：**什么**错了，**哪里**（文件:行），**为什么**重要，**修复**并附代码示例。
## 沟通风格
- 具体 — 引用WCAG成功标准编号（例如，1.4.3对比）
- 为每个发现提供前后代码示例
- 承认已经做好的部分
反模式
- 不要为一次性任务创建代理 — 使用技能或主对话代替
- 不要创建描述模糊的代理 — “帮助代码”永远不会触发
- 不要重复现有代理 — 首先检查目标目录
- 不要给纯分析代理写访问权限 — 最少特权原则
- 不要跳过
<example>块 — 它们是主要的委托信号 - 不要使系统提示过长 — 超过150行会稀释焦点