懐疑駆動開発

概要

確信のある回答は正しい回答ではありません。長時間のセッションでは、仮定が誰にも気づかれないまま「事実」に変わっていきます。懐疑駆動開発とは、新鮮なコンテキストを持つレビュアーを具現化する規律です。その特徴は、承認ではなく反論に偏ったレビュアーが、非自明な出力が確定する前に審査することです。

これは /review ではありません。/review は完成した成果物に対する最終判定です。これはその過程での姿勢です。非自明な決定は、軌道修正がまだ安上がりなうちに精査されます。

いつ使うか

以下のいずれかが当てはまるとき、決定は非自明です。

• 分岐ロジックを導入または変更する
• モジュールまたはサービスの境界を越える
• 型システムやコンパイラが検証できないプロパティを主張する（スレッド安全性、べき等性、順序、不変量）
• その正確さが将来の読み手には見えないコンテキストに依存する
• その影響範囲が回復不可能である（本番環境へのデプロイ、データマイグレーション、パブリックAPI の変更）

次のような場合に、このスキルを適用してください。

• 不確実な状況で建築上の決定を下そうとしている
• 非自明なコードをコミットしようとしている
• 自明でない事実を主張しようとしている（「これは安全である」「これはスケールする」「これは仕様に一致する」）
• 完全には理解していないコードで作業している

使わないケース:

• 機械的な操作（リネーム、フォーマット、ファイル移動）
• 明確で曖昧でないユーザー指示に従う
• 既存コードを読むまたは要約する
• 正確性が明白な1行の変更
• 純粋なツール操作（テスト実行、ファイルリスト表示）
• ユーザーが検証より速度を明確に要求している場合

すべてのキーストロークを疑えば、何も船出しません。このスキルは上記で定義された非自明な決定にのみ適用されます。

制約の読み込み

このスキルはメインセッションオーケストレーター用に設計されており、ステップ3（以下の詳細な DOUBT）で新鮮なコンテキストを持つレビュアーを生成できます。

• このスキルをペルソナの skills: frontmatter に追加しないでください。 ステップ3に従うペルソナは別のペルソナを生成することになります。これは references/orchestration-patterns.md で明確に禁止されているオーケストレーションのアンチパターン（「ペルソナは他のペルソナを呼び出さない」）です。
• サブエージェントコンテキストの内部からこのスキルを適用している場合（Claude Code がネストされたサブエージェント生成を防止する場合）：推奨される方法は、懐疑駆動がネストで実行できないことをユーザーに提示し、メインセッションに処理させることです。最終手段として、劣化した自己質問フォールバックが存在します。ARTIFACT + CONTRACT を新しい自己プロンプトとして書き直し、以前の推論から明確に分離し、ステップ1～5を実行します。これは新鮮なコンテキストレビューではない（あなたは自分のコンテキストを持ち込む）ため、結果を劣化したものとしてフラグを立て、ユーザーにアクセスできるときはエスカレーションを優先します。

プロセス

スキルを適用するときに、このチェックリストをコピーしてください。

懐疑サイクル:
- [ ] ステップ1: CLAIM — クレームと重要性を記述した
- [ ] ステップ2: EXTRACT — 推論を除去し、成果物と契約を分離した
- [ ] ステップ3: DOUBT — 新鮮なコンテキストを持つレビュアーを敵対的なプロンプトで呼び出した
- [ ] ステップ4: RECONCILE — すべての指摘を成果物のテキストに対して分類した
- [ ] ステップ5: STOP — 停止条件を満たした（自明な指摘、3サイクル、またはユーザーオーバーライド）

ステップ1: CLAIM — 何が確立されるかを表面化する

決定を2～3行で命名します。

CLAIM: 「新しいキャッシング層は、仕様で説明されている
        読み取り中心のワークロードではスレッドセーフである。」
WHY THIS MATTERS: ここでの競争状態はユーザーデータを破損させ、
                  QA での検出が難しい。

クレームをそれほどコンパクトに書けない場合、あなたは直感を持っていて、決定ではありません。それを精査する前に表面化させてください。

ステップ2: EXTRACT — 最小のレビュー可能単位

新鮮なコンテキストのレビュアーは旅ではなく、成果物と契約が必要です。

• コード：全体のファイルではなく、差分または関数
• 決定：3～5文の提案と、それが満たすべき制約
• 主張：クレームと、それを支えるとされる証拠（ステップ1の CLAIM ブロックとは別に保持。それは検査下のオーケストレーターの仮説です）

