菜单
作成手順「code-review-execution」（self-evolving-agent から自動同期）: コードレビュー実行手順（EM 視点）
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
全 Claude セッションをスキャンし、ユーザーが何をしているかを分析して、 スキル・MCP プラグイン・エージェント・CLAUDE.md のどれに最適化すべきかを分類し、 具体的な改善提案（優先度・実装難易度・推奨アクション付き）を生成する。 Use when the user wants to analyze their Claude usage patterns, or when asked to "scrape sessions", "what do I do with Claude", or "what should be a skill vs agent vs claude.md".
PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。
Claude Code のトークン使用量・コストの確認と分析を行う。日次・月次レポートの表示から 高コスト要因・キャッシュ効率の分析、削減提案まで（表示だけの軽量モードあり）。 Use when you need to check today's or this month's token usage and cost, or to analyze Claude Code costs and get reduction suggestions. Triggers on: "今日のコスト", "今月のコスト", "トークン使用量", "ccusage", "コスト分析", "コスト削減".
/compact の前に、圧縮の要約から抜け落ちやすい「判断構造」と「セッション状態」を tmp/compact-state/latest.md に固定フォーマットで保存する。 Use when you are about to run /compact, when the user says "compact する前に", "compact-prep", "コンテキストを圧縮したい", or when context usage is high and compaction is imminent. Do NOT use for cross-session handover documents (use handover) — compact-prep is for surviving in-session compaction, not for ending a session.
現在のセッションの作業内容を次のセッションへ引き継ぐための引き継ぎドキュメントを生成する。 Use when the user asks to summarize the session for handover, says "引き継ぎ", "次のセッションに渡して", "context をまとめて", or when a session is ending and you think it would help to create a handover document for continuity. Also use when you are about to run out of context and want to preserve progress.
作成手順「1on1-prep」（self-evolving-agent から自動同期）: 1on1 準備手順（ EM 版）
基于 SOC 职业分类
| name | code-review-execution |
| description | 作成手順「code-review-execution」（self-evolving-agent から自動同期）: コードレビュー実行手順（EM 視点） |
用途: PR レビューを実際に実施するとき。
優先順位の決定は pr-triage、コメント 1 件の書き方は Lesson H を参照。
この手順はその「間」を埋める実行フロー（読む順番・EM 観点・判断基準・教える義務）を定義する。
| 既存資産 | カバーする関心 | この手順が追加するもの |
|---|---|---|
pr-triage | どの PR をいつ・誰がレビューするか（優先順位決定） | — |
| Lesson H | コメント 1 件の書き方（What + Why + How、重大度ラベル） | — |
android-self-review スキル | AI による規約・定型パターンの一次チェック | — |
| この手順 | — | PR を開いてから Approve/Request Changes するまでの実行フロー全体 |
コードを読む前に必ず行う。先にコードを読むと実装詳細に引き込まれ、設計レベルの問題を見落とす。
確認する順番:
「この PR が達成しようとしていること」を 1 文で言えなければ、コードを読み始めてはいけない。
PR 説明が不十分なら最初のコメントは「変更の目的と背景を教えてください」にする（実装を読む前に）。
EM がレビューで見る優先順位は個人実装者（IC）と異なる。
| 観点 | EM が問う内容 | IC との差 |
|---|---|---|
| チームパターンへの影響 | この変更は既存の設計パターンを壊すか・学習コストを上げるか | EM はチーム全体への波及を見る |
| アーキテクチャ守備 | レイヤー依存方向が守られているか（:ui → :domain → :data、逆依存禁止） | EM は構造。IC は実装 |
| 成長機会の有無 | このコードはチームメンバーの良いお手本になるか | EM はレビューを学習素材にする |
| 再発リスク | 同クラスのバグが他の PR・他のファイルにも潜んでいないか | 一件指摘より根本対処を考える |
EM が自分でレビューしない（委任する）判断基準（pr-triage と連動）: アーキテクチャ構造・チームパターンに影響しない実装詳細はシニアに委任し、Andy はスポットチェック（1〜2 点の確認）のみ。
読む順番を固定することで「見落とし」と「時間超過」の両方を防ぐ。
Layer 1: テスト（最初に読む理由: 仕様書として使えるから）
Layer 2: 公開 API / インターフェース
api 依存で公開している型・関数が適切か（implementation に閉じるべきものが漏れていないか）Layer 3: 実装ロジック
SimpleDateFormat 等の非スレッドセーフクラスの共有使用）try/catch の範囲・握りつぶし・ログ忘れ）Layer 4: Android 固有チェック（高頻出リスト）
| リスク | 確認ポイント |
|---|---|
| メインスレッドブロッキング | IO・ネットワーク操作が Dispatchers.IO か |
| Coroutine スコープ逸脱 | GlobalScope の不使用 / viewModelScope が適切か |
SimpleDateFormat 共有 | スレッドセーフな DateTimeFormatter か ThreadLocal に変更済みか |
Locale / TimeZone 暗黙依存 | フォーマット処理に Locale.JAPAN + ZoneId を明示しているか |
@Composable 副作用漏れ | 副作用が LaunchedEffect / SideEffect 内にあるか / remember の依存キーが正しいか |
| モジュール依存方向 | :ui → :domain → :data の一方向か（逆依存は ⛔ blocker） |
| 判断 | 条件 |
|---|---|
| Approve（承認） | ⛔ blocker がゼロ。🔴 major が 1 件以下かつ「次 PR での修正」を作者と合意済み |
| Request Changes | ⛔ blocker が 1 件以上。または 🔴 major が複数あり設計方向の修正が必要 |
| Comment only（保留） | 設計の大きな変更が必要で口頭議論の方が速い。コメントに「15 分 sync しましょう」と追記 |
「理想ではないが許容する」の明示的な扱い: 🟡 minor / 💬 nit は Approve しながらコメントを残し、「通す判断をした理由」を 1 行添える（例: 「🟡 minor: 動作影響なし。次スプリントのリファクタ候補として残します」）。黙って Approve しない。
IC がレビュー通過を目標とするのに対し、EM はコメントをチームの学習素材として残すことを目標とする。
教えるコメントの 3 条件:
Android EM レビューでよく現れる「教え場面」のトリガー:
| トリガー | 教えるべき原則 |
|---|---|
SimpleDateFormat の共有 | GapWorker による競合・DateTimeFormatter の immutable 性 |
api / implementation の使い分け | モジュール公開 API の基準（依存グラフへの影響） |
Dispatchers.Main でのブロッキング処理 | Coroutine Dispatcher の使い分け・キャンセル協調 |
@Composable 内の副作用直書き | LaunchedEffect / SideEffect の使い分け |
| モジュール依存方向違反 | レイヤードアーキテクチャの依存ルールと理由 |
最低 1 件は「このコメントを読んだ人が次に似たコードを書くとき良くなる」コメントを意図的に入れる。
| 状況 | アクション |
|---|---|
| Request Changes を送った | 作者が修正 push したら能動的に確認（通知待ちでなく追跡） |
| 口頭 sync を提案した | 当日中に 15 分スロットを確保。2 営業日返信がなければ Slack DM |
| 教えるコメントが横断的な問題を示している | Issue を起票し「他 PR にも同様パターンがあれば同時修正を推奨」と #team-android で共有 |
| 重大な設計問題を発見した | 1on1 アジェンダに追加（PR コメントで責める形にしない） |
取り込み経緯: 2026-06-27 の auto-kaizen セッションで「コードレビューは eval（eval-code-review.md）・Lesson H（コメント書式）・pr-triage（優先順位）が揃うのに実行フロー procedure だけがゼロ」と自己診断。About Andy に「コードレビューのボトルネック対策」が継続課題として記録されていることが観察可能な選定根拠。android-self-review スキル（AI 一次チェック）との役割分担を明確にする価値もある。