Review a GitHub pull request from multiple perspectives in parallel, output only findings, then let the user pick which to fix in the same session. Use when the user asks to review a PR by number, mentions "PRレビュー" / "PR review" with a number, or invokes `/pr-review <number>`. Fans out subagents for absolute-rules, stop-slop, security, architecture, code-quality, testing, and ai-antipattern.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
引数として渡されたPR番号のコードレビューを、複数観点のサブエージェントに並列実行させ、結果を統合して指摘だけを出力する。出力後、どの指摘に対応するかをユーザーにチェックボックスで選ばせ、選ばれたものを同じセッションで修正する。
$1: PR番号
以下を並列で取得する。
gh pr view <PR番号> --json number,title,body,headRefName,baseRefName,author,files,additions,deletions
gh pr diff <PR番号>
diffは大きくても全部をレビュー対象にする。
Agentツールを同一メッセージ内で7個並列に呼び出す。各サブエージェントに以下を渡す。
サブエージェントの subagent_type は general-purpose を使う。
すべて ~/.claude/skills/pr-review/policies/ 配下のファイルをReadで開かせる。
| 観点 | ポリシーファイル |
|---|---|
| absolute-rules | absolute-rules.md |
| stop-slop | stop-slop.md |
| security | security.md |
| architecture | architecture.md |
| code-quality | code-quality.md |
| testing | testing.md |
| ai-antipattern | ai-antipattern.md |
あなたはPRレビュアーである。担当観点は「<観点名>」。
# 参照すべきポリシー
以下をReadで読んでから判定する。読まずに判定しない。
<ポリシーファイルの絶対パス>
# レビュー対象
## PRタイトル
<title>
## PR本文
<body>
## 差分
<full diff>
# 出力ルール
- 良い点や要約は書かない。指摘のみ。
- 各指摘は以下の形式で列挙する。指摘がなければ空の配列 `[]` だけを返す。
```json
[
{
"severity": "REJECT" | "Warning",
"file": "<repo-relative path>",
"line": <行番号または範囲 "12-18">,
"category": "<ポリシー内の該当項目番号または節名>",
"problem": "<何が問題か1-2文>",
"fix": "<どう直すか1-2文>"
}
]
### 3. 結果の統合
7つのサブエージェントから返ったfindingsをマージする。
- 同一の file, line, problem をもつ重複
- 1件に統合する
- `perspectives` に元の観点名を列挙する
- 重複していない指摘
- どの観点から出たかをタグ付けする
- 並び順
- severity
- REJECT
- Warning
- ファイルパス昇順
- 行番号昇順
- 各指摘に `F1`, `F2` のような通し番号を付ける
- 以降の選択と修正フェーズでこの番号を使う
- 各指摘に対応要否の所見を付ける
- 「対応すべき」
- 「対応不要」
- 「判断保留」
- 理由と対応方針を1-2文で書く
- 必要なら該当ファイルをReadで開いて現状を確認してから判断する
- 自分で妥当性を検証した結果を書く
### 4. 出力フォーマット
Markdownで以下の形式で出力する。指摘が0件なら「指摘なし」とだけ書いて終了する。前置きは書かない。
```markdown
## REJECT
### F1. <file>:<line> [観点1, 観点2]
**問題**: <problem>
**修正**: <fix>
**カテゴリ**: <category>
**所見**: <対応すべき/対応不要/判断保留: 理由と対応方針>
<以降同様>
## Warning
<以降同様>
REJECTが1件でもあれば末尾に 判定: REJECT を追記する。すべてWarningのみなら 判定: Warning、指摘なしなら 判定: APPROVE。
所見を付けたステップ4の出力を提示したあと、AskUserQuestion をmultiSelect: trueで呼び出し、対応する指摘をユーザーに選ばせる。
options は最大4件questions は最大4問
question の例
header は「対応対象」で統一するlabel: F<番号>: <file>:<line>description: [severity][所見: 対応すべき/不要/保留] <problemの要約>ユーザーが1件も選ばなければ「対応対象なし」と1行だけ返して終了する。
git worktree list で、対象PRのブランチをチェックアウトしてあるローカルworktreeを探す。同一ファイルへの変更は順番に、依存があれば依存順に処理する。
git -C <worktree絶対パス> を付けるgit status と git diff で意図した変更のみが含まれているか確認するgit add で対象ファイルを指定してstageするnix develop -c git commit でコミットする
F1 のようなfinding番号は書かないAskUserQuestion でユーザーに確認してから行う対応済みと未対応のfindingを番号順に列挙する。
## 対応済み
- F1: <one-line summary>
- F3: <one-line summary>
## 未対応
- F2: <理由 or 「ユーザー選択外」>
severity の判定はポリシーファイルの表に従わせるNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use by any agent before writing specs, editing code, or changing workflow files when the change could add compatibility behavior, aliases, silent fallbacks, or default-value fallbacks.
The English summary is being prepared. Showing the original description.
Cascade merge changes through a chain of dependent branches. Use when updating stacked/chained PRs, propagating changes from a parent branch to all downstream branches, or when the user mentions "cascade merge", "propagate changes", "update dependent branches", or "merge to downstream branches".
The English summary is being prepared. Showing the original description.
Interview the user in rounds until no branch of the design tree stays open.
The English summary is being prepared. Showing the original description.
外部のスキルをこのリポジトリにコピーして自分のスキルにする。ユーザーがスキルのURLやリポジトリ名を渡して「入れたい」「導入したい」と言ったとき、「上流を参照せずコピーしたい」と言ったとき、またはユーザーが `/import-skill` と打ったときに使う。Vendors an external Claude skill into this repository.
The English summary is being prepared. Showing the original description.
Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has been paged at 3am for a factory class that wrapped one function: question whether the task needs to exist at all, reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full, ultra. The default is full. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests such as general knowledge, prose, translation, summaries, recipes.
The English summary is being prepared. Showing the original description.
PRを作る、または既存PRのbodyを直す。ユーザーが「PRを作る」「PR出して」「PRのbodyを直して」と言ったとき、ユーザーが `/pr-create` と打ったとき、または `gh pr create` や `gh pr edit --body` がhookにブロックされたときに使う。Creates or edits a pull request with a three-line body.
The English summary is being prepared. Showing the original description.