audit-pr

PR を監査する

マネージャーの 「これをリリースしてよいか？」 の判定ゲートです。PR 全体を対象に、まず読み取りを行って監査します。対象には、SPEC、すべてのフェーズ、ドキュメント、CI の状態、レビュー受領記録が含まれ、結果として マージ可能 または優先順位付きの ブロッカー一覧 のいずれかを返します。編集、リファクタリング、マージは決して行いません。 人間がマージするか、実行中の advance --fullauto が SHA に紐付いた判定結果を受け取り、独立したフェイルクローズ方式のマージ手順を実行します。

audit-pr は差分を再レビューしません。現在の SHA に紐付いた review-change の受領記録（REVIEW-PASS コメントマーカー）をレビューの証拠として受け取り、受領記録がない場合や古くなっている場合は /review-change に差し戻してブロックします。また、以下のデリバリーゲートのみを独立して評価します。

ターンの契約 — ターンを終了する前に確認する

✓ The review receipt was consumed from one PR snapshot: `headRefOid` + newest
  matching `review-change:pass` marker fetched together; absent or any SHA
  mismatch → blocker routed to `/review-change`, current → its scope/axes/
  acceptance coverage/manual checks acknowledged without re-review
✓ Terminal hygiene was read from state, not assumed: tree clean, branch pushed,
  PR not a draft (`bun scripts/audit-pr-gate.mjs hygiene --pr <N> --apply`)
✓ Upstream lineage was re-verified (current plan receipt + parent spec receipt,
  digests recomputed), every obligation row is `verified`/`n/a`, and no planning
  finding is open — stale or missing lineage is a blocker, never a formality
✓ The verdict block was printed in the fixed format: `VERDICT: MERGE-READY | BLOCKED` with ranked, evidenced blockers
✓ The PR's FULL URL is printed in the verdict header (the user may be juggling
  several projects and agents without a CI monitor — the link in the chat is
  the contract, never "PR #N" alone)
✓ MERGE-READY verdict? Then the comment was POSTED by
  `bun scripts/audit-pr-gate.mjs comment` (re-reads, exits non-zero unless the newest marker
  names the head) — a comment, never a commit-message tag. BLOCKED → no comment
✓ Nothing was edited, refactored, or merged; merge authorization is outside
  this skill and cannot be inherited from docs or an earlier session
✓ No review pass was composed or reconstructed: a missing/stale receipt is a
  blocker, never a prompt to re-run review axes from this skill
✓ Closure integrity was evaluated and its result stated explicitly: pass /
  blocker / n-a (fix-governed PRs are always n-a; never skipped
  silently)
✓ Scope integrity (descope) was evaluated and its result stated explicitly:
  pass / blocker / n-a (no unit-referencing issues born on the branch → n-a;
  never skipped silently)
✓ Architectural-invariant preservation was evaluated and its result stated
  explicitly: pass / blocker / n-a (no project document → n-a; never skipped)
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

チェックされていない項目がある状態でターンを終了しようとしていますか？ そのターンはまだ完了していません。不足している項目を先に完了してください（性能の低いモデルは文書末尾のタスクを見落としやすいため、このリストを意図的に最初に置いています）。

使用するタイミング

• 作業が「完了」した後、マージする前 — review-change の問題が解消され（REVIEW-PASS の受領記録が投稿され）、すべてのフェーズがコミットされた後の最終ゲートとして。
• すべての未完了事項が解消されたと信じるだけでなく、「この PR は本当に準備できているか？」に対する、根拠のある回答を一つ得たいとき。

review-change は品質について差分をレビューし、SHA に紐付いた受領記録を投稿します。audit-pr はその受領記録を受け取り、デリバリー単位としての PR を監査します。つまり、SPEC で約束された内容がすべて揃い、追跡可能で、問題がないことを確認します。受領記録がない場合や古くなっている場合はブロッカーとして /review-change に差し戻し、ここで再議論することはありません。

対象範囲

プルリクエスト全体です。ブランチとデフォルトのベースの比較に加えて、SPEC と計画関連の成果物、ロードマップの項目、ドキュメントマップ、PR の本文、Issue へのリンク、CI も対象になります。デフォルトでは現在のブランチの PR が対象です。別の PR を対象にする場合は、PR 番号を指定してください。

