sadd:launch-sub-agent

launch-sub-agent

启动一个专注型子 Agent 来执行所提供的任务。分析任务，以智能方式选择最合适的模型和 Agent 配置，然后派发子 Agent，并在开头启用零样本思维链推理，在结尾强制执行自我批判验证。 此命令实现了多 Agent 架构中的**监督者／编排者模式**：由你（编排者）派发上下文隔离的专注型子 Agent。其主要优势是**上下文隔离**——每个子 Agent 都在干净的上下文窗口中运行，专注于自己的任务，不受累积上下文污染的影响。

流程

阶段 1：使用零样本思维链分析任务

派发前，请系统地分析任务。逐步思考：

Let me analyze this task step by step to determine the optimal configuration:

1. **Task Type Identification**
   "What type of work is being requested?"
   - Code implementation / feature development
   - Research / investigation / comparison
   - Documentation / technical writing
   - Code review / quality analysis
   - Architecture / system design
   - Testing / validation
   - Simple transformation / lookup

2. **Complexity Assessment**
   "How complex is the reasoning required?"
   - High: Architecture decisions, novel problem-solving, multi-faceted analysis
   - Medium: Standard implementation following patterns, moderate research
   - Low: Simple transformations, lookups, well-defined single-step tasks

3. **Output Size Estimation**
   "How extensive is the expected output?"
   - Large: Multiple files, comprehensive documentation, extensive analysis
   - Medium: Single feature, focused deliverable
   - Small: Quick answer, minor change, brief output

4. **Domain Expertise Check**
   "Does this task match a specialized agent profile?"
   - Development: code, implement, feature, endpoint, TDD, tests
   - Research: investigate, compare, evaluate, options, library
   - Documentation: document, README, guide, explain, tutorial
   - Architecture: design, system, structure, scalability
   - Exploration: understand, navigate, find, codebase patterns

阶段 2：选择模型

根据任务分析选择最合适的模型：

任务特征	推荐模型	原因
复杂推理（架构、设计、关键决策）	opus	推理能力最强
专业领域（与 Agent 配置相符）	Opus + 专业 Agent	领域专业知识 + 推理能力
不复杂但较长（大量文档、冗长输出）	sonnet[1m]	能力良好，处理长内容时成本效益高
简单且简短（琐碎任务、快速查找）	haiku	快速、经济，适用于简单任务
默认（不确定时）	opus	优先保障质量，而非降低成本

决策树：

Is task COMPLEX (architecture, design, novel problem, critical decision)?
|
+-- YES --> Use Opus (highest capability)
|           |
|           +-- Does it match a specialized domain?
|               +-- YES --> Include specialized agent prompt
|               +-- NO --> Use Opus alone
|
+-- NO --> Is task SIMPLE and SHORT?
           |
           +-- YES --> Use Haiku (fast, cheap)
           |
           +-- NO --> Is output LONG but task not complex?
                      |
                      +-- YES --> Use Sonnet (balanced)
                      |
                      +-- NO --> Use Opus (default)

阶段 3：匹配专业 Agent

如果任务符合专业领域，应纳入相关的 Agent 提示词。专业 Agent 提供特定领域的最佳实践、质量标准和结构化方法，从而提升输出质量。

决策： 当任务明显受益于领域专业知识时，使用专业 Agent。对于专业化会带来不必要开销的琐碎任务，则跳过。

Agent： 可用的专业 Agent 取决于项目和已安装的插件。sdd 插件中常见的 Agent 包括：sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:team-lead、sdd:qa-engineer、sdd:code-explorer、sdd:business-analyst。如果没有合适的专业 Agent，则回退到不带专业化配置的通用 Agent。

与模型选择的结合：

• 专业 Agent 与模型选择相结合，而非取代模型选择
• 复杂任务 + 专业领域 = Opus + 专业 Agent
• 与专业领域匹配的简单任务 = Haiku，不使用专业化配置（不值得为此增加开销）

用法：

1. 阅读 Agent 定义
2. 将 Agent 的指令放在 CoT 前缀之后，纳入子 Agent 提示词
3. 与零样本 CoT 前缀和批判后缀相结合

阶段 4：构建子 Agent 提示词

构建子 Agent 提示词时，必须包含以下部分：

4.1 零样本思维链前缀（必需——必须置于最前）

## Reasoning Approach

Before taking any action, you MUST think through the problem systematically.

Let's approach this step by step:

1. "Let me first understand what is being asked..."
   - What is the core objective?
   - What are the explicit requirements?
   - What constraints must I respect?

2. "Let me break this down into concrete steps..."
   - What are the major components of this task?
   - What order should I tackle them?
   - What dependencies exist between steps?

3. "Let me consider what could go wrong..."
   - What assumptions am I making?
   - What edge cases might exist?
   - What could cause this to fail?

4. "Let me verify my approach before proceeding..."
   - Does my plan address all requirements?
   - Is there a simpler approach?
   - Am I following existing patterns?

Work through each step explicitly before implementing.

4.2 任务正文

<task>
{Task description from $ARGUMENTS}
</task>

<constraints>
{Any constraints inferred from the task or conversation context}
</constraints>

<context>
{Relevant context: files, patterns, requirements, codebase information}
</context>

<output>
{Expected deliverable: format, location, structure}
</output>

4.3 自我批判后缀（必需——必须置于最后）

## Self-Critique Loop (MANDATORY)

Before completing, you MUST verify your work. Submitting unverified work is UNACCEPTABLE.