推論を除去してください。結論を渡せば、結論の検証が返されます。ユニットはレビュアーが1回で心に留められるほど小さくなければなりません。500行のPRならば、最初に分解してください。

ステップ3: DOUBT — 新鮮なコンテキストを持つレビュアーを呼び出す

レビュアーのプロンプトは敵対的でなければなりません。フレーミングは答えを決めます。

敵対的レビュー。この成果物で何が間違っているかを見つけてください。
著者が過剰に確信していると仮定してください。以下を探してください：
- 明記されていない仮定
- 処理されていないエッジケース
- 隠れた結合または共有状態
- 契約を違反できる方法
- これが破るかもしれない既存の慣例
- 予期しない入力下での障害モード

検証するな。要約するな。問題を見つけるか、徹底的な検査後、
何も見つけられないことを明確に述べよ。

ARTIFACT: <成果物をペーストする>
CONTRACT: <契約をペーストする>

ARTIFACT + CONTRACT のみを渡してください。CLAIM を渡さないでください。 レビュアーに結論を手渡すと、合意に向けて偏ります。レビュアーは、成果物が契約を満たすかどうかを独立して判定する必要があります。

Claude Code では、agents/ 内のロールベースのレビュアーは設計上分離されたコンテキストで始まり、ここで使用可能です。ロスター および ドメインごとのマッチについては agents/ を参照してください。

上記の敵対的なプロンプトは、ペルソナのデフォルト応答形式よりも優先されます。 code-reviewer のようなペルソナは、強みと弱みの両方を持つバランスの取れた判定を生成するように書かれています。懐疑駆動には問題のみの出力が必要です。敵対的なプロンプトを逐語的に呼び出しに貼り付けて、ペルソナのデフォルトをオーバーライドしてください。ペルソナの応答形式を明確にオーバーライドできない場合は、敵対的なプロンプトを含む一般的なサブエージェントにフォールバックしてください。

クロスモデルエスカレーション

単一モデルのレビュアーは、元の著者と盲点を共有しています。異なるアーキテクチャの冷たいモデルはそれを捉えます。懐疑駆動は既に非自明な決定についてのオプトインなので、そのスコープ内でクロスモデルを提供することはスキルの価値の一部であり、オプションの摩擦ではありません。

インタラクティブセッション：常に提供します。沈黙に省略しません。

ステップ1：ユーザーに尋ねる

上記のステップ3の単一モデルレビュー後、しかし RECONCILE の前に、一時停止して尋ねます。

「単一モデルのレビューが完了しました。クロスモデルの別の意見が必要ですか？オプション：Gemini CLI、Codex CLI、手動外部レビュー（別の場所に貼り付けます）、またはスキップ。」

この質問はすべてのインタラクティブな懐疑サイクルで必須です。低リスクに見える成果物でも。ユーザーが、ユーザーが、コストがそれに値するかどうかを決定します。エージェントの仕事は選択肢を表面化することです。

ステップ2：ユーザーが CLI を選択した場合 — 確認してから呼び出す

1. ツールが PATH にあるかどうか確認します（which gemini、which codex）。
2. 完全なプロンプトを渡す前に、それが機能するかテストします（gemini --version など）。古い、または壊れたバイナリは which に合格しても実入力で失敗することがあります。
3. 必須フラグ、認証、env 変数（API キーなど）を含む、正確な呼び出しを確認します。実装は異なります。決してそれを仮定しません。
4. ARTIFACT + CONTRACT + 敵対的なプロンプトのみを渡します。セッションコンテキストなし、CLAIM なし。
5. シェルエスケープに注意してください。成果物に引用符、$(...)、またはバッククォートが含まれている場合、インラインの -p "…" より stdin（echo … | gemini）またはヒアドックを優先します。疑わしい場合は、実行する前にユーザーに呼び出しを確認させてください。
6. 出力をステップ4（RECONCILE）に取ります。

成果物をシェル引用符付き引数に補間しないでください。 コード、マークダウン、およびレビュープロンプトはルーチンにバッククォート、$(...)、およびクォート文字を含み、プロンプトを切り詰めるか、埋め込まれたシェルを実行します。完全なプロンプトをファイルに書き込み、stdin を通してパイプします。

例の形式（インストールされたツールに対して必ずフラグを確認してください — 実装およびバージョン間で構文が異なります）：

# 敵対的なプロンプト + ARTIFACT + CONTRACT を一時ファイルに最初に書き込みます。
# その後、stdin 経由でパイプしてください。これにより、成果物内のシェルメタ文字は無効のままです。

