需要隔离上下文的复杂多步任务时，如何创建可复用的 AI…

当任务复杂多步且需要隔离上下文、并行执行或独立验证时，用结构化方法创建专用子代理（subagent）。

适用场景

解决思路

1. 判断该用子代理还是技能：任务复杂且多步时，若需要隔离上下文就用 SUBAGENT，否则用 SKILL；任务不复杂则用 SKILL。
2. 明确子代理用途：它承担什么具体职责、为什么需要隔离上下文、是否涉及多个复杂步骤、是否需要深度专业化。
3. 用 markdown 文件加 frontmatter 元数据定义子代理，包含 name、description、model、readonly 等字段。
4. 配置 name（必填）：使用 kebab-case 的唯一标识符，例如 security-auditor。
5. 配置 description（关键）：说明何时使用该子代理，用于自动委派；写具体场景，如“Security specialist. Use when implementing auth, payments, or handling sensitive data.”。
6. 在 description 中加入鼓励自动委派的措辞，如“Use proactively when...”“Always use for...”“Automatically delegate when...”。
7. 配置 model（可选）：inherit 表示与父代理同模型（默认），fast 表示用快速模型处理简单任务。
8. 配置 readonly（可选）：设为 true 可限制写权限。
9. 编写子代理提示词，依次定义：身份（“You are an [expert]...”）、被调用时的上下文、具体执行步骤、期望输出格式与内容。
10. 使用提示词模板：身份说明 → When invoked 步骤列表 → 详细方法说明 → Report 输出格式 → 遵循的原则或理念。
11. 验证代理模式：独立校验已完成工作，步骤为识别被声明完成的内容、验证实现存在且可用、执行测试或验证步骤、查找遗漏的边界情况，并报告通过项、未完成或损坏项、需解决的具体问题。
12. 调试器模式：捕获错误信息和堆栈、确定复现步骤、定位失败位置、实施最小修复、验证解决方案，并给出根因解释、诊断证据、具体代码修复、测试方法。
13. 安全审计模式：识别安全敏感代码路径、检查常见漏洞、确认密钥未硬编码、审查输入验证，并按 Critical/High/Medium/Low 严重级别报告发现。
14. 代码审查模式：分析代码变更、检查可读性/性能/模式/错误处理、识别代码坏味道和潜在 bug、给出具体改进建议，并输出 ✅ Approved / ⚠️ Approved with caveats / ❌ Changes needed 及问题清单。
15. 遵循最佳实践：每个子代理只承担一个清晰职责、重视 description 的投入、提示词保持简洁直接、将子代理定义纳入版本控制与团队共享、测试 description 能否触发正确的子代理。
16. 避免反模式：不要写“Use for general tasks”这类模糊描述、不要把提示词写到 2000 词、不要创建过多子代理（先从 2-3 个聚焦的开始）。
17. 定稿前过质量清单：description 是否具体说明何时委派、name 是否 kebab-case、是否只有一个清晰职责、提示词是否简洁完整、指令是否可执行、输出格式是否明确、模型配置是否合适。
18. 创建完成后输出提示信息：位置（如 .agent/subagents/[name].md）、用途简述、调用方式（自动委派上下文与显式 /[name] [instruction]），并提示加入“use proactively”等关键词以鼓励委派。
19. 注意：不要用于 Cursor 专用子代理，那种情况应改用 cursor-subagent-creator。

适用边界 · 注意事项

• 任务简单、一次性、不需要隔离上下文时，应使用 Skill 而非子代理。
• 需要 Cursor 专用子代理时，应使用 cursor-subagent-creator 而非本技能。
• 不要创建过多子代理，也不要写模糊描述或超长提示词。