recursive-synthesis について
憲章、組織規約、アーキテクチャ決定など、重要な基礎文書のマルチエージェント統合を調整するスキルです。独立した見解、批判的レビュー、異論の付録、実務者による新鮮な視点の確認を段階的に行い、速度より厳密さを重視します。
主な機能
- 016段階の文書統合プロセス
- 02独立したエージェントの並列意見
- 03原則の順位付けと階層化
- 04批判的コメントと統合
- 05実務者による新鮮な視点のレビュー
- 06未解決の緊張を記す異論の付録
活用シーン
- 01組織のガバナンス文書を作成
- 02関係者間のアーキテクチャ決定を検討
- 03基本原則間の対立を明らかにする
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ curiositech/ some_claude_skills --skill recursive-synthesisインストール後、Claude Code で/recursive-synthesisを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.claude-plugin/plugin.jsonreferences/phase-templates.mdprocess-design.md詳細
再帰的統合
複数のエージェントが協働して文書を統合するプロセスを統括します。複雑で多角的な入力を6段階のプロセスに導き、憲法、憲章、アーキテクチャ上の決定など、厳格な敵対的レビューと統合を必要とする、権威ある基本文書を作成します。
使用する場面
次の用途に使用します:
- 憲法文書(ガバナンス、原則、価値観)
- 複数のステークホルダーの視点を必要とするアーキテクチャ決定記録
- 相反する懸念を含む組織憲章
- 将来の意思決定を規定する基本文書
- 迅速さよりも「正しく仕上げること」が重要な文書
- 相容れない対立点を埋もれさせず、明らかにする必要がある文書
次の用途には使用しません:
- 簡単なドキュメントや README ファイル
- 単著の技術文書
- 短い要約やレポート
- 範囲が明確で、異論のない文書
- 時間的制約のある成果物(このプロセスには6段階以上かかります)
6段階のプロセス
Phase 0: SETUP
│
v
Phase 1: DIVERGENCE ──────────────────────────────────────┐
│ (10 agents write position papers in parallel) │
v │
Phase 2: SYNTHESIS │
│ (Synthesizer reads all 10, creates ranked hierarchy) │
v │
Phase 3: COMMENTARY ──────────────────────────────────────┤
│ (10 agents review synthesis, steel-man + critique) │
v │
Phase 4: CONSOLIDATION │
│ (Lead Architect merges into Soul Document) │
v │
Phase 5: REALITY CHECK │
│ (PM/EM/Design provide fresh-eyes practitioner review)│
v │
Phase 6: FINAL MERGE
│ (Polymath Editor produces Constitution + Guide)
v
OUTPUT: Constitution, Practitioner's Guide, Editorial Notes
フェーズ 0:セットアップ
目的:問題領域を定義し、基本ルールを設定して、エージェントを選定します。
主な決定事項
- 問題の定義:どのような問いや文書を統合しますか?
- エージェントの選定:どの10の知的伝統や視点を採用しますか?
- 基本ルール:
- スチールマン要件(批判する前に、相手の強みを認める)
- 原則の優先順位付けに順位選択投票を用いる
- 解消できない対立点については、異論の付録を設ける
- フェーズ 1~4 では PM/EM/デザインを除外する(フェーズ 5 に新鮮な視点を取り入れるため)
エージェント選定のガイドライン
本当に異なる知的伝統を代表するエージェントを選んでください。
| 分野 | エージェントの例 |
|---|---|
| 哲学 | プラグマティスト、合理主義者、経験主義者、徳倫理学者 |
| エンジニアリング | システム思考家、信頼性エンジニア、セキュリティ専門家、パフォーマンス最適化担当者 |
| デザイン | ユーザーの代弁者、アクセシビリティ推進者、ミニマリスト、ブランド戦略家 |
| ビジネス | プロダクト戦略家、リスク管理者、成長専門家、サステナビリティ推進者 |
| アカデミア | 複雑性理論家、組織心理学者、ゲーム理論家 |
選定基準:
- 認知的多様性を最大限にする(思考スタイルが異なること)
- 各分野における確かな専門性
- 明確な原則を説明できる能力
- 知的誠実さで知られていること
ファイル構成
次のディレクトリ構成を作成します。
synthesis-project/
├── phase-0-setup/
│ ├── problem-definition.md
│ ├── agent-roster.md
│ └── ground-rules.md
├── phase-1-divergence/
│ ├── agent-1-position.md
│ ├── agent-2-position.md
│ └── ... (one per agent)
├── phase-2-synthesis/
│ ├── principle-hierarchy.md
│ └── structural-skeleton.md
├── phase-3-commentary/
│ ├── agent-1-commentary.md
│ ├── agent-2-commentary.md
│ └── ... (one per agent)
├── phase-4-consolidation/
│ ├── soul-document.md
│ └── dissenting-appendix.md
├── phase-5-reality-check/
│ ├── pm-reality-report.md
│ ├── em-reality-report.md
│ └── design-reality-report.md
├── phase-6-final/
│ ├── constitution.md
│ ├── practitioners-guide.md
│ └── editorial-notes.md
└── meta/
├── process-log.md
└── cost-tracking.md
フェーズ 1:発散
目的:知的多様性を最大限に引き出します。各エージェントが独立して執筆します。
実行
- 並列実行:10のエージェントをすべて同時に実行します
- 相互の情報共有なし:エージェントは互いの成果物を見ることができません
- モデルの選択:複雑な哲学的なエージェントには Opus、専門分野に特化した技術的なエージェントには Sonnet を使用します
エージェントプロンプトのテンプレート
You are [AGENT_NAME], an expert in [DOMAIN] with deep knowledge of [SPECIFIC_EXPERTISE].
## Your Task
Write a position paper (1500-2500 words) addressing this question:
[PROBLEM_DEFINITION]
## Your Intellectual Tradition
You approach this from the perspective of [TRADITION]. Your core beliefs include:
- [BELIEF_1]
- [BELIEF_2]
- [BELIEF_3]
## Requirements
1. State your non-negotiable principles clearly
2. Explain WHY these principles matter from your perspective
3. Acknowledge potential tensions with other viewpoints
4. Propose concrete structural recommendations
5. Include specific examples or case studies
## Format
- Start with a 3-sentence executive summary
- Use headers to organize your argument
- End with a ranked list of your top 5 principles
品質ゲート
フェーズ 2 に進む前に、次の項目を確認します。
- 10件すべての立場表明書を受け取っている
- 各文書に明確な原則が記載されている
- 各文書が本当に異なる視点を示している
- エージェントが別のエージェントの立場を単に言い換えていない
フェーズ 2:統合
目的:共通点を見つけ、原則の優先順位を作成します。
実行
- 単独のエージェント:1つの統合担当エージェントが10件すべての文書を読みます
- モデルの選択:Opus(長いコンテキストを横断する深い推論が必要なため)
- 出力:優先順位付きの原則体系と、構成の骨子
統合担当エージェントのプロンプトテンプレート
You are the Synthesizer. You have read 10 position papers from different intellectual traditions on this question:
[PROBLEM_DEFINITION]
## Your Task
### Part 1: Principle Extraction
For each position paper, extract:
1. The 3-5 non-negotiable principles stated
2. The underlying values driving those principles
3. The specific recommendations made
### Part 2: Convergence Analysis
Identify:
1. **Universal principles**: Stated by 8+ agents
2. **Strong consensus**: Stated by 5-7 agents
3. **Significant minority**: Stated by 3-4 agents
4. **Unique contributions**: Stated by 1-2 agents but compelling
### Part 3: Tension Mapping
For each pair of conflicting principles:
1. State the tension clearly
2. Identify if it's reconcilable or fundamental
3. Propose resolution strategies (if reconcilable)
4. Flag for Dissenting Appendix (if fundamental)
### Part 4: Ranked Hierarchy
Using ranked-choice voting logic:
1. Rank all principles by consensus level
2. Break ties by reasoning about which principles subsume others
3. Create a hierarchy: foundational → derived → implementation
### Part 5: Structural Skeleton
Propose a document structure that:
1. Honors the principle hierarchy
2. Gives voice to minority positions
3. Provides actionable guidance
4. Separates philosophy from implementation
## Output Format
Produce two documents:
1. `principle-hierarchy.md`: The ranked principles with justification
2. `structural-skeleton.md`: The proposed document outline
品質ゲート
フェーズ 3 に進む前に、次の項目を確認します。
- 原則の優先順位が明確で、根拠が示されている
- 対立点が明示的に整理されている
- 構成の骨子が主要なテーマすべてに対応している
- いずれの立場表明書も無視されたり、誤って表現されたりしていない
フェーズ 3:コメント
目的:統合結果を敵対的にレビューします。元の各エージェントが批評します。
実行
- 並列実行:10のエージェントをすべて同時に実行します
- スチールマン要件:批判する前に、統合結果の正しい点を必ず認めます
- モデルの選択:フェーズ 1 で各エージェントに使用したものと同じモデルを使います
コメントプロンプトのテンプレート
You are [AGENT_NAME]. You wrote a position paper in Phase 1.
You have now received the Synthesizer's work:
- Principle Hierarchy
- Structural Skeleton
## Your Task
### Part 1: Steel-Man (REQUIRED)
Before any critique, you MUST:
1. Identify 3 things the synthesis got RIGHT about your position
2. Acknowledge where the synthesis improved on your original thinking
3. Note any surprising connections to other agents' positions
### Part 2: Critique
Now you may critique:
1. Where your position was misrepresented
2. Where the ranking undervalues your principles
3. Where the structural skeleton fails to address your concerns
4. Specific wording that contradicts your intent
### Part 3: Constructive Amendments
Propose specific changes:
1. Exact wording modifications
2. Structural reorganization
3. Additional sections needed
4. Principles that should be elevated/demoted
### Part 4: Irreconcilable Tensions
If you believe a fundamental tension exists that CANNOT be resolved:
1. State the tension clearly
2. Explain why it's fundamental (not just difficult)
3. Propose how the Dissenting Appendix should handle it
## Format
- Start with steel-man section (mandatory)
- Use constructive language throughout
- Be specific (line numbers, exact quotes)
- Propose solutions, not just problems
品質ゲート
フェーズ 4 に進む前に、以下を確認してください。
- 10 件のコメントがすべて届いている
- 各コメントにスティールマンのセクションが含まれている
- 批判が具体的で、実行可能である
- 相容れない緊張関係が明確に示されている
フェーズ 4:統合
目的:統合結果とコメントをまとめて、統一されたソウルドキュメントを作成します。
実行
- 単一のエージェント:リードアーキテクト
- モデルの選択:Opus(多数の入力を踏まえた繊細な判断が必要です)
- 出力:ソウルドキュメント+異論の付録
リードアーキテクトのプロンプトテンプレート
You are the Lead Architect. You have:
- The original 10 position papers
- The Synthesizer's principle hierarchy and skeleton
- 10 commentary documents from the original agents
## Your Task
### Part 1: Commentary Integration
For each of the 10 commentaries:
1. Document which critiques you're accepting (and why)
2. Document which critiques you're rejecting (and why)
3. Note any critique that reveals a flaw in the synthesis
### Part 2: Soul Document
Create a single document that:
1. Embodies the principle hierarchy (with accepted modifications)
2. Follows the structural skeleton (with accepted modifications)
3. Speaks with one coherent voice
4. Includes concrete, actionable guidance
5. Is honest about its scope and limitations
### Part 3: Dissenting Appendix
For tensions that could NOT be reconciled:
1. State each tension clearly
2. Present each side's strongest argument
3. Explain why this document took the position it did
4. Acknowledge the legitimate concerns of the minority position
5. Suggest conditions under which this might be revisited
### Part 4: Scope Documentation
Document:
1. What this document IS authoritative about
2. What this document explicitly does NOT address
3. What decisions are deferred to future work
4. What principles might be phased in over time
## Output Format
Produce two documents:
1. `soul-document.md`: The unified founding document
2. `dissenting-appendix.md`: The documented tensions and minority positions
品質ゲート
フェーズ 5 に進む前に、以下を確認してください。
- ソウルドキュメントに一貫した語り口がある
- 主要な立場がすべて公平に反映されている
- 異論の付録で緊張関係が誠実に扱われている
- 対象範囲が明確に記録されている
フェーズ 5:現実性の確認
目的:新鮮な視点を持つ実務者によるレビューです。PM/EM/デザイン担当者はフェーズ 1〜4 に参加していません。
実行
- 3 人のエージェント:プロダクトマネージャー、エンジニアリングマネージャー、デザインリード
- 新鮮な視点:これらのエージェントは、これまでの作業を一切見ていません
- モデルの選択:Opus(シニアレベルの判断が必要です)
- 率直な評価:懐疑的な姿勢で検討することが認められています
新鮮な視点が重要な理由
フェーズ 1〜4 のエージェントは、共通のコンテキストと語彙を築いています。そのため、次のような状態に陥っている可能性があります。
- 哲学的な洗練を過度に重視している
- 実務上の実装を見失っている
- 外部の人には理解しにくい専門用語を使っている
- 明白ではない前提を置いている
新鮮な視点を持つ実務者は、こうした盲点を見つけます。
現実性確認のプロンプトテンプレート
You are the [PM/EM/DESIGN_LEAD]. You are reviewing a founding document for the first time.
You were deliberately EXCLUDED from the creation process. Your job is to bring fresh eyes and practical skepticism.
## The Document
[SOUL_DOCUMENT]
## Your Task
### Part 1: First Impressions
Before deep analysis, note:
1. What's your gut reaction?
2. What's clear vs. confusing?
3. What's missing that you expected?
4. What's present that surprises you?
### Part 2: Practitioner Audit
From your [PM/EM/DESIGN] perspective:
1. Can this actually be implemented?
2. What's the realistic timeline?
3. What resources would this require?
4. What existing constraints does this ignore?
5. What stakeholders would object and why?
### Part 3: Jargon Check
Flag any:
1. Undefined terms
2. Circular definitions
3. Insider language
4. Concepts that need examples
### Part 4: Gap Analysis
What's missing?
1. Processes needed but not defined
2. Responsibilities unclear
3. Metrics undefined
4. Edge cases not addressed
### Part 5: Verdict
Choose ONE:
- **SHIP**: Ready for adoption with minor edits
- **BUILD**: Needs significant work in specific areas
- **COMPLEX**: Fundamentally needs rethinking
Include specific demands for what must change for you to upgrade your verdict.
## Format
- Be direct and concrete
- Use examples from your domain
- Propose solutions, not just problems
- Prioritize your concerns (P0/P1/P2)
品質ゲート
フェーズ 6 に進む前に、以下を確認してください。
- 3 件の現実性レポートがすべて届いている
- 各レポートに判定(SHIP/BUILD/COMPLEX)が含まれている
- 具体的な要求が実行可能である
- 新鮮な視点が本当に新鮮である(フェーズ 1〜4 の内容を言い換えただけではない)
フェーズ 6:最終統合
目的:対象読者に応じた最終成果物を作成します。
実行
- 単一のエージェント:ポリマスエディター
- モデルの選択:Opus(最高品質の文章作成)
- 出力:憲章+実務者向けガイド+編集メモ
ポリマスエディターのプロンプトテンプレート
You are the Polymath Editor. You have:
- The Soul Document (from Phase 4)
- The Dissenting Appendix (from Phase 4)
- Three Reality Reports (from Phase 5)
## Your Task
### Part 1: Address Reality Check Demands
For each P0 and P1 demand from the three Reality Reports:
1. Implement the change OR
2. Document why you're rejecting it
### Part 2: Constitution
Create the definitive founding document:
1. Written for posterity (will be read in 5+ years)
2. Uncompromising on principles
3. Clear on scope and authority
4. Includes Dissenting Appendix (edited for clarity)
5. Stands alone without needing other documents
### Part 3: Practitioner's Guide
Create a practical implementation guide:
1. Written for someone starting TODAY
2. Outside-in structure (start with "what do I do?")
3. Examples and templates
4. FAQ section addressing common questions
5. Phased rollout plan if applicable
### Part 4: Editorial Notes
Document your editorial process:
1. What changed from Soul Document to Constitution
2. Which Reality Check demands were accepted/rejected
3. What you consider the most important principles
4. What you consider the biggest risks
5. Advice for future editors
## Output Format
Produce three documents:
1. `constitution.md`: The authoritative founding document
2. `practitioners-guide.md`: The practical how-to guide
3. `editorial-notes.md`: The editorial process documentation
品質ゲート
最終チェックリスト:
- 憲章に一貫性があり、権威ある内容になっている
- 実務者向けガイドが実行可能である
- 編集メモで主要な決定がすべて説明されている
- 現実性確認で挙がった P0 の要求にすべて対応している
- 異論の付録で緊張関係が誠実に扱われている
モデル選択のガイドライン
| フェーズ | 推奨モデル | 理由 |
|---|---|---|
| フェーズ 1(哲学系エージェント) | Opus | 深い推論と繊細な立場の提示 |
| フェーズ 1(技術系エージェント) | Sonnet | 高速であり、専門分野の知識を活かした高品質な出力も可能 |
| フェーズ 2(統合担当) | Opus | 長いコンテキストと複雑な統合 |
| フェーズ 3(コメント) | フェーズ 1 と同じ | 語り口の一貫性 |
| フェーズ 4(リードアーキテクト) | Opus | 最も高度な判断が必要 |
| フェーズ 5(現実性の確認) | Opus | シニア実務者のシミュレーション |
| フェーズ 6(ポリマスエディター) | Opus | 最高品質の文章作成 |
コスト最適化:予算が限られている場合、フェーズ 1 と 3 では 10 人のエージェントのうち 6〜8 人に Sonnet を使用できます。哲学的に最も複雑な視点には Opus を割り当ててください。
WinDAG による並列化
このプロセスは DAG に自然に対応します。
Wave 1: Phase 1 agents (10 parallel nodes)
│
Wave 2: Phase 2 Synthesizer (1 node, depends on all of Wave 1)
│
Wave 3: Phase 3 commentators (10 parallel nodes, depends on Wave 2)
│
Wave 4: Phase 4 Lead Architect (1 node, depends on all of Wave 3)
│
Wave 5: Phase 5 Reality Check (3 parallel nodes, depends on Wave 4)
│
Wave 6: Phase 6 Polymath Editor (1 node, depends on all of Wave 5)
dag-planner を使って実行グラフを構築してください。
適切に分離して実行するには dag-runtime を使ってください。
アンチパターン
エコーチェンバー化
問題:エージェントが早々に意見を収束させ、多様性が失われます。 解決策:フェーズ 1 と 3 では相互交流を禁止します。異なるシステムプロンプトを使用してください。
コンテキストウィンドウの崩壊
問題:後続のフェーズで、前のフェーズの細かなニュアンスが失われます。 解決策:文書全体ではなく、参照を使用してください。要約は戦略的に行ってください。
複雑さの演出
問題:プロセス自体が成果物より重要になります。 解決策:各フェーズで具体的な成果物を必ず作成してください。文書についてのメタ文書は作成しないでください。
通知の放置
問題:エージェントが、いつまでも届かない人間による承認を待ち続けます 解決策:明確な品質ゲートを定義します。可能な場合は、フェーズの移行を自動化します。
複雑さがもたらすメタリスク
問題:統合プロセス自体が複雑すぎて、役に立ちません 解決策:憲章は、それを作成したプロセスよりもシンプルでなければなりません。そうでなければ、失敗です。
関連項目
references/process-design.md- このプロセスが有効な理由references/phase-templates.md- コピーして使えるプロンプトテンプレートteam-builder- エージェントの選定用dag-planner- 実行計画用orchestrator- 複数フェーズの調整用