# Codex（読み取り専用サンドボックスは CLI があなたのワークスペースに書き込むことを防止します）：
codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md

# Gemini（'--approval-mode plan' は読み取り専用；'-p ""' は非対話型モードをトリガーし、
# プロンプトは stdin から読み込まれます）：
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md

読み取り専用サンドボックスは重要な詳細です。疑惑の成果物自体に指示（意図的なまたは偶然的なプロンプトインジェクション）が含まれていることがあり、クロスモデル CLI はそれ以外の場合あなたのワークスペースに対して実行されます。

ステップ3：CLI が利用不可またはエラーが発生した場合

失敗を明確に表面化します。次のいずれかを提案します：手動で実行、別のツールを試す、またはスキップ。単一モデルに沈黙でフォールバックしません。クロスモデルが起こらなかったことをユーザーが知る必要があります。

ステップ4：ユーザーがスキップした場合

出力でスキップを認識します（「単一モデルの結果のみで進める」）し、RECONCILE に進みます。スキップは問題ありません。沈黙のスキップは問題です。

非インタラクティブなコンテキスト（CI、/loop、自律ループ、スケジュールされた実行）：

• クロスモデルはスキップされ、スキップは出力でお知らせされる必要があります：「クロスモデルスキップ：非インタラクティブなコンテキスト。」
• 明確なユーザー認可なしに外部 CLI を呼び出さない — これは重要な安全プロパティです。

クロスモデルはコスト、レイテンシ、およびツールの脆弱性を追加します。エージェントはすべてのサイクルで選択肢を表面化します。ユーザーは、この成果物がそれを保証するかどうかを決定します。

ステップ4: RECONCILE — 結果を統合する

レビュアーの出力はデータであり、判定ではありません。あなたはまだオーケストレーターです。 分類する前に、各指摘に対してアーティファクトテキストを読み直します。レビュアーをゴム判を押すことは、それを無視することと同じ失敗モードです。

各指摘について、この優先度順で分類します（最初に一致するクラスが勝ち）：

1. 契約の誤読 — レビュアーは、あなたが提供した CONTRACT が不明確または不完全だったため、特に何かをフラグを立てました。最初に契約を修正してから、次のサイクルで再分類します。
2. 有効で実行可能 — 成果物を変更する必要がある実際の問題。それを変更し、再ループします。
3. 有効なトレードオフ — 問題は実際ですが、修正のコストが受け入れのコストを超えています。トレードオフを明示的に文書化して、ユーザーが見えるようにします。
4. ノイズ — レビュアーが、実際にはレビュアーが持たないコンテキストの下で正しいものをフラグを立てました。それを記録し、続けてください。その質問をしてください。その文脈を契約に追加することで、誤検出が防止されていたでしょうか？

新しいレビュアーはコンテキストの欠如のため間違っている可能性があります。ただ「新鮮」だからといって延期しないでください。

ステップ5: STOP — 有界なループ、再帰ではない

停止する場合：

• 次のイテレーションは自明または既に考慮された指摘のみを返す、または
• 3サイクル完了（ユーザーにエスカレート、4番目で単独でグラインドしない）、または
• ユーザーが明確に「それを船出する」と言う

3サイクル後、レビュアーがまだ実質的な問題を表面化している場合、成果物は準備ができていないかもしれません。これをユーザーに表面化します。3つの未解決サイクルはループを続ける理由ではなく、成果物についての情報です。

3サイクルが「明らかに不十分」である場合、成果物が大きいため：成果物が大きすぎます。ステップ2に戻り、分解してください。バウンドを上げないでください。

よくある正当化

正当化	現実
「確信があるので、懐疑ステップをスキップします」	確信は新規の問題での正確性と相関が悪いです。確実さの瞬間は、盲点が隠れる場合です。
「レビュアーを生成することは費用がかかります」	本番環境で間違ったコミットをデバッグすることはさらに費用がかかります。チェックは有界です。バグではありません。
「レビュアーはただ細かく指摘するだけでしょう」	スコープが定められている場合のみ。プロンプトを「この契約下で失敗する問題」に制限します。
「最後に /review で懐疑を実行します」	/review は最終ゲートです。懐疑駆動は軌道修正が安上がりなうちに間違った方向を捕捉します。PR の時点では遅すぎます。
「すべてのステップを疑えば、何も船出しません」	スキルは非自明な決定に適用されます、すべてのキーストロークではなく。「使わないケース」を再度読んでください。
「2つの意見は常に1つより良いです」	2番目がより少ないコンテキストを持ち、ノイズを生成する場合は違います。延期ではなく、統合してください。
「レビュアーが反対したので、私は間違っていました」	レビュアーはあなたのコンテキストを欠いています — 反対は判定ではなく情報です。成果物を再度読み、分類し、次に決定してください。
「クロスモデルは常により良いです」	クロスモデルは単一モデルが自身で共有する盲点を捕捉しますが、コストとツールの脆弱性が追加されます。すべてのインタラクティブな懐疑サイクルで提供します。ユーザーが成果物がそれを保証するかどうかを決定します。エージェントの仕事は選択肢を表面化することです、それをゲートすることではありません。
「ユーザーが一度はいと言ったので、CLI を呼び出し続けることができます」	各呼び出しはそれ独自の認可です。成果物、プロンプト、フラグは呼び出し間で変わります。すべて実行する前にユーザーと正確なコマンドを再確認します。

