| name | code-review |
| description | コードレビューの実行手法と規律。スコープに応じて Quick / Standard / Deep モードを選択、team-bucciarati の Stand を観点別に dispatch。レビューする側 / 受ける側の両方をカバー。 |
| version | 2.0.0 |
| tags | ["code-review","refactor","methodology","discipline","team-bucciarati","hearing-first","chronista-style"] |
Code Review
レビューは技術的評価であり、感情的パフォーマンスではない。
スコープに応じて Quick / Standard / Deep。毎回フルレビューする必要はない。
受ける側は技術的正確さ > 社交的快適さ。
TL;DR (Decision Tree)
| 状況 | 飛び先 |
|---|
| 主体的にレビューしたい (PR / branch / refactor) | §A. レビュアー |
| レビューを受けた (user / 外部 reviewer から) | §B. 著者 |
| 定期的にレビューしたい (週次 / 月次) | §C. 定期実行 |
| 規律で迷った (反論すべき？ performative になってる？) | §D. 共通規律 |
詳細は reference/ 配下:
§A. レビュアー (主体)
A.1 Hearing でスコープ確定 (auto-suggest 付き)
実行前に git diff --stat HEAD ^main で変更規模を見て mode を自動推奨。ユーザは OK / 変更要求するだけ。
| 変更規模 / 性質 | 推奨 mode | ヒアリング深さ |
|---|
| < 200 行 / single concern | Quick | スキップ可 |
| 200-1000 行 / 複数モジュール | Standard | 1-2 問 |
| > 1000 行 / refactor / merge 前 / 定期 | Deep | 3-4 問 |
明示で override OK (ユーザが「Deep でやって」と言ったら従う)。
A.2 Mode 詳細
Quick mode (30 秒)
- Moody Blues 1 発 (CI + 4 視点 review)
- ヒアリングほぼなし
- 出力: コンソール / PR コメント
Standard mode (3-5 分)
- 2-3 Stand 並列 dispatch via Aerosmith
- 推奨: Moody Blues + Purple Haze + (Spice Girl)
- 結果集約 → severity matrix
Deep mode (10-30 分)
A.3 観点 ↔ Stand マッピング
代表観点 (Standard / Deep で使用):
| Pass | 観点 | 推奨 Stand |
|---|
| 1 | 全体アーキテクチャ | Aerosmith |
| 2 | モジュールごと品質 | Moody Blues |
| 3 | 実行時フロー / threading / IPC | Purple Haze |
| 4 | 横断関心事 (error / log / security) | Moody Blues |
| 5 | 具体バグ / subtle issue | Moody Blues |
| 6 | UX / accessibility | (手動) |
| 7 | ビルド / 配布 | Gold Experience |
| 8 | 長いモジュール / 分割整理 | Aerosmith |
詳細は reference/stand-mapping.md
A.4 Dispatch
並列 dispatch は 同一メッセージ内で複数 Agent ツール呼び出し で送る:
Aerosmith (orchestrator)
├→ Moody Blues
├→ Purple Haze
└→ Spice Girl
または直接 Agent ツール (subagent_type=moody-blues 等) で個別呼び出し。
A.5 Aggregate (severity matrix)
各 Stand の生 output を 構造化 してまとめる。生コピペは禁止 (signal/noise 比悪い)。
| # | severity | location | 観点 | 問題 |
|---|---|---|---|---|
| B1 | 🔴 Major | app.rs:325 | runtime | daemon 復帰検知なし |
| B2 | 🔴 Major | app.rs:758 | memory | HashMap leak |
| ...
severity:
- 🔴 Major — merge blocker、データ消失 / セキュリティ / 機能破壊
- 🟡 Minor — 動くが望ましくない、技術的負債
- 💡 Idea — 改善提案、現状で十分
信頼度 75 未満は載せない (Moody Blues 規約と揃える)。
A.6 Iterate (Deep mode のみ)
Aggregate 結果を見せた後:
「次の観点どうする？
├─ 特定 issue 深掘り (Purple Haze 再 dispatch)
├─ 別 angle (新 pass 提案)
└─ 終了」
新規の指摘が薄くなったら終了。
A.7 Output
| 出力先 | 用途 |
|---|
Canvas (vantage-point:show skill) | チーム共有、スクショ可 |
md ファイル (docs/review/<branch>-review.md) | repo に残す、commit |
PR コメント (gh pr comment <N>) | PR への直接フィードバック |
複数同時 OK。
A.8 Decision
レビュー後、次アクションを提案:
- merge 可 (blocker なし) → 「merge する？」
- 修正必要 → fix を Sticky Fingers / user に振る
- 規模次第で別 PR / 同 PR fixup
§B. 著者 (受信)
B.1 レスポンスパターン
フィードバック受信時:
1. 読む: 全体を反応せずに読む
2. 理解: 要件を自分の言葉で言い換える (or 質問)
3. 検証: コードベースの実態と照合
4. 評価: このコードベースで技術的に正しいか？
5. 対応: 技術的な応答または根拠ある反論
6. 実装: 1 項目ずつ、各項目テスト
B.2 禁止レスポンス
絶対にやるな:
- 「おっしゃる通り！」 (performative agreement)
- 「素晴らしい指摘！」 (感情的パフォーマンス)
- 「すぐ実装します」 (検証前の着手)
- 「ありがとうございます！」 (感謝の表明)
代わりに:
- 技術的要件を自分の言葉で言い換える
- 不明点を質問する
- 間違いなら技術的根拠で反論する
- 黙って直す (行動 > 言葉)
B.3 不明点を先に質問
不明な項目が 1 つでもあれば:
→ 何も実装するな
→ 不明点を先に質問
理由: 項目間に関連がある可能性。部分的理解 = 間違った実装。
例:
- レビュー: 「項目 1-6 を修正して」、1,2,3,6 は理解、4,5 が不明
- ❌ NG: 1,2,3,6 を先に実装、4,5 は後で聞く
- ✅ OK: 「1,2,3,6 は理解。4 と 5 について確認させてください」
B.4 ソース別の対応
ユーザーから:
- 理解したら実装 (信頼ベース)
- スコープ不明なら質問
- performative agreement 禁止は同じ
外部レビュアー / Stand から:
実装前に:
1. このコードベースで技術的に正しいか？
2. 既存機能を壊さないか？
3. 現在の実装に理由はあるか？
4. レビュアーは全体のコンテキストを理解しているか？
間違いだと思う → 技術的根拠で反論
ユーザーの過去の決定と矛盾 → 先にユーザーと議論
B.5 実装順序
複数項目のフィードバック:
1. 不明点を先にすべて質問
2. 実装順序:
- ブロッキング (破壊、セキュリティ)
- シンプル (タイポ、import)
- 複雑 (リファクタ、ロジック)
3. 各修正を個別にテスト
4. リグレッションがないことを確認
B.6 反論する時
反論すべきケース:
- 既存機能が壊れる
- レビュアーがコンテキストを欠いている
- YAGNI 違反 (未使用機能の追加)
- この技術スタックで技術的に間違い
- ユーザーのアーキテクチャ決定と矛盾
反論の仕方:
- 防御的にならず、技術的根拠を述べる
- 具体的な質問をする
- 動作するテスト / コードを参照する
B.7 正しいフィードバックへの応答
✅ OK: 「修正。[変更内容の簡潔な説明]」
✅ OK: 「[具体的な問題] を [場所] で修正」
✅ OK: 黙って直してコードで示す
❌ NG: 「おっしゃる通り！」「素晴らしい指摘！」「ありがとう！」
§C. 定期実行
毎日 Deep mode は重い。週次 / 月次で main / 主要 branch に対して定期 Deep review を /schedule で回す。
よくあるパターン
- 毎週月曜 09:00 — main 全体に Quick mode (drift 検出)
- 毎月 1 日 — main に Deep mode (構造的負債の棚卸し)
- リリース前 — release branch に Deep mode 1 回
セットアップ
/schedule skill 経由で remote agent を登録。詳細手順 + cron 例は reference/periodic-setup.md。
§D. 共通規律
D.1 技術評価 > 感情的パフォーマンス
レビューはコードの技術的正しさを評価する場。社交的快適さや感謝表明は副次的。
D.2 YAGNI チェック
「ちゃんと実装すべき」と言われたら:
→ コードベースで実際の使用箇所を grep
使われていない → 「この機能は呼ばれていません。削除 (YAGNI)？」
使われている → 適切に実装
D.3 Performative Agreement 禁止
「素晴らしい指摘！」「おっしゃる通り！」は 空のシグナル。技術的価値で sort せよ。
代わりに 「修正しました」「反論します、理由は X」「不明点があります」 で答える。
D.4 反論の仕方
防御的にならず、技術的根拠を述べる。具体的な質問をする。動作するテスト / コードを参照する。
D.5 信頼度スコアリング
issue を報告する時、信頼度を 0-100 で付ける。
| スコア | 意味 |
|---|
| 0-24 | 偽陽性 |
| 25-49 | 不確実 |
| 50-74 | 中程度 (ニットピック) |
| 75-89 | 高信頼 (二重確認済み) |
| 90-100 | 確実 (証拠で完全に裏付け) |
スコア 75 未満は報告しない。
§E. 既存スキルとの関係
codeflow — 開発全体フロー。本 skill は Implementation 完了直後の品質ゲートroute — issue → goal の path 探索。本 skill はレビュー時の path 探索版team-bucciarati:dispatch — 単発 pipeline (Ship / Full / Deploy)。本 skill は review 専用 Custom pipeline を構成team-bucciarati:improve — autonomous improvement loop。本 skill は review → improve に流す前段
アンチパターン
❌ 観点を切り替えず 1 pass で済ませる (Deep が必要な時に Quick で済ます)
❌ 複数質問を一度に投げる (一問一答違反)
❌ 生 output を貼り付ける (集約せず投げる)
❌ Performative aggregation (「素晴らしい指摘ばかりです！」と Stand を褒めるだけ)
❌ Severity 無し (Major / Minor / Idea を分けない)
TL;DR フロー
ヒアリング (auto-suggest mode)
↓
mode 確定 (Quick / Standard / Deep)
↓
dispatch (Stand 並列 or 単発)
↓
aggregate (severity matrix)
↓
iterate (Deep のみ)
↓
output (canvas / md / PR コメント)
↓
decision (merge / fix / split)
