ce:compound

Name: ce:compound
Author: everyinc

github.com/everyinc開発25.8k394 回インストール今日更新

リポジトリ

ce:compound について

ce:compoundは、最近解決した問題を `docs/solutions/` 以下の構造化ファイルに記録するスキルです。並行調査とレビューを調整し、解決策を検索可能にしてチームで再利用しやすくします。

主な機能

01最近の問題解決の記録
02並行する調査エージェントの調整
03検索可能なYAML frontmatterの追加
04関連する解決ドキュメントの検索
05フルとライトのワークフローに対応

活用シーン

01修正したばかりのバグの記録
02再利用可能な技術ガイダンスの保存
03解決ドキュメントの重複確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce:compound

インストール後、Claude Code で/ce:compoundを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/

resolution-template.md

references/

schema.yaml

yaml-schema.md

詳細

/compound

最近解決した問題を記録するため、複数のサブエージェントを並行して連携させます。

目的

解決策を、検索や今後の参照に適した YAML フロントマター付きの構造化ドキュメントとして docs/solutions/ に記録し、コンテキストが新鮮なうちに問題の解決方法を残します。効率を最大化するため、サブエージェントを並行して使用します。

「compound」という名前の理由：記録した解決策は、チームの知識を積み重ねていきます。問題を初めて解決するときには調査が必要です。解決策を記録しておけば、次に同じ問題が発生したときには数分で済みます。知識は積み重なっていきます。

使用方法

/ce:compound                    # Document the most recent fix
/ce:compound [brief context]    # Provide additional context hint

サポートファイル

これらのファイルは、ワークフローの永続的な契約です。必要な手順で必要に応じて読み込んでください。スキルの開始時にまとめて読み込まないでください。

references/schema.yaml — フロントマターの標準フィールドと列挙値（YAML の検証時に読み込みます）
references/yaml-schema.md — problem_type からディレクトリへのカテゴリ対応表（分類時に読み込みます）
assets/resolution-template.md — 新規ドキュメントのセクション構成（組み立て時に読み込みます）

サブエージェントを起動するときは、スキル間のパスを参照しなくても契約を確認できるよう、関連ファイルの内容をタスクプロンプトに渡してください。

実行戦略

続行する前に、プラットフォームのブロッキング質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使って、ユーザーに2つの選択肢を提示してください。質問ツールが利用できない場合は、選択肢を提示してユーザーの返答を待ってください。

1. Full (recommended) — the complete compound workflow. Researches,
   cross-references, and reviews your solution to produce documentation
   that compounds your team's knowledge.

2. Lightweight — same documentation, single pass. Faster and uses
   fewer tokens, but won't detect duplicates or cross-reference
   existing docs. Best for simple fixes or long sessions nearing
   context limits.

モードを事前に選択してはいけません。この質問を省略してはいけません。ユーザーが選択するまで待ってください。

ユーザーが Full を選んだ場合：続行する前に、追加の質問を1つしてください。実行中のハーネス（Claude Code、Codex、Cursor）を検出し、次のように質問します。

Would you also like to search your [harness name] session history
for relevant knowledge to help the Compound process? This adds
time and token usage.

ユーザーが「はい」と答えた場合は、Phase 1 で Session Historian をディスパッチします。「いいえ」と答えた場合はスキップします。lightweight モードでは、この質問をしないでください。

Full モード

<critical_requirement> 主要な出力は1つのファイル、つまり最終ドキュメントです。

Phase 1 のサブエージェントは、オーケストレーターに TEXT DATA を返します。Write、Edit を使用したり、ファイルを作成したりしてはいけません。ファイルを書き込むのはオーケストレーターだけです。Phase 2 では解決策ドキュメントを作成し、Discoverability Check で不足が見つかった場合に限り、プロジェクトの指示ファイル（AGENTS.md または CLAUDE.md）を少し編集します。指示ファイルの編集はメンテナンスであり、2つ目の成果物ではありません。これにより、今後のエージェントがナレッジストアを見つけられるようにします。 </critical_requirement>

Phase 0.5：自動メモリのスキャン