ステップ 0 — プロジェクトと PR を特定する（必ず最初に実施）

1. プロジェクトの契約。 エージェントガイドの ワークフロー規約 と ドキュメントマップ に従い、このスキルに必要なものを読みます。ロードマップとプロジェクトの検証ゲート（型チェック／テスト／ビルド／CI）を確認してください。機能や修正のテンプレート全体は読み込まないでください。この監査で読む計画成果物は、以下の SPEC のみです（AC 14）。
2. PR。 PR を特定し、全文を読みます（プロジェクトのワークフロー規約に従って forge CLI を使用します。例では gh を使用します）。

   gh pr view <N> --json number,url,title,body,baseRefName,headRefName,headRefOid,isDraft,mergeable,mergeStateStatus,files,commits,statusCheckRollup,closingIssuesReferences
   

   PR 番号が指定されていない場合は、現在のブランチの PR を特定します（gh pr view --json ...）。まだ存在しない場合は、デフォルトのベースに対するブランチを監査し、「PR はまだオープンされていない」と伝えてください。それでも契約は適用されます。
3. SPEC。 適用される SPEC（機能の場合は docs/features/<NN>-<slug>/、修正の場合は docs/fix/<n>-<topic>/）と、存在する場合は計画関連の成果物（PLAN.md、TASKS.md、progress.md、testing.md、known-issues.md、decisions.md）を特定します。「完了」の定義に関する唯一の正となる情報源は SPEC です。

ステップ 1 — レビューレシートを取り込む（常に、ゲートより先に）

レビューの証拠は、PR に review-change が投稿する SHA に紐づいた REVIEW-PASS レシートです。ここでレビューをやり直すことは決してありません。headRefOid と PR のコメントをまとめて取得し、次のマーカーを含むコメントのうち、最新のものを見つけます。 ``：

gh pr view <N> --json headRefOid,comments

• current — マーカーの sha が、そのスナップショットの headRefOid（現在のヘッド SHA）と一致します。その範囲／軸、受け入れ条件のカバレッジ、不変条件の結果、手動チェックをレビューの証拠として確認してから、以下のデリバリーゲートを評価します。
• absent — PR に一致するマーカーがありません → ブロッカー：ヘッド時点のレビュー証拠がありません。/review-change に引き継ぎます。
• stale — マーカーはありますが、その sha が headRefOid と一致しません。無効にする前に、範囲を考慮した判定を適用します（fix/286、#182 AC 3/9）。範囲マニフェストを記録したレシート（マーカー内の scope=<64-hex>）は、ヘッド差分（レシートの sha → ヘッド、git diff --name-only）が影響しないパスのみを対象とする場合、current のままです。該当する閉じたクラス（セッションログ docs/LOGS.md、エージェントのツール状態／メモリ .engram/、.pi/、.serena/）は scripts/scope-manifest.mjs が管理します。名前付きクラスに一致しないパスはすべて影響ありとみなします。bun scripts/review-receipt.mjs verify --pr <N> を実行します。差分をローカルで計算し、current（終了コード 0）または stale（影響するパスを示して終了コード 4）を返します。scope 属性のない旧式のレシート、影響ありの差分、または解決できない差分がある場合、レシートは無効になります → ブロッカー：再レビューのため /review-change に引き継ぎます。PR ヘッドとの比較を覆すためにローカルの git diff を使ってはいけません。差分チェックは、範囲指定済みのレシートを current のまま維持することしかできず、範囲指定のないレシートを新たに current にすることはありません。

レシートの欠落／stale を解消するために、差分からレビューを作成、再構成、または「スポットチェック」してはいけません。それは review-change の担当であり、ここで軸を再検討することこそ、レシートゲートがなくすものです（AC 13）。

段階的な読み込み — 必須の監査ルート

参照先の許可リストは、以下にリンクされた 6 つのパスのみです。ほかの references/ パスを作ったり、読んだりしてはいけません。発見とステップ 1 のレシート確認の後、すべての監査で、次の 5 つの必須リソースを順番どおりに読み込み、適用します。

