القائمة
コードレビューの実行手法と規律。スコープに応じて Quick / Standard / Deep モードを選択、team-bucciarati の Stand を観点別に dispatch。レビューする側 / 受ける側の両方をカバー。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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"] |
レビューは技術的評価であり、感情的パフォーマンスではない。 スコープに応じて Quick / Standard / Deep。毎回フルレビューする必要はない。 受ける側は技術的正確さ > 社交的快適さ。
| 状況 | 飛び先 |
|---|---|
| 主体的にレビューしたい (PR / branch / refactor) | §A. レビュアー |
| レビューを受けた (user / 外部 reviewer から) | §B. 著者 |
| 定期的にレビューしたい (週次 / 月次) | §C. 定期実行 |
| 規律で迷った (反論すべき？ performative になってる？) | §D. 共通規律 |
詳細は reference/ 配下:
reference/modes.md — Quick / Standard / Deep の詳細フローreference/stand-mapping.md — 観点 ↔ Stand 対応表 (Pass 1〜8)reference/periodic-setup.md — /schedule 連携手順reference/examples.md — 実例実行前に 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 でやって」と言ったら従う)。
reference/modes.md代表観点 (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
並列 dispatch は 同一メッセージ内で複数 Agent ツール呼び出し で送る:
Aerosmith (orchestrator)
├→ Moody Blues
├→ Purple Haze
└→ Spice Girl
または直接 Agent ツール (subagent_type=moody-blues 等) で個別呼び出し。
各 Stand の生 output を 構造化 してまとめる。生コピペは禁止 (signal/noise 比悪い)。
| # | severity | location | 観点 | 問題 |
|---|---|---|---|---|
| B1 | 🔴 Major | app.rs:325 | runtime | daemon 復帰検知なし |
| B2 | 🔴 Major | app.rs:758 | memory | HashMap leak |
| ...
severity:
信頼度 75 未満は載せない (Moody Blues 規約と揃える)。
Aggregate 結果を見せた後:
「次の観点どうする？
├─ 特定 issue 深掘り (Purple Haze 再 dispatch)
├─ 別 angle (新 pass 提案)
└─ 終了」
新規の指摘が薄くなったら終了。
| 出力先 | 用途 |
|---|---|
Canvas (vantage-point:show skill) | チーム共有、スクショ可 |
md ファイル (docs/review/<branch>-review.md) | repo に残す、commit |
PR コメント (gh pr comment <N>) | PR への直接フィードバック |
複数同時 OK。
レビュー後、次アクションを提案:
フィードバック受信時:
1. 読む: 全体を反応せずに読む
2. 理解: 要件を自分の言葉で言い換える (or 質問)
3. 検証: コードベースの実態と照合
4. 評価: このコードベースで技術的に正しいか？
5. 対応: 技術的な応答または根拠ある反論
6. 実装: 1 項目ずつ、各項目テスト
絶対にやるな:
代わりに:
不明な項目が 1 つでもあれば:
→ 何も実装するな
→ 不明点を先に質問
理由: 項目間に関連がある可能性。部分的理解 = 間違った実装。
例:
ユーザーから:
外部レビュアー / Stand から:
実装前に:
1. このコードベースで技術的に正しいか？
2. 既存機能を壊さないか？
3. 現在の実装に理由はあるか？
4. レビュアーは全体のコンテキストを理解しているか？
間違いだと思う → 技術的根拠で反論
ユーザーの過去の決定と矛盾 → 先にユーザーと議論
複数項目のフィードバック:
1. 不明点を先にすべて質問
2. 実装順序:
- ブロッキング (破壊、セキュリティ)
- シンプル (タイポ、import)
- 複雑 (リファクタ、ロジック)
3. 各修正を個別にテスト
4. リグレッションがないことを確認
反論すべきケース:
反論の仕方:
✅ OK: 「修正。[変更内容の簡潔な説明]」
✅ OK: 「[具体的な問題] を [場所] で修正」
✅ OK: 黙って直してコードで示す
❌ NG: 「おっしゃる通り！」「素晴らしい指摘！」「ありがとう！」
毎日 Deep mode は重い。週次 / 月次で main / 主要 branch に対して定期 Deep review を /schedule で回す。
/schedule skill 経由で remote agent を登録。詳細手順 + cron 例は reference/periodic-setup.md。
レビューはコードの技術的正しさを評価する場。社交的快適さや感謝表明は副次的。
「ちゃんと実装すべき」と言われたら:
→ コードベースで実際の使用箇所を grep
使われていない → 「この機能は呼ばれていません。削除 (YAGNI)？」
使われている → 適切に実装
「素晴らしい指摘！」「おっしゃる通り！」は 空のシグナル。技術的価値で sort せよ。 代わりに 「修正しました」「反論します、理由は X」「不明点があります」 で答える。
防御的にならず、技術的根拠を述べる。具体的な質問をする。動作するテスト / コードを参照する。
issue を報告する時、信頼度を 0-100 で付ける。
| スコア | 意味 |
|---|---|
| 0-24 | 偽陽性 |
| 25-49 | 不確実 |
| 50-74 | 中程度 (ニットピック) |
| 75-89 | 高信頼 (二重確認済み) |
| 90-100 | 確実 (証拠で完全に裏付け) |
スコア 75 未満は報告しない。
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 を分けない)
ヒアリング (auto-suggest mode)
↓
mode 確定 (Quick / Standard / Deep)
↓
dispatch (Stand 並列 or 単発)
↓
aggregate (severity matrix)
↓
iterate (Deep のみ)
↓
output (canvas / md / PR コメント)
↓
decision (merge / fix / split)
作業の完了を宣言する前に使用。証拠なき完了宣言を防ぐ規律スキル。
AI agent の action space・tool 定義・observation format を設計し、completion rate を上げる。 agent harness を構築・最適化するときの語彙と判断軸を提供する。
AI agent 自身の failure (loop / drift / max tool call / 環境ズレ) に対する構造化 self-debug。 capture → diagnose → contained recovery → introspection report の 4 phase で、 retry blind を防ぎ human escalation の前に agent が自己修正する。
Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。
Mac M-series で Rust binary を zigbuild で linux/amd64 に cross-compile → slim Dockerfile に COPY → docker buildx --push する開発ループ標準化。 sccache + zig cache + cargo target/ + buildx registry cache の多層 cache を仕込み、 2 回目以降は秒単位の image 更新を実現する。 GH Actions (cargo-chef + GHA cache 10 GiB 制限) からの脱却 path として使う。
多義的な意思決定・トレードオフ・go/no-go 判断のために、4 voice の合議を召集する。複数の妥当な path が存在し、選択前に構造化された反対意見が必要なときに使う。