Phase 1 のサブエージェントを起動する前に、システムプロンプトに挿入された自動メモリブロックから、記録対象の問題に関連するメモを確認します。

システムプロンプトのコンテキストにすでに含まれている「user's auto-memory」というラベルのブロックを探します（Claude Code のみ）。MEMORY.md のエントリーはそこにインラインで表示されます。
ブロックがない、空である、または Claude Code 以外のプラットフォームの場合は、この手順をスキップし、変更を加えずに Phase 1 に進みます。
記録対象の問題に関連する情報がないか、エントリーを確認します。キーワードの一致ではなく、意味に基づいて判断してください。
関連するエントリーが見つかった場合は、ラベル付きの抜粋ブロックを用意します。

## Supplementary notes from auto memory
Treat as additional context, not primary evidence. Conversation history
and codebase findings take priority over these notes.

[relevant entries here]

このブロックを、Phase 1 の Context Analyzer と Solution Extractor のタスクプロンプトに追加のコンテキストとして渡します。メモリの内容が最終ドキュメント（調査手順や根本原因分析など）に含まれる場合は、その出所が将来の読者に明確になるよう「(auto memory [claude])」とタグ付けします。

関連するエントリーが見つからなかった場合は、メモリのコンテキストを渡さずに Phase 1 に進みます。

Phase 1：調査

調査用のサブエージェントを起動します。各エージェントはオーケストレーターにテキストデータを返します。

ディスパッチ順序：

Context Analyzer、Solution Extractor、Related Docs Finder を並行して（バックグラウンドで）起動します。
次に、session-historian をフォアグラウンドでディスパッチします。バックグラウンドエージェントがアクセスできない可能性のある、作業ディレクトリ外のセッションファイルを読み込みます。
バックグラウンドエージェントの処理中にフォアグラウンドのディスパッチが実行されるため、経過時間は増えません。

<parallel_tasks>

1. コンテキストアナライザー

会話履歴を抽出します
references/schema.yaml を読み込み、列挙値の検証とトラックの分類を行います
problem_type からトラック（bug または knowledge）を判定します
問題の種類、コンポーネント、およびトラックに応じたフィールドを特定します：
- Bug トラック：symptoms、root_cause、resolution_type
- Knowledge トラック：applies_when（symptoms/root_cause/resolution_type は任意）
オーケストレーターから自動メモの抜粋が提供された場合、補足的な証拠として取り入れます
references/yaml-schema.md を読み込み、docs/solutions/ 内のカテゴリへのマッピングを確認します
[sanitized-problem-slug]-[date].md の形式でファイル名を提案します
次の内容を返します：YAML フロントマターのひな形（problem_type からマッピングした category: フィールドを含める必要があります）、カテゴリのディレクトリパス、提案するファイル名、該当するトラック
スキーマやマッピングのファイルを参照せずに、記憶に基づいて列挙値、カテゴリ、フロントマターのフィールドを作り出すことはありません
Bug トラックのフィールドを Knowledge トラックの学びに適用したり、その逆を行ったりしません

2. ソリューション抽出器

トラック（bug と knowledge）の分類のために references/schema.yaml を読み込みます
problem_type のトラックに応じて出力構成を調整します
オーケストレーターから自動メモの抜粋が提供された場合、補足的な証拠として取り入れます。会話履歴と検証済みの修正を優先し、メモの内容が会話と矛盾する場合は、注意すべき背景情報としてその矛盾を記載します

Bug トラックの出力セクション：

問題：問題の説明（1～2 文）
症状：観察可能な症状（エラーメッセージや動作）
うまくいかなかったこと：調査に失敗した試みと、その理由
解決策：実際の修正。該当する場合はコード例（修正前／修正後）
これが機能する理由：根本原因の説明と、解決策が問題に対処できる理由
再発防止：再発を避けるための方法、ベストプラクティス、テストケース。該当する場合は、具体的なコード例（Gem の設定、テストのアサーション、リンティングルールなど）を含めます

Knowledge トラックの出力セクション：

