launch-sub-agent

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

launch-sub-agent

<task> Launch a focused sub-agent to execute the provided task. Analyze the task to intelligently select the optimal model and agent configuration, then dispatch a sub-agent with Zero-shot Chain-of-Thought reasoning at the beginning and mandatory self-critique verification at the end. </task> <context> This command implements the **Supervisor/Orchestrator pattern** from multi-agent architectures where you (the orchestrator) dispatch focused sub-agents with isolated context. The primary benefit is **context isolation** - each sub-agent operates in a clean context window focused on its specific task without accumulated context pollution. </context>

<task> 启动一个专注的子Agent来执行指定任务。分析任务以智能选择最优模型和Agent配置，然后调度一个在初始阶段采用Zero-shot Chain-of-Thought推理、在结束阶段强制进行自我校验的子Agent。 </task> <context> 该命令实现了多Agent架构中的**Supervisor/Orchestrator pattern**，其中你（编排器）调度具有独立上下文的专注子Agent。主要优势是**上下文隔离**——每个子Agent在干净的上下文窗口中运行，专注于其特定任务，不会受到累积上下文污染。 </context>

Process

流程

Phase 1: Task Analysis with Zero-shot CoT

阶段1：基于Zero-shot CoT的任务分析

Before dispatching, analyze the task systematically. Think through step by step:

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

在调度之前，系统地分析任务。逐步思考：

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

Phase 2: Model Selection

阶段2：模型选择

Select the optimal model based on task analysis:

Task Profile	Recommended Model	Rationale
Complex reasoning (architecture, design, critical decisions)	`opus`	Maximum reasoning capability
Specialized domain (matches agent profile)	Opus + Specialized Agent	Domain expertise + reasoning power
Non-complex but long (extensive docs, verbose output)	`sonnet[1m]`	Good capability, cost-efficient for length
Simple and short (trivial tasks, quick lookups)	`haiku`	Fast, cost-effective for easy tasks
Default (when uncertain)	`opus`	Optimize for quality over cost

Decision Tree:

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)

基于任务分析选择最优模型：

