Review Pr Feedback

Review — PR Feedback Analyzer

Analyzes existing GitHub PR review comments from human reviewers or bots. Parses, explains, and prioritizes reviewer feedback so developers know exactly what to address and in what order. This skill does not review code itself — it interprets what others said.

Workflow

review-pr-feedback Progress:
- [ ] Step 1: Read Job Context (if CONTEXT_PATH provided)
- [ ] Step 2: Parse PR URL or identifier
- [ ] Step 3: Fetch review comments, general comments, and review verdicts via GitHub
- [ ] Step 4: Group comments by author
- [ ] Step 5: Classify comment types (blocker intent / suggestion / question / nitpick)
- [ ] Step 6: Explain each comment + suggest concrete fix with code example
- [ ] Step 7: Detect senior/boss reviewer comments — offer pattern extraction (with user consent)
- [ ] Step 8: Emit structured report with action items checklist

Input Contract

Step 1: Job Context

If context_doc is provided and the file exists, read it before fetching PR comments.

Context path convention: <JOBS_ROOT>/<JOB_NAME>/ai/context.md

Use the context to:

• Understand the codebase's conventions and chosen libraries
• Interpret reviewer comments more accurately (e.g., "use the store" means the MobX pattern)
• Identify whether a reviewer's concern is already addressed by project convention

If absent, proceed without context — it is optional and non-blocking.

Step 2: Parse PR URL

Extract owner, repo, and pullNumber from the provided identifier.

Accepted formats:

• https://github.com/owner/repo/pull/123 → owner=owner, repo=repo, pullNumber=123
• https://github.com/owner/repo/issues/123 → treat as PR if context confirms it
• owner/repo#123 → owner=owner, repo=repo, pullNumber=123
• #123 (when repository context is known from git remote) → resolve owner/repo from git remote get-url origin

If the URL cannot be parsed, respond with STATUS: BLOCKED and state the parsing failure.

Step 3: Fetch Comments via GitHub

Use GitHub MCP tools or gh CLI. Prefer MCP when available.

Line-specific review comments:

gh api repos/{owner}/{repo}/pulls/{pullNumber}/comments

General PR / issue-level comments:

gh api repos/{owner}/{repo}/issues/{pullNumber}/comments

Review verdicts (APPROVE / REQUEST_CHANGES / COMMENT):

gh api repos/{owner}/{repo}/pulls/{pullNumber}/reviews

Collect all three. If any fetch fails, note it in the output and continue with what was retrieved.

For each comment, extract:

• author.login
• body (comment text)
• path (file path, if line-specific)
• line or original_line (line number, if line-specific)
• created_at
• diff_hunk (surrounding code context, if available)

Step 4: Group by Author

Organize all comments under each author, distinguishing line-specific from general comments:

## Author: <login> (N line comments, M general comments) — Verdict: APPROVE | REQUEST_CHANGES | COMMENT

### Line-specific
- `path/to/file.ts:42` — "comment text"
- `path/to/file.ts:78` — "comment text"

### General
- "general comment text"

Step 5: Classify Comment Intent

For each comment, classify intent before explaining:

If a question contains an implied concern ("why did you use X here?" where X is suboptimal), treat it as concern.

Step 6: Explain and Suggest Fix

For each comment:

### [C-001] <Short title summarizing the comment>

- **Author**: <login>
- **Severity**: blocker | major | minor | info
- **File**: path/to/file.ts:line (or "General")
- **Reviewer said**: > verbatim quote of the comment
- **Explanation**: What the reviewer means, the underlying concern, the type of issue
  (e.g., architecture / type safety / naming / missing test / performance / style)