背景：このガイダンスのきっかけとなった状況、ギャップ、または摩擦
ガイダンス：有用な場合はコード例を添えた、実践方法、パターン、または推奨事項
重要な理由：このガイダンスに従うこと、または従わないことの根拠と影響
適用する場面：このガイダンスが当てはまる条件や状況
例：この実践方法を具体的に示す、修正前／修正後または使用例

3. 関連ドキュメントファインダー

docs/solutions/ で関連ドキュメントを検索します
相互参照とリンクを特定します
関連する GitHub issue を見つけます
関連する学習ドキュメントやパターンドキュメントのうち、現在では古くなっている、矛盾している、または範囲が広すぎる可能性があるものにフラグを立てます
作成中の新しいドキュメントとの重複を評価します。評価は、問題の記述、根本原因、解決アプローチ、参照ファイル、防止ルールの 5 つの観点で行います。スコアは次のとおりです:
- High: 4〜5 の観点が一致 — 本質的に同じ問題を再度解決している
- Moderate: 2〜3 の観点が一致 — 同じ領域だが、切り口や解決策が異なる
- Low: 0〜1 の観点が一致 — 関連はあるが別物
返すもの: リンク、関連性、更新候補、重複評価 (スコア + 一致した観点)

検索戦略 (効率化のための grep ファーストのフィルタリング):

問題のコンテキストからキーワードを抽出します: モジュール名、技術用語、エラーメッセージ、コンポーネントの種類
問題のカテゴリが明確な場合は、検索を一致する docs/solutions/<category>/ ディレクトリに絞り込みます
ネイティブのコンテンツ検索ツール (例: Claude Code の Grep) を使用して、コンテンツを読む前に候補ファイルを事前にフィルタリングします。大文字と小文字を区別せず、frontmatter のフィールドを対象とした複数の検索を並列で実行します。以下はテンプレートのパターンです -- 実際のキーワードに置き換えてください:
- title:.*<keyword>
- tags:.*(<keyword1>|<keyword2>)
- module:.*<module name>
- component:.*<component>
検索結果が 25 件を超える場合は、より具体的なパターンで再実行します。3 件未満の場合は、全文検索に範囲を広げます
関連性を評価するために、候補ファイルの frontmatter (先頭 30 行) のみを読みます
完全に読むのは strong/moderate の一致のみです
生のファイル内容ではなく、絞り込んだリンクと関連性を返します

GitHub issue 検索:

関連する issue を検索するには、gh CLI を優先して使用します: gh issue list --search "<keywords>" --state all --limit 5。gh がインストールされていない場合は、利用可能であれば GitHub MCP ツール (例: unblocked data_retrieval) にフォールバックします。どちらも利用できない場合は、GitHub issue 検索をスキップし、出力でスキップしたことを記載します。

</parallel_tasks>

4. Session Historian（フォアグラウンド、上記の起動後 — ユーザーがオプトインした場合のみ）

ユーザーが追加の質問でセッション履歴を拒否した場合は、完全にスキップします
compound-engineering:research:session-historian としてディスパッチします
フォアグラウンドでディスパッチします — このエージェントは作業ディレクトリ外のセッションファイル（~/.claude/projects/、~/.codex/sessions/、~/.cursor/projects/）を読み取りますが、バックグラウンドエージェントはアクセスできない場合があります
同じプロジェクトの過去の Claude Code、Codex、Cursor のセッションを検索し、関連する調査コンテキストを見つけます
すべてのプラットフォームにわたってリポジトリ名でセッションを関連付けます（メインのチェックアウト、ワークツリー、Conductor のワークスペースのセッションを照合します）
ディスパッチプロンプトに、次の内容を渡します：
- 記録対象の問題の具体的な説明 — 一般的なトピックではなく、具体的な問題（エラーメッセージ、モジュール名、何が壊れ、どのように修正されたか）を記載します。エージェントはこの情報に基づいて調査結果を絞り込みます。
- 現在の Git ブランチと作業ディレクトリ
- 次の指示：「この特定の問題に直接関連する過去のセッションの調査結果のみを提示してください。同じセッションやブランチの無関係な作業は無視してください。」
- 出力形式：
```
次のセクションで回答を構成してください（調査結果がないセクションは省略してください）：
- 以前に試したこと：この特定の問題に対して過去に試したアプローチ
- うまくいかなかったこと：過去のセッションでこの問題に対して失敗した試み
- 主な決定事項：この問題について下された選択と、その理由
- 関連するコンテキスト：この問題のドキュメント作成に直接役立つ、過去のセッションからのその他の情報
```
ユーザーが設定した権限設定を適用するため、mode パラメーターは省略します
中位モデル（例：Claude Code の model: "sonnet"）でディスパッチします — 調査結果の統合は複合アセンブリに組み込まれ、最先端の推論は必要ありません
戻り値：過去のセッションの調査結果を構造化してまとめたもの。見つからない場合は「関連する過去のセッションはありません」

