launch-sub-agent

launch-sub-agent

タスクを実行するため、特定の作業に特化したサブエージェントを起動します。タスクを分析して最適なモデルとエージェント構成を適切に選択し、最初にゼロショットの思考連鎖による推論を行い、最後に必須の自己批評による検証を実施するサブエージェントをディスパッチします。 このコマンドは、分離されたコンテキストを持つ特化型サブエージェントをディスパッチする、マルチエージェントアーキテクチャの**スーパーバイザー／オーケストレーターパターン**を実装します。主な利点は**コンテキストの分離**です。各サブエージェントは、蓄積されたコンテキストによる汚染のないクリーンなコンテキストウィンドウで、特定のタスクに集中して動作します。

プロセス

フェーズ 1：ゼロショット CoT によるタスク分析

ディスパッチする前に、タスクを体系的に分析します。順を追って考えてください。

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	最大限の推論能力
専門分野（エージェントのプロファイルに一致）	Opus + 特化型エージェント	分野の専門知識と推論能力を両立
複雑ではないが長いタスク（大量のドキュメント、冗長な出力）	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：特化型エージェントの選定

タスクが特定の専門分野に該当する場合、該当するエージェントのプロンプトを組み込みます。特化型エージェントは、分野固有のベストプラクティス、品質基準、体系的な手法を提供し、出力の品質を高めます。

判断： 分野の専門知識によって明確な効果が見込める場合は、特化型エージェントを使用します。専門化によるオーバーヘッドが不要な簡単なタスクでは使用しません。

エージェント： 利用可能な特化型エージェントは、プロジェクトとインストール済みのプラグインによって異なります。sdd プラグインでよく使用されるエージェントには、sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:code-explorer、sdd:business-analyst、sdd:code-reviewer、sdd:tech-writer があります。適切な特化型エージェントが利用できない場合は、特化させずに汎用エージェントを使用します。

モデル選択との組み合わせ：

• 特化型エージェントはモデル選択の代わりではなく、モデル選択と組み合わせます。
• 複雑なタスク＋専門分野＝Opus＋特化型エージェント
• 専門分野に該当する単純なタスク＝特化なしの Haiku（オーバーヘッドに見合わないため）

使用方法：

1. エージェントの定義を読みます。
2. CoT プレフィックスの後に、エージェントの指示をサブエージェントのプロンプトに含めます。
3. ゼロショット CoT プレフィックスおよび批評サフィックスと組み合わせます。

フェーズ 4：サブエージェントのプロンプトを作成

必須要素を含めてサブエージェントのプロンプトを作成します。

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：サブエージェントをディスパッチ

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 エージェント

ディスパッチ： Opus モデル、sdd:software-architect のプロンプト、CoT プレフィックス、批評サフィックスを指定して Task ツールを使用

---

例 2：シンプルなドキュメント更新（Haiku）

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

分析：

• タスクの種類：ドキュメント（簡単な編集）
• 複雑さ：低（単一ファイル、要件が明確）
• 出力サイズ：小（1 つのセクション）
• ドメイン適合性：不要（簡単すぎるため）

選択： Haiku（高速、低コスト、タスクに十分）

ディスパッチ： Haiku モデルを使った Task ツール、基本的な CoT プレフィックス、基本的な批評サフィックス

---

例 3：中程度の実装（Sonnet + Developer）

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

分析：

• タスクの種類：コード実装
• 複雑さ：中（既存のパターンに従う）
• 出力サイズ：中（実装 + テスト）
• ドメイン適合性：sdd:developer

選択： Sonnet + sdd:developer エージェント（複雑ではないものの、ドメインの専門知識が必要）

ディスパッチ： 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 エージェント

ディスパッチ： Opus モデルを使った Task ツール、sdd:researcher プロンプト、CoT プレフィックス、批評サフィックス

ベストプラクティス

コンテキストの分離

• 特定のタスクに関連するコンテキストだけを渡します
• 会話履歴全体を渡すのは避けます
• サブエージェントには、ツールを使ってコードベースのパターンを見つけさせます
• 大量のコンテンツを埋め込むのではなく、ファイルパスと参照を使います

モデルの選択

• 迷ったときは、Opus を使います（コストより品質を優先）
• Haiku は、本当に簡単なタスクに限って使います
• Sonnet は「単純作業」に使います。能力は必要ですが、卓越した知性までは必要ありません
• 本番コードには、常に Opus を使う価値があります

専門エージェント

• ドメインの専門知識によって品質が明らかに向上する場合に使います
• CoT と批評のパターンを組み合わせます
• 一般的なタスクに専門性を無理に適用しないでください

品質ゲート

• 自己批評のループは必須です
• サブエージェントは、完了前に検証の質問に回答する必要があります
• 受け入れる前に、サブエージェントの出力をレビューします