> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrmagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# コードレビュー規律

> Myrm の code-review スキルはレビュー前提下で越権しません — 問題を報告するだけで黙ってコードを変更せず、推測による危険を拒み、各問題を正しい変更に帰属させ、スコープ外のブロック項目は判断をユーザーに委ねます。

# コードレビュー規律

AI コードレビュアーの失敗は「十分に細かく見なかった」ことではなく、**越権**にあります。エージェントが「レビューだけ依頼された」コードをついでに直し、古いバグをあなたの新しい変更のせいだとしかめ立て、実在しない危険を作り出して深刻さを演出したり、モジュール境界をまたぐ問題を黙って直、こちらは本来人が決めるべきなのに — Myrm の **code-review** スキルは、レビュアーが自制のあるシニアエンジニアのように振る舞うことを保証します。

* **レビューだけ。修正はしない。** 修正の適用は別ステップで、あなたまたは専用の修正パイプラインが行います。
* **すべての問題に帰属がある。** 各 finding は `Introduced-in-change`（今回の変更で混入）/ `Pre-existing`（以前からの問題）/ `Unknown`（判定不能）のいずれかを明示し、`git diff` / `git blame` を根拠にします。推測はしません。
* **推測による危険は拒否する。** finding は実際の diff に根拠\_bb がなければ成立しません。非現実的なエッジケースや仮定上の失敗は足し算ではなく除外されます。
* **スコープ外のブロック項目はユーザーにエスカレーション。** 本当にモジュール境界や所有権の境界をまたぐリスクは、**Needs user decision**（ユーザーの判断が必要）として報告され、今回の変更に黙って取り込まれません。

## 4 層の規律

| 規律 | 何を防ぐか | どう実現するか |
| - | - | - |
| **報告のみ・変更しない** | レビュー中にコードを直してしまう | スキル本文に「報告のみを生む」契約を明記 |
| **帰属** | 古いバグがあなたの変更のせいにされる | `git diff` / `git blame` の証拠 + 保守的な `Unknown` をフォールバックに |
| **反推測** | 偽のバグを並べて報告を水増しする | finding は実 diff と周辺コードの引用が必須 |
| **止まって引き上げる** | レビュアーが跨モジュール問題を勝手に直す | **Needs user decision** を付与し、自動適用しない |

## マルチエージェントパイプラインの閉ループ

レビューを **code-review-pipeline**（アナリスト → セキュリティレビュアー → ロジックレビュアー → バリデータ）として走らせると、閉ループは最後の 1 マイルで明示的に落地します。

* **バリデータ**役は修正の確定と回帰テストの実行を行いますが、**`Needs user decision` とされた項目は自動修復しません** — これらはユーザーに差し戻します。
* パイプラインの成功条件には **out-of-scope blockers escalated to user decision**（スコープ外のブロック項目はユーザーの判断へエスカレーションすること）が含まれ、真のリスクがエージェントの修復リストに消えることを防ぎます。

これが重要なのは、Myrm のパイプラインがエンドツエンドの agent 自動化だからです。競合製品では humans が常に PR 画面に参加するため、「検証エージェントはいつ止まるべきか」を教える必要がありません。Myrm はその環節を補う必要があり、実際に補っています。

## 要件トレーサビリティ

問題を洗い出すだけでなく、スキルはタスク / PR 記述の各要件を検証結果へ対応付けます。

| 要件 | 状態 |
| - | - |
| 例「Google と GitHub で OAuth ログインを実装する」 | 満たす / 一部満たす / 満たさない |

明確な要件がない場合は、推測した目的を明示し、コードがそれを達成しているかを確かめます — だからレビューの答えは「コードは綺麗か」ではなく「**今回の変更は約束を果たしたか**」になります。

## 使い方

**設定不要。** このスキルはプリセットスキルとして **設定 → スキル** に現れます。

* **変更を直接レビューする**: `code-review` スキルを有効にして、PR・ファイル・モジュールをレビューさせます。
* **レビュー pipeline 全体を実行する**: `code-review-pipeline` スキル（カンバン → パイプライン → コードレビュー）を使い、セキュリティ + ロジックのレビューを並行展開したのち、修正検証と回帰テストまで行います。

## 検証と契約テスト

スキルの契約は契約テストが守ります（各規律条項の存在と frontmatter バージョン規則をアサート）、統合テストがパイプライン全体（インスタンス化 → タスク DAG → バリデータのタスク記述）をモックなしでカバーし、重要な経路は切り分けて検証します。レビュー pipeline の解析と `Needs user decision` の閉ループはいずれもエンドツエンドでカバーされています。

## 関連

* [証拠規律（英語）](/guides/evidence-discipline) — すべての回答の表現層の誠実さ
* [階層検証\_プレイブック（英語）](/guides/layered-verification-playbook) — レビュー規律のさらに上にあるアーキテクチャレベルの検証
* [スキル発見とレジストリ（英語）](/guides/skill-discovery) — プリセットスキルのインストールと管理


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.