フェーズ 2：組み立てと書き込み

<sequential_tasks>

先へ進む前に、フェーズ 1 のすべてのサブエージェントが完了するまで待ちます。

オーケストレーションを担当するエージェント（メインの会話）が、以下の手順を実行します。

フェーズ 1 のサブエージェントからテキストの結果をすべて収集します

書き込む内容を決める前に、関連ドキュメント検索エージェントによる重複の評価を確認します。

重複度	対応
高 — 既存のドキュメントが同じ問題、根本原因、解決策を扱っている	重複したドキュメントを作成するのではなく、既存のドキュメントを最新の情報（新しいコード例、更新された参照情報、追加の予防策など）で更新します。既存ドキュメントのパスと構成はそのまま維持します。
中程度 — 同じ問題領域だが、観点、根本原因、解決策が異なる	通常どおり新しいドキュメントを作成します。統合の見直しを提案するため、重複についてフェーズ 2.5 に伝えます。
低またはなし	通常どおり新しいドキュメントを作成します。

更新ではなく新規作成を避ける理由：同じ問題と解決策を説明する 2 つのドキュメントは、いずれ必ず内容に食い違いが生じます。新しい情報のほうが新鮮で信頼できるため、すぐに統合が必要になる 2 つ目のドキュメントを作成するのではなく、既存のドキュメントに取り込みます。

既存のドキュメントを更新する場合は、ファイルパスとフロントマターの構成を維持します。解決策、コード例、予防策、古くなった参照情報を更新します。フロントマターに last_updated: YYYY-MM-DD フィールドを追加します。問題の捉え方が大きく変わっていない限り、タイトルは変更しません。

利用可能な場合は、セッション履歴の調査結果を取り込みます。セッション履歴リサーチャーが過去のセッションから関連情報を返した場合：
- 調査の行き詰まりや失敗したアプローチを、バグの記録では**「機能しなかったこと」のセクションに、ナレッジの記録では「コンテキスト」**のセクションに取り込みます
- セッションをまたぐパターンを活用して、**「予防」または「重要な理由」**のセクションを充実させます
- 将来の読者が情報の出所を把握できるよう、セッション由来の内容には「(session history)」とタグ付けします
- 調査結果が乏しい場合、または「関連する過去のセッションがない」場合は、セッションの情報を使わずに進めます
収集した要素から完全な Markdown ファイルを組み立て、新しいドキュメントのセクション構成を確認するために assets/resolution-template.md を読みます
YAML フロントマターを references/schema.yaml に照らして検証します
必要に応じてディレクトリを作成します：mkdir -p docs/solutions/[category]/
ファイルを書き込みます。更新した既存のドキュメント、または新しい docs/solutions/[category]/[filename].md のいずれかです

新しいドキュメントを作成する場合、ユーザーが明示的に別の構成を求めない限り、assets/resolution-template.md のセクション順を維持します。

</sequential_tasks>

フェーズ 2.5：選択的な更新の確認

新しい学びを書き込んだ後、この新しい解決策が古いドキュメントを更新すべき根拠となるかどうかを判断します。

ce:compound-refresh はデフォルトの後続手順ではありません。新しい学びから、古い学びやパターンのドキュメントが不正確になった可能性がある場合に、選択的に使用します。

次のいずれかに該当する場合は、ce:compound-refresh を実行するのが適切です。

