概念レビュー
誰かがその上に構築を開始する前に、推論または実装仕様が妥当かどうかを判断します。ユーザーが別途編集を依頼しない限り、読み取り専用のままにします。
証拠から始める
- 最初に安価な証拠を取得する: リポジトリの状態、テスト、コンパイラまたは型チェッカーの出力、ドキュメント、ログ、ベンチマーク、設定、実行時動作。推論は証拠が尽きたところから始まる。決して確認する代わりに推論してはならない。
- 要求されたリビジョン、ブランチ、スコープ、読み取り制限を尊重する。仕様がコミットにバインドされている場合は、ワーキングツリーではなくそのコミットを読み取る。
- すべての引用、数値、リポジトリに関する主張、引用された先例は検証すべきものとして扱う。
- 各重要な前提を「観察された」「推論された」「仮定された」「未知の」としてラベル付けする。利用できないソースはカバレッジギャップであり、確認ではない。
モードを選択する
- 推論モード: 決定、主張、結論用。
- 仕様モード: 実装者が従う実装契約、計画、または概要用。
仕様が争点のある主張に依存している場合は両方を使用する。
推論モード
- 決定または主張を述べる。
- それが依存する前提を上記のようにラベル付けしてリストアップする。
- 証拠が、飛躍したステップ、循環的なサポート、または前提が許容する以上の確実性なしに結論を裏付けていることを確認する。
- すべてを同時に真にできない前提を探す。
- 最も弱い重要なリンクを挙げる。
- 最も強力で信頼できる反論または競合する説明を行う。藁人形論法は禁止。
- 別の決定が重要な不確実性をより適切に処理できるかどうかを問う（必要に応じて可逆性も含む）。
- 最小限の修正を推奨する: 維持、修正、1つの名前付き未知の調査、または切り替え。
仕様モード
実装またはその承認を誤らせる可能性があるものをチェックする:
- 結果: 動作、除外事項、前提条件が互いに一致している。
- ソース: 引用、範囲、プロトコルルール、数式、外部の事実が一次ソースと一致している。
- 算術: カウント、境界、行列、合計が正確に再計算される。
- カバレッジ: 影響を受けるすべての呼び出し元、テスト、インターフェース、不変条件、互換性の約束、ドキュメント文が考慮されている。仕様が挙げるパスを超えて境界のある検索を実行するが、無関係なアーキテクチャレビューには流れ込まない。
- 受入能力: 必要な各テストが、対象とする欠陥に対して失敗できる。制御は意味があり、否定的なケースには観察可能な失敗がある。
- 実行の明確さ: ファイルスコープ、順序、エッジケースと失敗動作、完了の証明により、重要な点が推測に委ねられていない。
- スコープ: 先例と将来の作業が、現在の証拠が必要とする以上のことを静かに正当化していない。
発見事項はリポジトリの重大度用語で評価する。または:
- BLOCKING: 誤った実装、誤った合格、または回避不可能な推測を生み出す可能性がある。
- AMEND: 具体的なギャップまたは曖昧さ; アプローチ自体は依然として有効。
- NIT: 実装を変更しない表現または証拠の修正。
出力
- 評決から始める。推論モード: 推論は妥当である、またはそれを破るもの。仕様モード: 準備完了 または 準備未完了、決定的な理由を添えて。
- 推論モードは、重要な前提、最も弱いリンク、最善の反論、推奨事項のみを提供する。
- 仕様モードは、優先順位順に番号付きの発見事項（タイトル、重大度、正確な証拠、なぜ重要か、具体的な修正）と、検証に合格した重要な主張の短い検証済みリストを提供する。
- 信頼度（高、中、低）、評決を変える可能性が最も高い証拠、およびカバレッジギャップや未検証のソースで終了する。
ルール
- 決定を変える可能性のあるポイントのみを提起する。クリーンな評決は有効であり、決して発見事項を作り出してはならない。
- 証拠がサポートできない確率やスコアを捏造してはならない。
- 不足している決定や要件がレビューを妨げる場合にのみ、ユーザーに質問する。自分で入手可能な事実を取得すること。
- このレビューは、実装、編集、またはその他の結果を生み出すアクションを許可しない。
- インターフェースとシーム設計については、その方法をやり直す代わりに
$codebase-designを推奨する。
根拠: Anthropic and Redwood Researchの概念推論インデックス研究を開発者ワークフローとして適応。このスキルはCRIまたはそのベンチマークを実装するものではありません。