Menu
PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
全 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".
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 版）
作成手順「agency-operations」（self-evolving-agent から自動同期）: 並列 agent を agency で安全に運用する手順(agency 運用知見)
| name | pr-review |
| description | PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。 |
「意図を掴む → コードを読む」順番を守り、指摘をGitHubのインラインコメントとして投稿する。
$ARGUMENTS からPR番号を読み取る（#42 または 42）。
番号がなければ現在のブランチのPRを探す:
gh pr view --json number,title,url 2>/dev/null
# PR基本情報とdiff
gh pr view <番号> --json title,body,url,headRefOid,headRefName,baseRefName
# diffの取得
gh pr diff <番号>
# 変更ファイル一覧
gh pr view <番号> --json files --jq '.files[].path'
PR description・リンクIssue・変更ファイルサマリーから 「このPRが達成しようとしていること」を1文で述べる。
1文で言えない場合 → コードを読む前にGitHubへコメントを投稿して終了：
gh pr review <番号> \
--comment \
--body "PR descriptionが不十分です。以下を追記してください：
- 何を・なぜ変えるか（課題と意図）
- やらなかったことと理由
コードを読む前に目的を把握するため、追記をお願いします。"
Layer 1: テスト
Layer 2: 公開API / インターフェース
Layer 3: 実装ロジック
Layer 4: プロジェクト固有ルール
各指摘をGitHubのインラインコメントとして投稿する。
gh api の -f/-F はオブジェクトの配列（comments[]）を正しく組み立てられないため、
JSONファイルを --input で渡す方式を使う（バッククォート・日本語のシェル展開も回避できる）。
gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
gh pr view <番号> --json headRefOid --jq '.headRefOid'
tmp/pr<番号>-review.json を作る（side: "RIGHT"、line は新ファイル側の行番号）:
{
"commit_id": "<headRefOid>",
"event": "COMMENT",
"body": "<レビュー全体のサマリー>",
"comments": [
{
"path": "<ファイルパス>",
"line": 35,
"side": "RIGHT",
"body": "<コメント本文>"
}
]
}
gh api --method POST /repos/<owner>/<repo>/pulls/<番号>/reviews --input tmp/pr<番号>-review.json --jq '{id: .id, state: .state, html_url: .html_url}'
各インラインコメントは以下の形式で書く：
<重大度> **What:** <何が問題か>
**Why:** <なぜ問題か — 根拠・原則・起きうるリスク>
**How:** <修正方向。コード例があれば>
重大度ラベル:
⛔ blocker — マージ前必須（クラッシュ・データ破壊・セキュリティ）🔴 major — 同PR内での修正を推奨🟡 minor — 次PR可💬 nit — スタイル・好み（任意）全インラインコメントを含むレビューを1リクエストで送信する（Step 4のAPIコールで body に記載）。
サマリー本文の形式：
## レビュー: <PRタイトル>
**意図:** <1文>
### 総合判断
<✅ Approve推奨 / 🔄 Request Changes推奨 / 💬 議論推奨>
<判断理由1行>
---
<⛔ N件 / 🔴 N件 / 🟡 N件 / 💬 N件>
各指摘の詳細は上記インラインコメントを参照してください。
総合判断の基準：
「このコメントを読んだ人が次に似たコードを書くとき良くなる」コメントを 必ず1件以上インラインに含める。設計原則・言語仕様・チームルールの説明を添える。