赤旗

• 1行のリネームまたはフォーマット変更のために新鮮なコンテキストレビュアーを生成する
• レビュアー出力を成果物テキストを再読みすることなく権威として扱う
• ユーザーにエスカレートせずに3サイクルを超えてループする
• レビュアーに「これは良いですか？」ではなく「問題を見つけてください」をプロンプトする
• 高リスク決定で時間圧力下で懐疑をスキップする
• 変更されていない成果物で新鮮なコンテキストを再生成する（同じ結果が得られます。あなたは停止しています）
• 懐疑劇場（チェック可能な信号）：レビュアーが実質的な結果を表面化した2つ以上のサイクルでは、ゼロの結果が実行可能として分類されました。検証しており、疑っていません。停止してエスカレートします。
• コミット後にのみ懐疑する — これは懐疑駆動開発ではなく、/review です
• ユーザーがツールが存在し、設定され、その正確な構文を受け入れることを確認せずに外部 CLI 呼び出しをハードコーディングする
• インタラクティブな懐疑サイクルでクロスモデルを沈黙で省略します。 推奨しない場合でも、提供は見えるべきです。スキップは問題ありません。沈黙のスキップは問題です。
• 外部 CLI がエラーまたは不足している場合は沈黙でフォールバック — 失敗を表面化し、ユーザーにリダイレクトさせます
• 契約をレビュアーの入力から除去する
• CLAIM をレビュアーに渡す（合意に向けて偏る）

他のスキルとのインタラクション

• code-review-and-quality / /review：補完的。/review は事後的 PR 判定、懐疑駆動は行程中の決定別。両方を使用します。
• source-driven-development：SDD は公式ドキュメントに対してフレームワークについての事実を検証します。懐疑駆動は成果物についてのあなたの推論を検証します。SDD は API が存在することを確認します。懐疑駆動は契約下で正しく使用したことを確認します。
• test-driven-development：TDD の RED ステップは具体化された懐疑です — 失敗テストは反論試行です。TDD が適用される場合、その失敗テストは行動上の主張に対する懐疑ステップです。
• debugging-and-error-recovery：レビュアーが実際の障害モードを表面化すると、デバッグスキルにドロップして、ローカライズと修正を行います。
• リポジトリオーケストレーションルール（references/orchestration-patterns.md）：このスキルはメインセッションからオーケストレートします。ペルソナが別のペルソナを呼び出すことはアンチパターン B です — 上記のローディング制約を参照してください。

検証

懐疑駆動開発を適用した後：

• すべての非自明な決定（上記の定義ごと）が、確立前に CLAIM として明示的に命名された
• 非自明な成果物ごとに少なくとも1つの新鮮なコンテキストレビュー（TDD の RED ステップによって生成された失敗テストは、他のスキルとのインタラクションごと、行動上の主張についてこれを満たします）
• レビュアーは ARTIFACT + CONTRACT を受信しました。CLAIM ではなく、推論ではなく
• レビュアーのプロンプトは敵対的でした（「問題を見つけてください」）、検証ではなく（「良いですか」）
• 結果は成果物テキストに対して分類されました（優先度：契約の誤読/実行可能/トレードオフ/ノイズ）、ゴム判を押されませんでした
• 停止条件が満たされました（自明な結果、3サイクル、またはユーザーオーバーライド）
• インタラクティブモードでは、クロスモデルが明確にユーザーに提供された（成果物の利害かかわらず）、応答は出力で認識された
• 非インタラクティブモードでは、クロスモデルがスキップされ、スキップが告知された
• 外部 CLI の呼び出しには、PATH チェック、動作バイナリテスト、ユーザーとの構文確認、実行への明示的な認可が先行しました