review-core

コアレビューワークフロー

使用するタイミング

• アーキテクチャ、数学、API などの詳細なレビューワークフローを開始するときに、このスキルを使用します。
• コンテキストの記録、エビデンスのログ作成、最終レポートの形式設定に一貫した構成を提供し、異なるレビューの調査結果を比較しやすくします。

使用しないタイミング

• 差分に焦点を当てた分析には、diff-analysis を使用します。

有効化パターン

トリガーキーワード：review、audit、analysis、assessment、evaluation、inspection コンテキスト上の手がかり：

• 「このコード／設計／アーキテクチャをレビューして」
• 「〜を監査して」
• 「問題がないか分析して」
• 「〜の品質を評価して」
• 「評価を実施して」

自動読み込みの条件：レビュー固有のワークフローが検出された場合、または分析手法が求められた場合。

必須の進捗項目

1. review-core:context-established
2. review-core:scope-inventoried
3. review-core:evidence-captured
4. review-core:deliverables-structured
5. review-core:findings-verified
6. review-core:contingencies-documented

ステップ 1 – コンテキストの確立（review-core:context-established）

• pwd、リポジトリ、ブランチ、上流のベースを確認します（例：git status -sb、git rev-parse --abbrev-ref HEAD）。
• 比較対象（マージベース、リリースタグなど）を記録し、後の差分が具体的な範囲を参照できるようにします。
• レビュー対象の機能／バグ／取り組みの概要と、関係者および期限を記載します。

ステップ 2 – スコープの一覧化（review-core:scope-inventoried）

• このレビューに関連する成果物を一覧にします。ソースファイル、設定、ドキュメント、仕様、生成アセット（OpenAPI、Makefiles、ADR、ノートブックなど）が含まれます。
• 一覧化に使用した方法を記録します（rg --files -g '*.mk'、ls docs、cargo metadata などのコマンド）。
• 計画や課題から引き継いだ前提条件や制約を記録し、ドメイン固有の分析で引用できるようにします。

ステップ 3 – エビデンスの記録（review-core:evidence-captured）

• レビューに役立つすべてのコマンドと出力を記録します（例：git diff --stat、make -pn、cargo doc、web.run の引用）。後で参照できるよう、抜粋や行番号を残します。
• 事前確認で見つかった未解決の質問や差異を追跡します。進行の妨げになる場合は、担当者と期限をすぐに記録します。

学んだ教訓の記録（意思決定ジャーナル）

この作業に手戻り、失敗したアプローチ、またはブロッカーが伴った場合は、知見をセッション後も残すために docs/lessons-learned.md に記録します（下書きを作成して確認します）。

• leyline がインストールされている場合は、Skill(leyline:decision-journal) を実行し、 教訓のエントリー（what_happened、what_didnt_work、root_cause、action）を追記します。 phase は review に設定します。下書きを提示し、確認後に追記します。
• フォールバック（leyline がない場合）：ファイル内の ENTRY TEMPLATE を使用して docs/lessons-learned.md に追記し、次の LL-NNN ID を割り当てます。

ステップ 4 – 成果物の構成（review-core:deliverables-structured）

• すべてのレビューで共通するレポートの骨組みを用意します。
  • 概要（ベースライン、スコープ、推奨事項）
  • 優先順位付きの調査結果（重大度、ファイル:行、違反した原則、修正方法）
  • フォローアップタスク（担当者＋期限）
  • エビデンスの付録（コマンド、URL、ノートブック）
• 結論を出す前に、ドメイン固有のチェックリストによって各セクションが埋まることを検証します。

ステップ 5 – 指摘事項の根拠を検証する（review-core:findings-verified）

すべての指摘事項は反証可能でなければなりません。つまり、2 回目の確認で機械的に読み直し、正しいことを確認できる引用が必要です。検証に通らない指摘事項は提出しません。

• Skill(imbue:structured-output) の根拠付き指摘事項スキーマを使用します。各指摘事項には、Location（file:line）と、その行からそのまま引用した Anchor のスニペットを含めます。

• 指摘事項を .review/findings.json に記録します（指摘事項ごとに 1 つのオブジェクトを作成し、id、file、line、anchor、severity、category、recommendation、evidence_refs を含めます）。

• 検証ツールを実行します。

  python plugins/imbue/scripts/citation_verifier.py \
    --findings .review/findings.json --repo-root .
  

  終了コード 0 はすべての引用が解決されたことを示します。終了コード 1 では、パス、行、またはアンカーがソースと一致しなかった各指摘事項が一覧表示されます。

• 検証に失敗した指摘事項は削除するか、UNVERIFIED とラベル付けします。検証済みの指摘事項のみをレポートに含めます。検証ツールの出力はエビデンス付録に添付します。

• スクリプトを利用できない場合は、引用された file:line をそれぞれ手動で読み直し、アンカーテキストが含まれていることを確認します。代替手段として手動確認を行ったことを、コンティンジェンシーセクションに記載します。

ステップ 6 – コンティンジェンシープラン（review-core:contingencies-documented）

• 必須のツールやスキル（例：web.run）を利用できない場合は、実施する代替手順と、それによって生じる制約を記録します。これにより、レビュー担当者が網羅性に関する不足を把握できます。
• レビューを完了するために必要な未取得の承認やデータがあれば記載します。

完了条件

• すべての進捗項目が、具体的なメモ（実行したコマンド、一覧表示したファイル、エビデンスのパス）とともに完了していること。
• レポートに含めるすべての指摘事項に Location と逐語的な Anchor があり、citation_verifier.py（または記録された手動での再確認）によって確認済みであること。未検証の指摘事項は提出しないこと。
• .review/findings.json が存在し、検証ツールの終了コードが 0 であること。または、検証に失敗したすべての指摘事項が削除されるか、UNVERIFIED とラベル付けされていること。
• ドメイン固有のレビューを開始する前に、コンテキスト、エビデンスログ、成果物テンプレートが用意されていること。
• エビデンス収集中に判明した手戻り、失敗したアプローチ、またはブロッカーがあれば、docs/lessons-learned.md（またはファイル内のテンプレート）に記録されていること。