- **Suggested fix**:
  ```typescript
  // Corrected code example

• Confidence: High | Medium | Low
  • High: reviewer's intent is clear and the fix is straightforward
  • Medium: intent is clear but fix requires understanding more context
  • Low: comment is ambiguous; two or more reasonable interpretations

If confidence is Low, state both interpretations and ask the user which one applies.

---

## Step 7: Senior / Boss Reviewer Handling

**Detection**: if an author is identified as a senior or boss reviewer (by username, or by
review authority markers such as "REQUEST_CHANGES from `boss`"), trigger this flow:

1. Notify the user: "This PR has comments from a senior reviewer (`<login>`)."
2. **NEVER update rules, CLAUDE.md, or any configuration without explicit user consent.**
3. Ask: "Should I analyze `<login>`'s comments for patterns and suggest updates to review rules?"
4. If the user agrees:
   - Identify recurring patterns in that reviewer's feedback (not one-off edge cases)
   - Propose specific additions to `~/goodai-base/rules/core/code-review-boss-profile.mdc` or the relevant rule file
   - Present the proposed changes to the user for approval before writing anything
   - After approval, update the rule file and note it in the output
5. Extract generalizable patterns only — not personal phrasing or one-off opinions

---

## Step 8: Action Items

At the end of the report, produce a prioritized checklist:

```markdown
## Action Items

### Must address (blockers and concerns)
- [ ] [C-001] Fix DTO validation missing on `/users/update` endpoint — `src/users/users.controller.ts:42`
- [ ] [C-003] Add error handling to async `createOrder` method — `src/orders/orders.service.ts:87`

### Consider (suggestions)
- [ ] [C-005] Extract magic number `3600` to named constant — `src/auth/auth.service.ts:15`

### Optional / nitpicks
- [ ] [C-007] Rename `x` to `userId` for clarity — `src/users/users.service.ts:33`

### Clarifications needed (ambiguous comments)
- [ ] [C-009] Unclear: reviewer asked "why not use the cache here?" — two interpretations, see finding

Output Contract

STATUS: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
summary: "N comments from N reviewers. Verdict: APPROVE | REQUEST_CHANGES | COMMENT. N blockers, N concerns."
action_items:
  - "fix X in path/to/file.ts:42"
  - "address question in path/to/file.ts:78"
rule_suggestions:
  - "pattern: always validate DTOs at controller boundary"  # only when senior reviewer patterns found

Full markdown report structure:

# PR Feedback Analysis — <owner>/<repo>#<pullNumber>

## Overview
- **PR**: `<title>`
- **Reviewers**: <comma-separated list>
- **Verdict**: APPROVE | REQUEST_CHANGES | COMMENT
- **Total comments**: N (line-specific: N, general: N)

## Stats
- blocker: N
- major (concern): N
- minor (suggestion): N
- info (nitpick): N
- praise: N

## By Author

### <reviewer-login> (N comments — REQUEST_CHANGES)
<grouped findings for this author in C-NNN format>

### <reviewer-login-2> (N comments — COMMENT)
<grouped findings>

## Action Items

### Must address
- [ ] [C-NNN] ...

### Consider
- [ ] [C-NNN] ...

### Optional
- [ ] [C-NNN] ...

### Clarifications needed
- [ ] [C-NNN] ...

## Rule Suggestions (if senior reviewer patterns found)
<only present if user agreed to pattern extraction>
- Pattern: ...
- Proposed rule update: ...

Scope Boundaries

Job Context Awareness

When dispatched by job-orchestrator or called with an explicit context path, the prompt MAY include:

JOB_NAME:     <job-name>
CONTEXT_PATH: <JOBS_ROOT>/<job-name>/ai/context.md

Context path resolution order:

1. Value passed explicitly in the dispatch prompt
2. GOODAI_JOBS_ROOT environment variable + /<JOB_NAME>/ai/context.md
3. <PROJECT_DIR>/jobs/<JOB_NAME>/ai/context.md

If provided and the file exists, read it before fetching PR comments. If absent, proceed normally.

Red Flags

Orchestrated Review Contract

When dispatched by review-orchestrator, follow the provided reviewer-input.schema.json payload. Return a REVIEW_RESULT object compatible with skills/review-orchestrator/reviewer-finding.schema.json, then a concise markdown summary. Keep findings evidence-based, include concrete suggested_fix for every blocker/major, and return NEEDS_CONTEXT instead of guessing when required context is missing.