関連する学びやパターンのドキュメントが、新しい修正と矛盾するアプローチを推奨している
新しい修正が、古いドキュメントに記載された解決策に明らかに取って代わる
今回の作業でリファクタリング、移行、名前変更、依存関係のアップグレードを行い、古いドキュメント内の参照が無効になった可能性が高い
パターンのドキュメントが、範囲を広く取りすぎている、古くなっている、または更新後の実態ではサポートされなくなっている
関連ドキュメント検索で、同じ問題領域における確度の高い更新候補が見つかった
関連ドキュメント検索で既存のドキュメントとの中程度の重複が報告され、重点的なレビューによって統合の機会が見つかる可能性がある

次の場合は、ce:compound-refresh を実行するのは適切ではありません。

関連ドキュメントが見つからなかった
関連ドキュメントが新しい学びと引き続き整合しているように見える
重複が表面的なもので、従来のガイダンスに影響しない
更新に、根拠が乏しい広範な履歴レビューが必要となる

次のルールに従ってください。

明らかに古くなった候補が1つある場合は、新しい学びを書き込んだ後、対象を絞ったスコープのヒントを付けて ce:compound-refresh を実行します
同じ領域に複数の候補がある場合は、そのモジュール、カテゴリ、またはパターンセットを対象に更新を実行するか、ユーザーに確認します
コンテキストに余裕がない場合や軽量モードの場合は、広範な更新に自動的に範囲を広げないでください。代わりに、スコープのヒントを添えて次の手順として ce:compound-refresh を提案します

ce:compound-refresh を実行または提案する場合は、渡す引数を明示してください。役立つ範囲のうち最も狭いものを優先します。

学びやパターンのドキュメントが1つだけ古くなっている可能性が高い場合は、具体的なファイル
関連する複数のドキュメントをレビューする必要がある場合は、モジュール名またはコンポーネント名
あるソリューション領域にずれが集中している場合は、カテゴリ名
古いガイダンスが docs/solutions/patterns/ にある場合は、パターンのファイル名またはトピック

例：

/ce:compound-refresh plugin-versioning-requirements
/ce:compound-refresh payments
/ce:compound-refresh performance-issues
/ce:compound-refresh critical-patterns

1つのスコープのヒントを指定しても、変更が1つのドメイン、カテゴリ、またはパターン領域内の複数箇所に及ぶ場合は、関連する複数のドキュメントが対象となることがあります。

ユーザーが明示的に広範な調査を希望していない限り、引数なしで ce:compound-refresh を実行しないでください。

まず、必ず新しい学びを記録してください。更新は対象を絞った保守の後続手順であり、ドキュメント化の前提条件ではありません。

発見可能性の確認

学びを書き込み、更新するかどうかを判断した後、プロジェクトの指示ファイルに従うと、エージェントがドキュメント化された領域の作業を始める前に docs/solutions/ を見つけて検索できるかを確認します。ナレッジストアの価値はエージェントが情報を見つけられて初めて蓄積されるため、この確認は毎回行います。

ルートレベルの指示ファイル（AGENTS.md、CLAUDE.md、またはその両方）が存在するか確認します。ファイルを読み、実質的な内容を含むファイルを判断してください。一方のファイルが、もう一方を @ で読み込むだけのシムである場合があります（例：CLAUDE.md の内容が @AGENTS.md のみ、またはその逆）。実質的な内容を含むファイルを評価および編集の対象とし、シムは無視してください。どちらのファイルも存在しない場合は、この確認を完全にスキップします。
指示ファイルを読んだエージェントが、次の3点を把握できるか評価します。
- 文書化された解決策を検索できるナレッジストアが存在すること
- 効果的に検索するために必要な、その構造に関する情報（カテゴリ別の構成、module、tags、problem_type などの YAML フロントマターのフィールド）
- いつ検索すべきか（機能の実装、問題のデバッグ、または文書化された領域での意思決定の前。そこにはバグ、ベストプラクティス、ワークフローのパターン、その他の組織的な知見が記載されている場合があります）
これは文字列の一致ではなく、意味に基づく評価です。情報はアーキテクチャのセクションの1行でも、注意点の箇条書きでも、複数の箇所に分かれていても、正確なパス docs/solutions/ を一度も使わずに表現されていてもかまいません。指示ファイルを読めば、エージェントがナレッジストアの存在を知り、活用すると合理的に判断できる場合は、この確認に合格です。
上記の趣旨がすでに満たされている場合は、何もせず次に進みます。
満たされていない場合： a. ファイルの既存の構成、語調、情報量に基づいて、記述を自然に追加できる場所を特定します。新しいセクションを作成する前に、関連性が最も高いセクション（アーキテクチャツリー、ディレクトリ一覧、ドキュメントのセクション、規約のブロックなど）に1行で追加できないか確認してください。既存のセクションへの1行追加が、ほぼ常に新しい見出しを設けるより適切です。ファイルに明確なセクション構成があり、関連する場所がまったくない場合に限り、最後の手段として新しいセクションを追加します。 b. 3点を伝えるための最小限の追記案を作成します。ファイルの既存のスタイルと情報量に合わせてください。追記ではプラグインではなくナレッジストアそのものを説明してください。プラグインを使わないエージェントにとっても有用である必要があります。

