quality-gate

品質ゲート

コードレビュアーエージェント（agents/code-reviewer.md）を呼び出し、欠陥が広がる前に洗い出します。

基本原則： 早めに、頻繁に確認します。

最優先指令

レビューなしでマージしない

例外はありません。回避策もありません。近道もありません。

開始プロトコル

レビューを開始する前に、次の点を確認します。

1. 現在のブランチでテストスイートがパスする
2. すべての変更がコミットされている（作業ツリーに未コミットの変更がない）
3. BASE_SHA と HEAD_SHA を特定している
4. 何を構築し、その理由を説明できる
5. どの計画または仕様を基準にレビューするか把握している
6. レビューの範囲を適切に定めている（単一タスクか、一括か）

条件を満たしていない項目があれば、レビューを依頼する前に解決してください。

開始するタイミング

必須：

• 委任実行ワークフローの各タスクの後
• 重要な機能の完成後
• trunk ブランチへのマージ前

任意ですが推奨：

• 行き詰まったとき（第三者の視点で解決の糸口が見つかることがよくあります）
• 大規模なリファクタリングの開始前（ベースラインを確立します）
• 難しい欠陥の解決後

開始方法

1. コミット範囲を取得します：

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. コードレビュアーのサブエージェントを起動します：

Agent ツールを使って、コードレビュアーエージェント（agents/code-reviewer.md）を呼び出します。code-reviewer.md のテンプレートに必要事項を記入します。

テンプレートのプレースホルダー：

• {WHAT_WAS_IMPLEMENTED} — 直近で構築したもの
• {PLAN_OR_REQUIREMENTS} — 満たすべき内容
• {BASE_SHA} — 開始コミット
• {HEAD_SHA} — 終了コミット
• {DESCRIPTION} — 簡単な説明

3. 指摘事項に対応します：

• Critical の指摘は直ちに解決します
• Important の指摘は次に進む前に解決します
• Minor の指摘は今後の対応として記録します
• レビュアーが誤っている場合は、根拠を示して異議を唱えます

手順

[Just completed Task 3: Add data validation layer]

You: Initiating quality gate before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 2" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Launch code-reviewer agent (agents/code-reviewer.md)]
  WHAT_WAS_IMPLEMENTED: Input validation and sanitization for all API endpoints
  PLAN_OR_REQUIREMENTS: Task 3 from docs/plans/api-hardening-plan.md
  BASE_SHA: c4e19a7
  HEAD_SHA: 8b2f305
  DESCRIPTION: Added validateRequest() and sanitizeInput() with 5 rule types

[Subagent returns]:
  Strengths: Comprehensive rule coverage, solid test assertions
  Issues:
    Important: Missing rate-limit header on validation error responses
    Minor: Hardcoded threshold (50) for payload size check
  Assessment: Ready to proceed after addressing Important item

You: [Fix rate-limit header]
[Continue to Task 4]

認知上の落とし穴

合理化	実際
「ほんの小さな変更だから、レビューは不要」	小さな差分が大規模な障害を引き起こすことがあります。すべてレビューします。
「徹底的にテストした」	テストとレビューでは、根本的に異なる種類の問題を検出します。
「レビューすると勢いがそがれる」	本番環境のインシデント対応は、はるかに勢いをそぎます。
「レビュアーはこのコードを理解できない」	レビュアーが理解できないなら、次のエンジニアも理解できません。
「次の PR でまとめてレビューする」	品質上の負債は複利で膨らみます。今レビューするか、後で複利の利息を支払うかです。

統合

godmode:delegated-execution:

• 委任したタスクごとにレビューします
• 欠陥が連鎖する前に洗い出します
• 次のタスクを開始する前に解決します

godmode:task-runner:

• タスクの各バッチの後にレビューします
• フィードバックを集めて修正を適用し、続行します

アドホック開発：

• マージ前にレビューします
• 行き詰まったときにレビューします

ガードレール

禁止事項：

• 「簡単だから」という理由でレビューを省略する
• Critical の指摘を無視する
• Important の指摘を未解決のまま次に進む
• 根拠を示さずに妥当な技術的フィードバックを退ける
• Critical または Important の項目が未解決のまま変更をマージする

必須事項：

• delegated-execution の各タスク後にレビューする
• すべてのレビュー依頼に BASE_SHA と HEAD_SHA を含める
• Critical の指摘に直ちに対応する
• フィードバックに異議を唱える場合は、コードまたはテストの根拠を示す
• フィードバックが曖昧な場合は、説明を求める

プロセス図

START: Work finished
  |
  +-- Suite green? --NO--> Fix tests first
  |        |
  |       YES
  |        |
  +-- Changes committed? --NO--> Commit changes
  |        |
  |       YES
  |        |
  +-- Determine BASE_SHA and HEAD_SHA
  |        |
  +-- Launch code-reviewer agent (agents/code-reviewer.md)
  |        |
  +-- Wait for results
  |        |
  +-- Critical items? --YES--> Fix now, re-review
  |        |
  |       NO
  |        |
  +-- Important items? --YES--> Fix before advancing
  |        |
  |       NO
  |        |
  +-- Log Minor items for later
  |        |
  +-- ADVANCE to next task

レビュアーのテンプレートはこちらです：quality-gate/code-reviewer.md