コードレビュー規律
AI コードレビュアーの失敗は「十分に細かく見なかった」ことではなく、越権にあります。エージェントが「レビューだけ依頼された」コードをついでに直し、古いバグをあなたの新しい変更のせいだとしかめ立て、実在しない危険を作り出して深刻さを演出したり、モジュール境界をまたぐ問題を黙って直、こちらは本来人が決めるべきなのに — Myrm の code-review スキルは、レビュアーが自制のあるシニアエンジニアのように振る舞うことを保証します。- レビューだけ。修正はしない。 修正の適用は別ステップで、あなたまたは専用の修正パイプラインが行います。
- すべての問題に帰属がある。 各 finding は
Introduced-in-change（今回の変更で混入）/Pre-existing（以前からの問題）/Unknown（判定不能）のいずれかを明示し、git diff/git blameを根拠にします。推測はしません。 - 推測による危険は拒否する。 finding は実際の diff に根拠_bb がなければ成立しません。非現実的なエッジケースや仮定上の失敗は足し算ではなく除外されます。
- スコープ外のブロック項目はユーザーにエスカレーション。 本当にモジュール境界や所有権の境界をまたぐリスクは、Needs user decision（ユーザーの判断が必要）として報告され、今回の変更に黙って取り込まれません。
4 層の規律
マルチエージェントパイプラインの閉ループ
レビューを code-review-pipeline（アナリスト → セキュリティレビュアー → ロジックレビュアー → バリデータ）として走らせると、閉ループは最後の 1 マイルで明示的に落地します。- バリデータ役は修正の確定と回帰テストの実行を行いますが、
Needs user decisionとされた項目は自動修復しません — これらはユーザーに差し戻します。 - パイプラインの成功条件には out-of-scope blockers escalated to user decision（スコープ外のブロック項目はユーザーの判断へエスカレーションすること）が含まれ、真のリスクがエージェントの修復リストに消えることを防ぎます。
要件トレーサビリティ
問題を洗い出すだけでなく、スキルはタスク / PR 記述の各要件を検証結果へ対応付けます。
明確な要件がない場合は、推測した目的を明示し、コードがそれを達成しているかを確かめます — だからレビューの答えは「コードは綺麗か」ではなく「今回の変更は約束を果たしたか」になります。
使い方
設定不要。 このスキルはプリセットスキルとして 設定 → スキル に現れます。- 変更を直接レビューする:
code-reviewスキルを有効にして、PR・ファイル・モジュールをレビューさせます。 - レビュー pipeline 全体を実行する:
code-review-pipelineスキル（カンバン → パイプライン → コードレビュー）を使い、セキュリティ + ロジックのレビューを並行展開したのち、修正検証と回帰テストまで行います。
検証と契約テスト
スキルの契約は契約テストが守ります（各規律条項の存在と frontmatter バージョン規則をアサート）、統合テストがパイプライン全体（インスタンス化 → タスク DAG → バリデータのタスク記述）をモックなしでカバーし、重要な経路は切り分けて検証します。レビュー pipeline の解析とNeeds user decision の閉ループはいずれもエンドツエンドでカバーされています。
関連
- 証拠規律（英語） — すべての回答の表現層の誠実さ
- 階層検証_プレイブック（英語） — レビュー規律のさらに上にあるアーキテクチャレベルの検証
- スキル発見とレジストリ（英語） — プリセットスキルのインストールと管理