pr-review-analysis

$npx mdskill add breaking-brake/cc-wf-studio/pr-review-analysis

Analyzes GitHub PR review comments and validates each finding against the codebase.

  • Fetches and organizes review comments from a given GitHub PR URL.
  • Uses GitHub CLI and API to retrieve comments and code context.
  • Verifies each comment by reading referenced code and checking for similar patterns.
  • Outputs a structured report with validity assessment and recommended actions.

SKILL.md

.github/skills/pr-review-analysisView on GitHub ↗
---
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` を使ってレビューコメントを取得する:
   ```bash
   gh api repos/{owner}/{repo}/pulls/{number}/reviews
   gh api repos/{owner}/{repo}/pulls/{number}/comments
   ```
3. コメントの一覧をパースし、指摘内容・対象ファイル・行番号を整理する

### 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` で各コメントに返信する:
   ```bash
   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(重大度)はレビューコメントのラベルまたは内容から推定する
- 日本語で出力する(コード・パス等の技術用語は原文のまま)

More from breaking-brake/cc-wf-studio

SkillDescription
cc-workflow-ai-editorAI workflow editor for CC Workflow Studio. Create and edit visual AI agent workflows through interactive conversation using MCP tools (get_workflow_schema, get_current_workflow, apply_workflow, update_nodes). Use when the user wants to create a new workflow, modify an existing workflow, or edit the workflow canvas in CC Workflow Studio via the built-in MCP server.
ccwf-cliUse the `ccwf` CLI (from @cc-wf-studio/cli) to render, validate, preview, export, or run cc-wf-studio workflow JSON files from the terminal. Apply whenever the user mentions viewing, visualizing, checking, executing, or converting a workflow under `.vscode/workflows/` (or any `*workflow*.json`), wants a Mermaid diagram of a workflow, asks to "see" / "preview" / "open" a workflow, or wants to run a workflow as a Claude Code Skill without opening VSCode.
jira-driven-planningJiraチケットの要件とConfluenceの関連ドキュメントを基に、Frontend/Backend/Infrastructureに分割した実装計画を策定するプランニングスキル。Jiraチケット情報とConfluence検索結果が前段で取得済みであることを前提とし、構造化された実装計画を出力する。「プランニング」「実装計画策定」「タスク分割」などの文脈で使用。
next-taskRun one unattended iteration of the autonomous value-creation loop — invent an improvement that users of cc-wf-studio would notice, judge it against an explicit value bar, implement it on a branch off auto-dev, open a PR that squash-merges on green CI, and log the outcome. Use when the user says "次のタスク", "next task", "何か進めて", "続きをやって", or wants autonomous progress without specifying what to do.
pr-to-mainCreate a PR to the main branch for feature/fix changes in this pnpm + Changesets monorepo. Use when the user says "PRを作成", "mainにPR", or wants to submit changes for review. Always run this in the monorepo-aware way — identify the affected package(s) and make sure a changeset exists, because the release pipeline is Changesets-driven.
pr-to-main-cleanupClean up merged feature branches after PR to main is merged. Use when the user says "ブランチ削除", "cleanup", "マージ後の片付け", or wants to delete a merged branch.
workflow-schema-tuningUse when modifying `resources/workflow-schema.json` in cc-wf-studio to influence how AI agents generate workflows via the cc-workflow-ai-editor skill. Triggers include "AIが特定のノードタイプを選んでくれない", "ワークフロー生成のバイアスを調整したい", "スキーマの description を変えたい", "新しいノードタイプを追加したい", "嘘の制約がスキーマに混じっていないか確認したい". Covers what the schema actually does (instructions to AI, not runtime constraints), the design philosophy (align direction, do not prescribe rules), the build pipeline (.json → .toon auto-generated), and known bias sources to audit.