口調は説明的にし、指示的にならないようにしてください。タイミングは指示ではなく説明として表現します。「実装やデバッグを始める前に必ず検索する」ではなく、「文書化された領域を実装またはデバッグする際に関連する」のようにします。「実装前に必ず検索する」といった命令形の指示は、ワークフローに専用の検索手順が含まれている場合に、重複した読み込みを引き起こします。目的は認知を促すことです。エージェントがフォルダーの存在と内容を把握し、いつ参照するかは自ら判断できるようにします。

表現の調整例（テンプレートではありません。ファイルに合わせてください）：

既存のディレクトリ一覧やアーキテクチャのセクションがある場合は、1行追加します。
```
docs/solutions/  # 過去の問題の解決策（バグ、ベストプラクティス、ワークフローのパターン）を文書化したもの。カテゴリ別に整理され、YAML フロントマター（module、tags、problem_type）を含む
```
ファイルに自然な追記先がない場合は、小さな見出し付きセクションを追加します。
```
## 文書化された解決策

`docs/solutions/` — 過去の問題の解決策（バグ、ベストプラクティス、ワークフローのパターン）を文書化したものです。カテゴリ別に整理され、YAML フロントマター（`module`、`tags`、`problem_type`）を含みます。文書化された領域を実装またはデバッグする際に役立ちます。
```
c. フルモードでは、これが重要な理由をユーザーに説明します。このリポジトリで作業するエージェント（新しいセッション、他のツール、プラグインを使わない共同作業者を含む）は、指示ファイルに記載がなければ docs/solutions/ を確認する必要があると気づきません。追記案とその挿入先を示し、プラットフォームのブロッキング質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）を使って、編集前にユーザーの同意を得ます。質問ツールが使えない場合は、追記案を提示してユーザーの返答を待ちます。軽量モードでは、1行の注記を出力して次に進みます。

フェーズ 3：任意の強化

続行する前に、フェーズ 2 が完了するまで待ってください。

<parallel_tasks>

問題の種類に応じて、任意で専門エージェントを呼び出し、ドキュメントをレビューします。

performance_issue → compound-engineering:review:performance-oracle
security_issue → compound-engineering:review:security-sentinel
database_issue → compound-engineering:review:data-integrity-guardian
コード中心の問題 → 常に compound-engineering:review:code-simplicity-reviewer を実行し、さらにリポジトリの主要なスタックに合った kieran reviewer も実行します。
- Ruby/Rails → compound-engineering:review:kieran-rails-reviewer も実行
- Python → compound-engineering:review:kieran-python-reviewer も実行
- TypeScript/JavaScript → compound-engineering:review:kieran-typescript-reviewer も実行
- その他のスタック → kieran reviewer は不要

</parallel_tasks>

軽量モード

<critical_requirement> シングルパスの代替手段 — 同じドキュメントを、より少ないトークンで作成します。

このモードでは並列サブエージェントを完全に省略します。オーケストレーターがすべての作業をシングルパスで行い、相互参照や重複検出を行わずに同じ解決策ドキュメントを作成します。 </critical_requirement>

