triangulate-diagnosis

Triangulate Diagnosis

運用上のデフォルトを使って実行モードを選択します。 サブエージェントの依頼がない場合は、diagnoseを呼び出して単一のインライン診断を行い、 そのスコープを明記して、このワークフローを終了します。独立した三者検証として提示してはいけません。

以下の3パスの分岐には、3人のワーカーを対象とするユーザー指定のスコープと、 個別のコンテキストが実際に確認されていることが必要です。いずれかが得られない場合は、 許可や独立性を捏造せず、その制限を報告します。分離されたレポートを比較し、 結論の一致または不一致を記録します。多数派の意見を、そのフィードバックループが裏付ける以上の 強い証拠として扱ってはいけません。

このスキルは、ほかの小規模なスキルを統括します。

• diagnose：各サブエージェントが実行する、再現、仮説立案、特定の規律あるループです。
• to-spec：一致した診断または決定を仕様として記録します。
• to-tickets：実行可能な作業が必要な場合に、フォローアップ用チケットを作成します。
• wayfinder：1回の診断では広すぎる、または不明瞭なバグ領域をマッピングします。

Phase 0：共通ブリーフを作成する

作業を振り分ける前に、すべてのサブエージェントに一字一句そのまま渡すバグのブリーフをまとめます。 これが唯一の共通コンテキストです。3つの診断が独立性を保てるよう、解釈を加えず事実に限定します。 自分の仮説や原因の推測は含めてはいけません。

ブリーフには、次の内容を含める必要があります。

• ユーザーが説明した正確な症状。エラー文、誤った出力、発生タイミング、スクリーンショットなどを含みます。
• コードへの到達方法：リポジトリのパス、サービス、エントリーポイント、関連するコマンド。
• 会話中にすでに判明している再現手順、フィクスチャ、環境に関する注記。
• 厳守すべき制約：動作し続けなければならないものと、対象範囲外のもの。
• REFERENCE.mdに記載された必須の出力仕様。

証拠を共通ブリーフ、委任する診断、または永続的なレポートに含める前に、正規の diagnoseのシークレット秘匿境界を適用します。

ブリーフの内容を変える事実が不足しており、それを持っているのがユーザーだけの場合は、 作業を振り分ける前に、進行を妨げている点について簡潔な質問を1つだけ尋ねます。 それ以外の場合は、そのまま進めます。

Phase 1：独立した3つの診断に振り分ける

依頼されたスコープと実際のホストサポートの範囲内に限り、3人の診断ワーカーを同時に実行します。 各ワーカーは次のとおりです。

• 共通ブリーフを使ってdiagnoseスキルを実行します。
• 独立して作業します。サブエージェントに自分の推測を伝えてはいけません。また、サブエージェント同士が互いの結果を見られないようにします。
• REFERENCE.mdで定義された構造化された診断レポートを返します。根本原因、証拠、フィードバックループ、修正箇所、確信度、除外した代替案を含めます。

有益な違いを生み出すため、共通ブリーフに加えて、各サブエージェントには異なる視点を与えます。

1. 再現優先：フィードバックループの構築と、バグを引き起こした変更の二分探索を優先します。
2. データフロー：モジュールを通じて入力を端から端まで追跡し、境界、型、結合を疑います。
3. 最近の変更／環境：最近のコミット、設定、依存関係、インフラ、タイミングを疑います。

この視点は、最初に調べる場所を決めるものであり、到達すべき結論を決めるものではありません。 各ワーカーは、証拠が導く先をたどる必要があります。

サブエージェントがフィードバックループを構築できなかったと報告した場合は、そのレポートを 低い確信度のものとして扱い、Phase 2でその旨を明記します。

フェーズ 2：収束

3つのレポートを集めて比較します。短い収束サマリーを作成します。

• 合意された根本原因：サブエージェントのうち少なくとも2つが独立して特定した原因を1つにまとめます。表現を調整し、合意した各レポートから最も強い根拠を引用します。
• 相違点：意見が異なる点と、その理由を示します。
• 独自の知見：代替案の除外、関連するバグ、テスト境界の不足など、1つのサブエージェントだけが明らかにした実際の知見です。
• 確信度：3つすべてが共通のフィードバックループを伴って収束した場合は「高」、3つのうち2つが合意した場合は「中」、3つの見解が分かれた場合、またはいずれもループを構築していない場合は「低」または「保留」とします。

判断ゲート：

• 3つすべて、または3つのうち2つが収束：合意された根本原因を用いてフェーズ 3 に進みます。
• 3者の見解が分かれる場合、または意見の分かれ目がユーザーのみが持つ情報に依存する場合：停止します。根拠とともに原因候補を報告し、どれを追究するか尋ねます。ユーザーの依頼範囲に追加の確認作業が含まれている場合に限り、追加のタイブレーカー担当ワーカーを使用できます。

ユーザーが完全自律実行を明示的に依頼していない限り、何かを書く前に収束サマリーをユーザーに提示します。

フェーズ 3：合意内容を仕様として記録

収集済みのコンテキストとして収束サマリーを渡し、to-spec を呼び出します。

• 合意された根本原因を、診断仕様の中心にします。
• 合意された修正箇所またはアプローチを、「Decision / Solution」のたたき台にします。
• 除外した代替案を「Options Considered」に記載します。
• 独自の知見を「Evidence」、「Testing Decisions」、または「Open Questions」に記載します。
• 確信度が「中」または「低」の場合は、ステータスを Proposed に設定し、未解決の相違点を未解決の質問として列挙します。

仕様を docs/specs/<slug>.md に保存または更新します。

フェーズ 4：必要に応じてフォローアップチケットを作成

合意内容から実行可能な作業が生じる場合は、診断仕様または意思決定仕様を親として to-tickets を呼び出します。作成されるチケットは、次の場所に配置します。

docs/tickets/<spec-slug>/<NN>-<ticket-slug>.md

各チケットには、実装内容、受け入れ基準、明示的なブロッカー、フロンティアの状態、検証への期待を含めます。

ユーザーが診断と文書化のみを依頼した場合は、仕様内のセクションとしてフォローアップ作業を記載し、チケットファイルは作成しません。

最終回答

最終回答は簡潔にします。

• 合意された原因を1行で示します。
• 確信度を示します。
• 仕様のパスを示します。
• 作成した場合は、チケットフォルダーまたはチケットのパスを示します。
• 未解決の質問または人による判断が必要な事項があれば示します。

移植性に関する注意

依頼された各パスでは、明確に区別され、観察可能な形で隔離されたホストワーカーを使用します。同時実行できない場合は、コンテキストを分離したままワーカーを順次実行します。ホストがコンテキストをまったく分離できない場合は、分離できない旨を報告し、同じ前提に基づく3つのパスを実行しないでください。表示されているメモを消去しても、分離が確立されたことにはなりません。