コードベース監査（Codebase Audit）
監査の価値は優先順位付けとエビデンスにあり、長さではありません。ファイルパス、クエリ結果、PR番号、または行数がない発見事項は仮説であり、そのようにラベル付けしてください。
監査をドキュメントではなくコードとプロダクションに基づかせる
プロジェクトノート、計画、ステータスドキュメントはチェックポイントであり、権威ではありません。それらを出発点として何が主張されているかを学び、その後、実際のコミット、データベースの状態、PRチェック、ブランチヘッドに対して検証します。
ドキュメントとコードが矛盾する場合、その矛盾自体が発見事項であり、多くの場合監査の中で最も価値のあるものです。
プロダクションに関する主張には、プロダクションに対するクエリが必要です。メカニクスについては検証ゲートスキルと組み合わせてください。
構造
# <スコープ> 監査 (YYYY-MM-DD)
## TL;DR
<重要な3つのことと、最初に何をするか>
## パート1 — 見えていないもの（盲点、優先順位付け済み）
## パート2 — 欠落している機能（優先順位付け済み、それぞれに大まかな工数見積もり）
## パート3 — 改善が必要な既存機能（優先順位付け済み）
## パート4 — アーキテクチャの変更（優先順位付け済み、平易な日本語で）
## パート5 — 次の30日間を私が運営するなら
## 検証リスト（監査中に見つかった矛盾）
すべてに優先順位を付けましょう。 40件の発見事項が優先順位付けされていないリストは、行動が起こされない40件のリストです。
見積もり前に休眠スキャフォールドを確認する
各ギャップに大まかな工数見積もりを添付し、なぜそれが安価か高価かを説明してください。
通常、最も価値のある監査の発見事項はこれです：価値の高い「ギャップ」のほとんどは、数週間ではなく数日の作業であり、それはスキャフォールドがリポジトリ内に呼び出し元なしで既に存在するからです。 すでに80%構築されている機能は、そうでない機能とはまったく異なる判断を下します。
存在しないと宣言する前に、該当するものをgrepで検索してください。呼び出し元がゼロの関数が典型的なケースです — コードは存在するがそれを呼び出すものはなく、すべてのステータスドキュメントはその機能が存在しないと説明しています。
検証リスト
すべての監査は、解決できなかった矛盾で終了します。各エントリには次の内容を記載します：
- 何が主張されていたか
- 何が観測されたか
- それを解決するためのクエリまたはチェックは何か
これは次のセッションが実際に使用するセクションです。 短くても必ず記述してください。
明示的に価値がないと判断したセクション
調査したが意図的に却下したものを、その理由とともに明記してください。
バックログに追加するだけの監査は、バックログを役に立たなくします。調査して却下した発見事項は、言及すらしなかったものよりも価値があります。なぜなら、次の監査で再び持ち上げられるのを防ぐからです。
保留中の項目はギャップではない
すでに意図的に先送りされたもの、または明示的な人間の判断のために保留されたものは、意図的に保留されています。それをギャップとしてリストしないでください。
意図的な保留を発見事項として再浮上させることは、保留された判断が誤って実行される方法です。
出力
監査はプロジェクトが保管する場所に書き出してください。以前の監査を置き換える場合は、どれが置き換えられ、何が変わったかを明記してください — 監査のフォルダは、積み重なるのではなく、シーケンスとして読みやすい状態を保つべきです。