オーケストレーター（メインの会話）が、次のすべてを順番に1回で実行します。

会話から抽出：会話履歴から問題と解決策を特定します。また、システムプロンプトに挿入された「ユーザーの自動メモ」ブロックがあれば（Claude Code のみ）、そこも確認し、会話履歴を補足する関連メモを使用します。最終ドキュメントに取り込んだメモ由来の内容には「(auto memory [claude])」を付けます
分類：references/schema.yaml と references/yaml-schema.md を読み、トラック（バグまたはナレッジ）、カテゴリ、ファイル名を決定します
最小限のドキュメントを作成：適切なトラックのテンプレートを assets/resolution-template.md から使用して、docs/solutions/[category]/[filename].md を作成します。内容は次のとおりです。
- トラックに適した項目を含む YAML フロントマター
- バグトラック：問題、根本原因、主要なコードスニペットを含む解決策、予防策を1つ
- ナレッジトラック：コンテキスト、主要な例を含むガイダンス、適用上の注意点を1つ
専門エージェントによるレビューを省略（フェーズ 3）して、コンテキストを節約します

軽量モードの出力：

✓ Documentation complete (lightweight mode)

File created:
- docs/solutions/[category]/[filename].md

[If discoverability check found instruction files don't surface the knowledge store:]
Tip: Your AGENTS.md/CLAUDE.md doesn't surface docs/solutions/ to agents —
a brief mention helps all agents discover these learnings.

Note: This was created in lightweight mode. For richer documentation
(cross-references, detailed prevention strategies, specialized reviews),
re-run /compound in a fresh session.

サブエージェントは起動しません。並列タスクも実行しません。書き込むファイルは1つです。

軽量モードでは重複チェック（Related Docs Finder サブエージェント）を省略します。そのため、既存のドキュメントと重複するドキュメントが作成される場合があります。それは許容されます。ce:compound-refresh が後で検出します。明確で対象が限定された更新先がある場合にのみ、ce:compound-refresh を提案してください。軽量モードのセッションで、大規模な更新作業に広げないでください。

記録する内容

問題の症状：正確なエラーメッセージ、観察可能な動作
試した調査手順：うまくいかなかったこととその理由
根本原因の分析：技術的な説明
有効な解決策：コード例を含む段階的な修正方法
予防策：今後問題を避ける方法
相互参照：関連する問題やドキュメントへのリンク

前提条件

問題が解決済みである（進行中ではない）解決策が正常に動作することを確認済みである単純なタイプミスや明白なエラーではない、複雑な問題である

作成されるもの

整理されたドキュメント：

ファイル：docs/solutions/[category]/[filename].md

問題から自動検出されるカテゴリ：

バグトラック：

build-errors/
test-failures/
runtime-errors/
performance-issues/
database-issues/
security-issues/
ui-bugs/
integration-issues/
logic-errors/

ナレッジトラック：

best-practices/
workflow-issues/
developer-experience/
documentation-gaps/

よくある間違いと避け方

❌ 間違い	✅ 正しい方法
サブエージェントが `context-analysis.md` や `solution-draft.md` のようなファイルを書き出す	サブエージェントはテキストデータを返し、オーケストレーターが最終ファイルを1つ書き出す
調査と組み立てを並行して進める	調査を完了してから、組み立てを行う
ワークフロー中に複数のファイルを作成する	解決策のドキュメントを1つだけ書き出すか更新する：`docs/solutions/[category]/[filename].md`（見つけやすくするため、プロジェクトの指示ファイルを小規模に編集する場合もあります）
既存のドキュメントが同じ問題を扱っているのに、新しいドキュメントを作成する	重複の評価を確認し、重複度が高い場合は既存のドキュメントを更新する

成功時の出力

✓ Documentation complete

Auto memory: 2 relevant entries used as supplementary evidence

Subagent Results:
  ✓ Context Analyzer: Identified performance_issue in brief_system, category: performance-issues/
  ✓ Solution Extractor: 3 code fixes, prevention strategies
  ✓ Related Docs Finder: 2 related issues
  ✓ Session History: 3 prior sessions on same branch, 2 failed approaches surfaced

Specialized Agent Reviews (Auto-Triggered):
  ✓ performance-oracle: Validated query optimization approach
  ✓ kieran-rails-reviewer: Code examples meet Rails conventions
  ✓ code-simplicity-reviewer: Solution is appropriately minimal

File created:
- docs/solutions/performance-issues/n-plus-one-brief-generation.md

This documentation will be searchable for future reference when similar
issues occur in the Email Processing or Brief System modules.

What's next?
1. Continue workflow (recommended)
2. Link related documentation
3. Update other references
4. View documentation
5. Other

成功時の出力を表示した後、プラットフォームのブロッキング質問ツールを使って「次は何をしますか？」の選択肢を提示してください（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）。質問ツールが利用できない場合は、番号付きの選択肢を提示し、ユーザーの返答を待ってから続行してください。ユーザーが選択する前にワークフローを続行したり、ターンを終了したりしないでください。

代替出力（重複度が高いため既存のドキュメントを更新する場合）：

✓ Documentation updated (existing doc refreshed with current context)

Overlap detected: docs/solutions/performance-issues/n-plus-one-queries.md
  Matched dimensions: problem statement, root cause, solution, referenced files
  Action: Updated existing doc with fresher code examples and prevention tips

File updated:
- docs/solutions/performance-issues/n-plus-one-queries.md (added last_updated: 2026-03-24)

複利の考え方

これにより、知識が複利的に蓄積されるシステムが作られます。

初めて「ブリーフ生成における N+1 クエリ」を解決する → 調査（30 分）
解決策をドキュメント化する → docs/solutions/performance-issues/n-plus-one-briefs.md（5 分）
次に同様の問題が発生する → 素早く参照する（2 分）
知識が蓄積される → チームの知見が深まる

フィードバックループ：

Build → Test → Find Issue → Research → Improve → Document → Validate → Deploy
    ↑                                                                      ↓
    └──────────────────────────────────────────────────────────────────────┘

エンジニアリング作業の各単位は、その後の作業を難しくするのではなく、容易にするべきです。

自動呼び出し

<auto_invoke> <trigger_phrases> - "うまくいきました" - "修正されました" - "今は動いています" - "問題は解決しました" </trigger_phrases>

<manual_override> 自動検出を待たずにすぐドキュメント化するには、/ce:compound [context] を使用します。 </manual_override> </auto_invoke>

出力

最終的な学びを docs/solutions/ に直接書き込みます。

適用可能な専門エージェント

問題の種類に応じて、以下のエージェントがドキュメントを改善できます。

コード品質とレビュー

compound-engineering:review:kieran-rails-reviewer：Rails のベストプラクティスに沿ってコード例をレビューします
compound-engineering:review:kieran-python-reviewer：Python のベストプラクティスに沿ってコード例をレビューします
compound-engineering:review:kieran-typescript-reviewer：TypeScript のベストプラクティスに沿ってコード例をレビューします
compound-engineering:review:code-simplicity-reviewer：解決策のコードが最小限で明確であることを確認します
compound-engineering:review:pattern-recognition-specialist：アンチパターンや繰り返し発生する問題を特定します

特定分野の専門家

compound-engineering:review:performance-oracle：performance_issue カテゴリの解決策を分析します
compound-engineering:review:security-sentinel：security_issue の解決策に脆弱性がないかレビューします
compound-engineering:review:data-integrity-guardian：database_issue に関連するマイグレーションやクエリをレビューします

強化と調査

compound-engineering:research:best-practices-researcher：業界のベストプラクティスを解決策に取り入れます
compound-engineering:research:framework-docs-researcher：フレームワークやライブラリのドキュメントを参照するリンクを追加します

呼び出すタイミング

自動トリガー（任意）：ドキュメント化後に、改善のためエージェントを実行できます
手動トリガー：ユーザーは /ce:compound の完了後にエージェントを呼び出し、より詳細なレビューを依頼できます

基本情報

作者: everyinc
リポジトリ: everyinc/compound-engineering-plugin
カテゴリ: 開発
インストール数: 394
GitHub スター: 25,775

問題を報告