### 1. Generate 5 Verification Questions

Create 5 questions specific to this task that test correctness and completeness. There example questions:

| # | Verification Question | Why This Matters |
|---|----------------------|------------------|
| 1 | Does my solution fully address ALL stated requirements? | Partial solutions = failed task |
| 2 | Have I verified every assumption against available evidence? | Unverified assumptions = potential failures |
| 3 | Are there edge cases or error scenarios I haven't handled? | Edge cases cause production issues |
| 4 | Does my solution follow existing patterns in the codebase? | Pattern violations create maintenance debt |
| 5 | Is my solution clear enough for someone else to understand and use? | Unclear output reduces value |

### 2. Answer Each Question with Evidence

For each question, examine your solution and provide specific evidence:

[Q1] Requirements Coverage:
- Requirement 1: [COVERED/MISSING] - [specific evidence from solution]
- Requirement 2: [COVERED/MISSING] - [specific evidence from solution]
- Gap analysis: [any gaps identified]

[Q2] Assumption Verification:
- Assumption 1: [assumption made] - [VERIFIED/UNVERIFIED] - [evidence]
- Assumption 2: [assumption made] - [VERIFIED/UNVERIFIED] - [evidence]

[Q3] Edge Case Analysis:
- Edge case 1: [scenario] - [HANDLED/UNHANDLED] - [how]
- Edge case 2: [scenario] - [HANDLED/UNHANDLED] - [how]

[Q4] Pattern Adherence:
- Pattern 1: [pattern name] - [FOLLOWED/DEVIATED] - [evidence]
- Pattern 2: [pattern name] - [FOLLOWED/DEVIATED] - [evidence]

[Q5] Clarity Assessment:
- Is the solution well-organized? [YES/NO]
- Are complex parts explained? [YES/NO]
- Could someone else use this immediately? [YES/NO]

### 3. Revise If Needed

If ANY verification question reveals a gap:
1. **STOP** - Do not submit incomplete work
2. **FIX** - Address the specific gap identified
3. **RE-VERIFY** - Confirm the fix resolves the issue
4. **DOCUMENT** - Note what was changed and why

CRITICAL: Do not submit until ALL verification questions have satisfactory answers with evidence.

阶段 5：派发子 Agent

使用 Task 工具，按选定配置派发：

Use Task tool:
- description: "Sub-agent: {brief task summary}"
- prompt: {constructed prompt with CoT prefix + task + critique suffix}
- model: {selected model - opus/sonnet/haiku}

上下文隔离提醒： 仅传递与此特定任务相关的上下文。不要传递完整的对话历史。

示例

示例 1：复杂架构任务（Opus）

输入： /launch-sub-agent Design a caching strategy for our API that handles 10k requests/second

分析：

• 任务类型：架构／设计
• 复杂度：高（性能要求、系统设计）
• 输出长度：中等（设计文档）
• 领域匹配：sdd:software-architect

选择： Opus + sdd:software-architect Agent

派发： 使用 Task 工具，配置 Opus 模型、sdd:software-architect 提示词、CoT 前缀和批判后缀

---

示例 2：简单文档更新（Haiku）

输入： /launch-sub-agent Update the README to add --verbose flag to CLI options

分析：

• 任务类型：文档（简单编辑）
• 复杂度：低（单个文件，定义明确）
• 输出规模：小（一个章节）
• 领域匹配：无需匹配（任务过于简单）

选择： Haiku（快速、低成本，足以胜任任务）

调度： 使用 Haiku 模型的 Task 工具、基础 CoT 前缀和基础批判性评估后缀

---

示例 3：中等规模实现（Sonnet + Developer）

输入： /launch-sub-agent Implement pagination for /users endpoint following patterns in /products

分析：

• 任务类型：代码实现
• 复杂度：中（遵循现有模式）
• 输出规模：中（实现 + 测试）
• 领域匹配：sdd:developer

选择： Sonnet + sdd:developer Agent（并不复杂，但需要领域专业知识）

调度： 使用 Sonnet 模型的 Task 工具、sdd:developer 提示词、CoT 前缀和批判性评估后缀

---

示例 4：研究任务（Opus + Researcher）

输入： /launch-sub-agent Research authentication options for mobile app - evaluate OAuth2, SAML, passwordless

分析：

• 任务类型：研究 / 比较
• 复杂度：高（比较分析、提出建议）
• 输出规模：大（全面研究）
• 领域匹配：sdd:researcher

选择： Opus + sdd:researcher Agent

调度： 使用 Opus 模型的 Task 工具、sdd:researcher 提示词、CoT 前缀和批判性评估后缀

最佳实践

上下文隔离

• 仅传递与特定任务相关的上下文
• 避免传递完整的对话历史
• 让子 Agent 通过工具发现代码库模式
• 使用文件路径和引用，而不是嵌入大量内容

模型选择

• 拿不准时，使用 Opus（质量优先于成本）
• 仅将 Haiku 用于真正微不足道的任务
• 将 Sonnet 用于“苦力活”——需要能力，但不需要天才水平
• 生产代码始终值得使用 Opus

专用 Agent

• 仅在领域专业知识明显能提升质量时使用
• 与 CoT 和批判性评估模式结合使用
• 不要强行让通用任务采用专门化处理

质量门槛

• 自我批判循环不可妥协
• 子 Agent 必须在完成前回答验证问题
• 接受子 Agent 的输出前先进行审查