/pr-review-analysis
Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when
$ npx -y skills add breaking-brake/cc-wf-studio --skill pr-review-analysis --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/pr-review-analysis
Context preview
The summary Claude sees to decide when to auto-load this skill.
Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when
SKILL.md
pr-review-analysis.SKILL.mdname: pr-review-analysis
description: Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when given a PR review URL or when asked to check/analyze PR feedback.
PR Review Analysis
GitHub PR のレビューコメントを取得・分析し、各指摘の妥当性を検証してレポートを出力する。
Workflow
Step 1: レビューコメントの取得
1. ユーザーから PR の URL またはリポジトリ情報と PR 番号を受け取る 2. `gh api` を使ってレビューコメントを取得する:
gh api repos/{owner}/{repo}/pulls/{number}/reviews
gh api repos/{owner}/{repo}/pulls/{number}/comments3. コメントの一覧をパースし、指摘内容・対象ファイル・行番号を整理する
Step 2: 各指摘の検証
各レビューコメントについて:
1. **該当コードの確認**: 指摘が参照するファイルと行を Read ツールで読む 2. **指摘内容の分析**: レビューアの主張が技術的に正しいか検証する 3. **妥当性の判定**:
- ✅ **正当** (Valid): 指摘が正しく、修正が必要
- ❌ **不当** (Invalid): 指摘が誤っている、または該当しない
- ⚠️ **部分的に正当** (Partial): 指摘の一部は正しいが、完全には当てはまらない
Step 3: 影響範囲の確認
指摘が参照するパターン(バグ、アンチパターン等)が他のファイルにも存在するか Grep ツールで確認する。 同一パターンが複数箇所にある場合、それらも報告に含める。
Step 4: レポート出力
以下の形式でまとめを出力する:
## PR Review Analysis: #{PR番号}
### Summary
- Total comments: {件数}
- Valid: {件数} | Partial: {件数} | Invalid: {件数}
### Details
| # | File | Severity | Validity | Summary | Action |
|---|------|----------|----------|---------|--------|
| 1 | path/to/file.ts:L42 | Major | ✅ Valid | 説明 | 修正必要 |
| 2 | path/to/file.ts:L100 | Minor | ⚠️ Partial | 説明 | 検討 |
### Detailed Analysis
#### Comment 1: [タイトル]
- **File**: `path/to/file.ts:L42`
- **Reviewer's point**: 指摘内容の要約
- **Verification**: 検証結果の説明
- **Verdict**: ✅ Valid
- **Recommended action**: 具体的な修正方針
- **Same pattern found in**: (該当する場合) 他のファイルパス
...Step 5: レビューコメントへの返信
レポート出力後、修正対応が完了している場合はレビューコメントへの返信を提案する。
1. **ユーザー確認**: 「コメントに返信しますか?」と確認する。ユーザーが承認した場合のみ返信を実行する 2. **返信内容の生成**: 各コメントの Verdict に応じた返信を生成する:
- ✅ Valid: 修正コミットハッシュを含めて「Fixed in {hash}」形式で返信
- ⚠️ Partial: 対応した部分と対応しない理由を簡潔に説明
- ❌ Invalid: 該当しない理由を技術的に説明(例: 自動生成ファイルのため直接編集不可)
3. **返信の実行**: `gh api` で各コメントに返信する:
gh api repos/{owner}/{repo}/pulls/{number}/comments \
-f body='{返信内容}' \
-F in_reply_to={comment_id}4. **Outside-diff コメントの対応**: インラインコメントとして返信できない指摘(outside-diff)は、関連するインラインコメントのスレッドにまとめて返信する
Notes
- Bot によるレビュー(CodeRabbit, GitHub Actions 等)と人間のレビューの両方に対応する
- レビューコメントに対する返信スレッドも考慮する
- 指摘の severity(重大度)はレビューコメントのラベルまたは内容から推定する
- 日本語で出力する(コード・パス等の技術用語は原文のまま)
Read more
name: pr-review-analysis description: Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when given a PR review URL or when asked to check/analyze PR feedback.
PR Review Analysis
GitHub PR のレビューコメントを取得・分析し、各指摘の妥当性を検証してレポートを出力する。
Workflow
Step 1: レビューコメントの取得
1. ユーザーから PR の URL またはリポジトリ情報と PR 番号を受け取る 2. `gh api` を使ってレビューコメントを取得する:
gh api repos/{owner}/{repo}/pulls/{number}/reviews
gh api repos/{owner}/{repo}/pulls/{number}/comments3. コメントの一覧をパースし、指摘内容・対象ファイル・行番号を整理する
Step 2: 各指摘の検証
各レビューコメントについて:
1. **該当コードの確認**: 指摘が参照するファイルと行を Read ツールで読む 2. **指摘内容の分析**: レビューアの主張が技術的に正しいか検証する 3. **妥当性の判定**:
- ✅ **正当** (Valid): 指摘が正しく、修正が必要
- ❌ **不当** (Invalid): 指摘が誤っている、または該当しない
- ⚠️ **部分的に正当** (Partial): 指摘の一部は正しいが、完全には当てはまらない
Step 3: 影響範囲の確認
指摘が参照するパターン(バグ、アンチパターン等)が他のファイルにも存在するか Grep ツールで確認する。 同一パターンが複数箇所にある場合、それらも報告に含める。
Step 4: レポート出力
以下の形式でまとめを出力する:
## PR Review Analysis: #{PR番号}
### Summary
- Total comments: {件数}
- Valid: {件数} | Partial: {件数} | Invalid: {件数}
### Details
| # | File | Severity | Validity | Summary | Action |
|---|------|----------|----------|---------|--------|
| 1 | path/to/file.ts:L42 | Major | ✅ Valid | 説明 | 修正必要 |
| 2 | path/to/file.ts:L100 | Minor | ⚠️ Partial | 説明 | 検討 |
### Detailed Analysis
#### Comment 1: [タイトル]
- **File**: `path/to/file.ts:L42`
- **Reviewer's point**: 指摘内容の要約
- **Verification**: 検証結果の説明
- **Verdict**: ✅ Valid
- **Recommended action**: 具体的な修正方針
- **Same pattern found in**: (該当する場合) 他のファイルパス
...Step 5: レビューコメントへの返信
レポート出力後、修正対応が完了している場合はレビューコメントへの返信を提案する。
1. **ユーザー確認**: 「コメントに返信しますか?」と確認する。ユーザーが承認した場合のみ返信を実行する 2. **返信内容の生成**: 各コメントの Verdict に応じた返信を生成する:
- ✅ Valid: 修正コミットハッシュを含めて「Fixed in {hash}」形式で返信
- ⚠️ Partial: 対応した部分と対応しない理由を簡潔に説明
- ❌ Invalid: 該当しない理由を技術的に説明(例: 自動生成ファイルのため直接編集不可)
3. **返信の実行**: `gh api` で各コメントに返信する:
gh api repos/{owner}/{repo}/pulls/{number}/comments \
-f body='{返信内容}' \
-F in_reply_to={comment_id}4. **Outside-diff コメントの対応**: インラインコメントとして返信できない指摘(outside-diff)は、関連するインラインコメントのスレッドにまとめて返信する
Notes
- Bot によるレビュー(CodeRabbit, GitHub Actions 等)と人間のレビューの両方に対応する
- レビューコメントに対する返信スレッドも考慮する
- 指摘の severity(重大度)はレビューコメントのラベルまたは内容から推定する
- 日本語で出力する(コード・パス等の技術用語は原文のまま)
You think visually. AI thinks in .md. CC Workflow Studio speaks both. Design workflows on a canvas. Export as Markdown your AI agent already understands. No more prompt-guessing. Why CC Workflow Studio? - Speaker Deck Link
Repo: breaking-brake/cc-wf-studio
Other skills on cc-wf-studio.
- /jira-driven-planning
Jiraチケットの要件とConfluenceの関連ドキュメントを基に、Frontend/Backend/Infrastructureに分割した実装計画を策定するプランニングスキル。Jiraチケット情報とConfluence検索結果が前段で取得済みであることを前提とし、構造化された実装計画を出力する。「プランニング」「実装計画策定」「タスク分割」などの文脈で使用。
Open skill - /next-idea
Run one unattended IDEATION iteration of the autonomous value-creation loop — invent improvements a user of cc-wf-studio would notice, judge them against the value bar, and file the winners as locked `idea` issues. Never implements anything; the next-task skill builds from the
Open skill - /next-qa-idea
Run one unattended IDEATION iteration of the quality-assurance loop — find the highest-value untested behavior in the codebase, judge it against the QA value bar, and file ONE locked `qa` issue specifying the test to write. Never writes code or tests; the next-qa skill builds
Open skill - /next-qa
Run one unattended iteration of the QUALITY-ASSURANCE loop — steward any in-flight QA PR, then build ONE queued `qa` issue (test infrastructure, unit tests, regression tests for known bugs) on a branch off auto-qa and open a PR that squash-merges on green CI. Adds tests and
Open skill - /next-task
Run one unattended IMPLEMENTATION iteration of the autonomous value-creation loop — steward any in-flight PR, fix interrupts (red CI / security / human bugs), or else build ONE queued `idea` issue on a branch off auto-dev and open a PR that squash-merges on green CI. Ideation
Open skill - /pr-to-main-cleanup
Clean up merged feature branches after PR to main is merged. Use when the user says "ブランチ削除", "cleanup", "マージ後の片付け", or wants to delete a merged branch.
Open skill