1. 01 マージゲート：デリバリー、CI、トレーサビリティ、レビューのレシート、マージ可能性に関する証拠を確認します。
2. 02 クローズと範囲のゲート：機能のクローズと範囲除外の来歴を確認します。
3. 03 監査プロセス：ブロッカーを収集、判定、記録し、SHA に紐づいた MERGE-READY コメントを投稿します。
4. 出力の前に04 判定を読み、その後05 ルーティングとガードレールを読みます。これらの必須リソースは、docs/workflow/REPOSITORY_STATE.md の証拠ルールとアーキテクチャ不変条件ゲートを管理します。

宣言されたフォージまたはエージェントに名前付きプリミティブが実際にない場合に限り、移植性を読みます。それ以外の場合は読み飛ばしてください。プロジェクトの成果物 docs/workflow/REPOSITORY_STATE.md は証拠であり、スキルの参照先ではありません。すべてのリソースはこのファイルから 1 ホップ以内にあります。証拠の欠落または必須リソースの欠落はブロッカーです。合格を推測してはいけません。

マージの権限

このスキルは、プロジェクトのドキュメントに merge: auto と記載されている場合、ユーザーが以前にマージを承認している場合、またはツールに以前の許可が保持されている場合も含め、マージを行いません。こうした情報によって、このスキルの「先に読み取る」という境界が変わることはありません。

唯一の自動マージ権限は、advance --continue --fullauto の実行中の呼び出しにおける AUDIT ステージにあります。MERGE-READY コメントは証拠であり、許可ではありません。リポジトリのラッパーは、そのコメント、Forge の現在のヘッドとデフォルトブランチをベースとするブランチ、グリーンチェック、およびそのヘッドで取得した merge: fullauto の判定を個別に検証します。ラッパーが最新の同期チェック、一時的な状態、マージの実行、クリーンアップ、自動マージ PR コメントを管理します。このスキルを単独または手動で呼び出した場合は、常に MERGE-READY の URL を人間に引き渡します。

移植性

ゲートの意味は変えず、Forge のコマンドを置き換えてください。移植性 に記載された明示的な代替手段を使用してください。

他のスキルとの関係

execute-phase (all phases done) ─▶ review-change (REVIEW-PASS receipt posted) ─▶ audit-pr ─▶ merge
                                                                                │
                     blockers ─┬─ receipt absent/stale ──▶ /review-change ──────┘ (re-review, re-audit)
                               ├─ in-scope            ──▶ execute-phase ────────┘ (fold, re-audit)
                               ├─ out-of-scope        ──▶ unit-lane --fix
                               └─ deferral            ──▶ triage-issue

• review-change の REVIEW-PASS レシート（対象範囲／評価軸、受け入れ条件の網羅状況、不変条件の結果、手動チェック）に加え、unit-lane ／ execute-phase の成果物（SPEC、フェーズ、ドキュメント、Closes #N）を受け取ります。
• audit-docs は文書間の整合性チェック、audit-pr は PR ごとのマージ準備状況の確認、product-audit は定期的な製品全体の包括的な監査を行います。

完了条件

• レビューレシートを確認済みであること。最新のマーカーを確認したか、見つからない、または古いマーカーを /review-change に回すブロッカーとして扱っていること（ここで再レビューしない）。
• 該当するすべてのゲートについて、根拠として引用した証拠を添えた合格／ブロッカー／該当なしの判定があること。
• PR の完全な URL をヘッダーに記載したうえで、単一の最上位判定（MERGE-READY または、優先順位を付けたブロッカーを示す BLOCKED）を報告し、各ブロッカーの対応先を示し、人間による手動検証の項目を明記していること。
• MERGE-READY の場合、マージの担当者を明確にすること。単独の監査では URL を人間に引き渡し、advance --fullauto の実行中の AUDIT ステージでは SHA に紐づく判定を受け取り、その後のすべてのマージチェックを担当すること。
• 最後に → Next: ブロックを出力すること（マージリンク → 次のユニットとして /unit-lane <unit> または /triage-issue、BLOCKED → 対応先に回した修正、その後に再監査）。
• 編集、リファクタリング、マージを行っていないこと。