revision-adversarial

敵対的設計レビュー

目的

既存の技術設計ドキュメント（TECH-DESIGN.md）とその ADR に異議を唱え、欠落や根拠の乏しい決定、考慮されていないリスクを積極的に探します。このスキルは、既定で設計を妥当と判断することはありません。まず異議を唱え、実際の問題を見つけられなかった場合にのみ、決定が妥当だと認めます。

重要な理由

設計を作成したのと同じ会話で「本当にこれでよいですか？」と尋ねても、批評ではなく弁護が返ってくる傾向があります。モデルには迎合性（RLHF のトレーニングでは同意が報酬されます）と自己選好バイアス（モデルは自身の以前の出力をより好意的に評価します）が見られるためです。可能な限り、設計作成時の履歴がない新しい会話でこのスキルを実行してください。TDD を生成したのと同じ会話で実行する場合は、その条件ではレビューの質が低下することを、開始前にユーザーへ明確に伝えてください。

必須入力

• TECH-DESIGN.md とその adrs/*.md ファイル（必須）。
• PRD.md と Design.md（存在する場合）。記載されたスコープや UI 要件と決定が矛盾していないかを照合するために使用します。レビューの実行に必須ではありませんが、確認を省略するとレビューの範囲が狭まることを伝えてください。

ワークフロー

1. TECH-DESIGN.md とすべての ADR を最後まで読みます。
2. 各 ADR が以下の基準を満たしているか確認します。いずれかが欠けている、または弱い場合は不合格です。
   • コンテキストが決定を実際に正当化している（一般的な定型文ではない）。
   • 検討した代替案が実際に実行可能な選択肢であり、見せかけの二者択一ではない（同じものに別の名前を付けても該当しません）。
   • 結果に、メリットだけでなく、実際のコストやトレードオフが少なくとも 1 つ含まれている。
   • 決定がプロジェクトの実際の規模に見合っている（過剰設計と設計不足の両方を指摘する）。
3. ドキュメント全体を照合します。
   • 決定が PRD のスコープや明示された「対象外」の内容と矛盾していないか（PRD.md がある場合）。
   • Design.md にある、データを伴うすべての要素がデータモデルで扱われているか（Design.md がある場合）。
   • プロジェクトに明らかに必要でありながら、どの ADR でも扱われていない決定領域（コンポーネント、データモデル、API 契約、スタック、状態管理、レジリエンスなど）がないか。
4. 記載されていないものも積極的に探します。未対処の障害モード、PRD が示唆する非機能要件の欠落（パフォーマンス、並行性、オフライン利用など）、および ADR 自身が言及していない決定の二次的な影響を確認します。
5. 指摘事項のレポートを作成します。TECH-DESIGN.md や ADR を直接編集してはいけません。このスキルが報告し、変更内容は人間が決定します。

出力

重要度の高い順に並べた指摘事項のレポートを作成します。

• 重大 — 対処しないと、設計が失敗する可能性が高い、または明示された要件に矛盾します。
• 警告 — 実際の欠落、または根拠が弱い箇所です。実装前に修正する価値があります。
• 提案 — 小規模な改善案であり、実装を妨げるものではありません。

各指摘事項には、対象となる ADR またはセクション、具体的な問題、そして重要である理由を記載します。「見直しを検討してください」といった曖昧な指摘にしないでください。十分に検討しても特定の領域に実際の問題が見つからなかった場合は、網羅性を装うために些細な指摘をでっち上げず、そのことを明確に伝えてください。

品質ゲート

回答を返す前に、次の点を内部で確認します。

• すべての ADR に実際に異議を唱えている（読み飛ばしたり、無批判に妥当と判断したりしていない）。
• 少なくとも 1 つの指摘が、元の ADR が見落とした実際のトレードオフを挙げている。または、設計が精査に耐えたことを明示している。「問題なく見えます」といった具体性のない評価だけで済ませない。
• レポートを水増しするために指摘をでっち上げていない。