任务特征	推荐模型	理由
复杂推理（架构、设计、关键决策）	`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)

Phase 3: Specialized Agent Matching

阶段3：专业Agent匹配

If the task matches a specialized domain, incorporate the relevant agent prompt. Specialized agents provide domain-specific best practices, quality standards, and structured approaches that improve output quality.

Decision: Use specialized agent when task clearly benefits from domain expertise. Skip for trivial tasks where specialization adds unnecessary overhead.

Agents: Available specialized agents depends on project and plugins installed. Common agents from the

sdd

plugin include:

sdd:developer

sdd:researcher

sdd:software-architect

sdd:tech-lead

sdd:team-lead

sdd:qa-engineer

sdd:code-explorer

sdd:business-analyst

. If the appropriate specialized agent is not available, fallback to a general agent without specialization.

Integration with Model Selection:

Specialized agents are combined WITH model selection, not instead of
Complex task + specialized domain = Opus + Specialized Agent
Simple task matching domain = Haiku without specialization (overhead not justified)

Usage:

Read the agent definition
Include the agent's instructions in the sub-agent prompt AFTER the CoT prefix
Combine with Zero-shot CoT prefix and Critique suffix

如果任务匹配专业领域，整合相关的Agent提示词。专业Agent提供领域特定的最佳实践、质量标准和结构化方法，可提升输出质量。

决策： 当任务明显能从领域专业知识中获益时使用专业Agent。对于琐碎任务跳过，因为专业化会增加不必要的开销。

Agents: 可用的专业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（无需专业化，开销不合理）

使用方法：

阅读Agent定义
在子Agent提示词中，将Agent的指令放在CoT前缀之后
与Zero-shot CoT前缀和校验后缀结合

Phase 4: Construct Sub-Agent Prompt

阶段4：构建子Agent提示词

Build the sub-agent prompt with these mandatory components:

使用以下必填组件构建子Agent提示词：

4.1 Zero-shot Chain-of-Thought Prefix (REQUIRED - MUST BE FIRST)

4.1 Zero-shot Chain-of-Thought前缀（必填 - 必须放在最前面）

markdown

undefined

markdown

undefined

Reasoning Approach

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

Let's approach this step by step:

"Let me first understand what is being asked..."
- What is the core objective?
- What are the explicit requirements?
- What constraints must I respect?
"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?
"Let me consider what could go wrong..."
- What assumptions am I making?
- What edge cases might exist?
- What could cause this to fail?
"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.

undefined

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

Let's approach this step by step:

"Let me first understand what is being asked..."
- What is the core objective?
- What are the explicit requirements?
- What constraints must I respect?
"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?
"Let me consider what could go wrong..."
- What assumptions am I making?
- What edge cases might exist?
- What could cause this to fail?
"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.

undefined

4.2 Task Body

4.2 任务主体

markdown

<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>

markdown

<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 Suffix (REQUIRED - MUST BE LAST)

4.3 自我校验后缀（必填 - 必须放在最后）

markdown

undefined

markdown

undefined

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

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]

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:

STOP - Do not submit incomplete work
FIX - Address the specific gap identified
RE-VERIFY - Confirm the fix resolves the issue
DOCUMENT - Note what was changed and why

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

undefined

If ANY verification question reveals a gap:

STOP - Do not submit incomplete work
FIX - Address the specific gap identified
RE-VERIFY - Confirm the fix resolves the issue
DOCUMENT - Note what was changed and why

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

undefined

Phase 5: Dispatch Sub-Agent

阶段5：调度子Agent

Use the Task tool to dispatch with the selected configuration:

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

Context isolation reminder: Pass only context relevant to this specific task. Do not pass entire conversation history.

使用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}

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

Examples

示例

Example 1: Complex Architecture Task (Opus)

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

Input:

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

Analysis:

Task type: Architecture / design
Complexity: High (performance requirements, system design)
Output size: Medium (design document)
Domain match: sdd:software-architect

Selection: Opus + sdd:software-architect agent

Dispatch: Task tool with Opus model, sdd:software-architect prompt, CoT prefix, critique suffix

输入：

/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前缀、校验后缀

Example 2: Simple Documentation Update (Haiku)

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

Input:

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

Analysis:

Task type: Documentation (simple edit)
Complexity: Low (single file, well-defined)
Output size: Small (one section)
Domain match: None needed (too simple)

Selection: Haiku (fast, cheap, sufficient for task)

Dispatch: Task tool with Haiku model, basic CoT prefix, basic critique suffix

输入：

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

分析：

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

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

调度： 使用Task工具，配置为Haiku模型、基础CoT前缀、基础校验后缀

Example 3: Moderate Implementation (Sonnet + Developer)

示例3：中等难度实现（Sonnet + Developer）

Input:

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

Analysis:

Task type: Code implementation
Complexity: Medium (follow existing patterns)
Output size: Medium (implementation + tests)
Domain match: sdd:developer

Selection: Sonnet + sdd:developer agent (non-complex but needs domain expertise)

Dispatch: Task tool with Sonnet model, sdd:developer prompt, CoT prefix, critique suffix

输入：

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

分析：

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

选择： Sonnet + sdd:developer agent（非复杂但需要领域专业知识）

调度： 使用Task工具，配置为Sonnet模型、sdd:developer提示词、CoT前缀、校验后缀

Example 4: Research Task (Opus + Researcher)

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

Input:

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

Analysis:

Task type: Research / comparison
Complexity: High (comparative analysis, recommendations)
Output size: Large (comprehensive research)
Domain match: sdd:researcher

Selection: Opus + sdd:researcher agent

Dispatch: Task tool with Opus model, sdd:researcher prompt, CoT prefix, critique suffix

输入：

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

分析：

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

选择： Opus + sdd:researcher agent

调度： 使用Task工具，配置为Opus模型、sdd:researcher提示词、CoT前缀、校验后缀

Best Practices

最佳实践

Context Isolation

上下文隔离

Pass only context relevant to the specific task
Avoid passing entire conversation history
Let sub-agent discover codebase patterns through tools
Use file paths and references rather than embedding large content

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

Model Selection

模型选择

When in doubt, use Opus (quality over cost)
Use Haiku only for truly trivial tasks
Use Sonnet for "grunt work" - needs capability but not genius
Production code always deserves Opus

不确定时，使用Opus（质量优先于成本）
仅对真正琐碎的任务使用Haiku
对“繁重工作”使用Sonnet——需要能力但无需顶尖水平
生产代码始终值得使用Opus

Specialized Agents

专业Agent

Use when domain expertise clearly improves quality
Combine with CoT and critique patterns
Don't force specialization on general tasks

当领域专业知识明显提升质量时使用
与CoT和校验模式结合
不要在通用任务上强制专业化

Quality Gates

质量关卡

Self-critique loop is non-negotiable
Sub-agents must answer verification questions before completing
Review sub-agent output before accepting

自我校验循环是不可协商的
子Agent在完成前必须回答验证问题
在接受前评审子Agent的输出