prcomments

PR Comments

Investigate pull request review comments and produce a session report. Do not fix anything until the user explicitly chooses which comments to address.

Requirements

• An active samocode session must be known, including SESSION_PATH.
• A PR number, PR URL, or explicit review comments must be provided.
• If only a PR number is provided, detect owner/repo from git remote get-url origin; if that is unclear, ask the user.

Fetch Comments

If the user provides a PR URL, parse owner, repo, and PR number from it.

If the user provides only a PR number, fetch inline review comments with:

gh api 'repos/[OWNER]/[REPO]/pulls/[PR_NUMBER]/comments'

If the request concerns top-level PR conversation comments too, also fetch:

gh api 'repos/[OWNER]/[REPO]/issues/[PR_NUMBER]/comments'

If GitHub CLI is unavailable or unauthenticated, report the blocker and ask the user to paste the comments.

Workflow

1. Capture timestamps:

   • date '+%m-%d-%H:%M' for the report filename.
   • date '+%H:%M' for the session flow log.

2. Parse each comment:

   • reviewer name,
   • file path and line if present,
   • quoted comment or concise summary,
   • whether it is inline or top-level.

3. Investigate each issue:

   • Read the relevant code and nearby context.
   • Understand the reviewer's concern.
   • Determine whether the issue is valid, invalid, or partially valid.
   • If valid or partial, identify the smallest coherent fix.
   • Classify action using the triage principles below; do not label a valid architectural/code-quality issue as "defer" just because current behavior works.

4. Create [SESSION_PATH]/[MM-DD-HH:mm]-prcomments.md:

   # PR Comments Analysis
   
   Date: [timestamp]
   
   ## Comment 1: [brief title]
   
   **Reviewer says:** [quote or summary]
   **Location:** [file:line or top-level]
   
   **Analysis:**
   [Is this valid? Why or why not?]
   
   **Verdict:** [Valid/Invalid/Partial]
   
   **Suggested fix:**
   [If valid or partial, how to address it]
   
   ---
   
   ## Summary
   
   | Issue | Severity | Validity | Code Volume | Risk |
   | ----- | -------- | -------- | ---------- | ---- |
   | ...   | ...      | ...      | ...        | ...  |
   
   | Comment | Verdict | Action |
   | ------- | ------- | ------ |
   | ...     | ...     | ...    |
   
   ## Recommended Actions
   
   1. [What to fix and how]
   

5. Update [SESSION_PATH]/_overview.md:

   • Flow Log: - [HH:MM] PR comments analysis -> [filename].md
   • Files: - [filename].md - PR review analysis

6. If the sessions directory is a git repo, commit session docs:

   cd [SESSION_DIR] && git add . && git commit -m "PR comments analysis"
   

7. Report:

   • A table for all issues with columns: Severity, Validity, Code Volume, Risk.
   • Which comments are valid, invalid, or partial.
   • The recommended fixes.
   • Ask which issues to address.

Rules

• Do not start fixing review comments during this skill.
• Do not dismiss a comment without reading the relevant code path.
• If a reviewer cites stale code or the wrong path, say so and explain the live path.
• Preserve uncertainty: use Partial when the concern is directionally right but the proposed fix or cited location is wrong.
• Always include a compact triage matrix for every issue, both in the session report and in the final user-facing summary, with exactly these columns: Severity, Validity, Code Volume, Risk.

Triage Matrix Columns

• Severity: impact if the issue ships. Use values like Blocking, Important, or Suggestion.
• Validity: investigation result. Use Valid, Partial, or Invalid.
• Code Volume: amount of code affected by the fix (implementation size). Use concise labels such as Small, Medium, or Large, optionally with a short reason.
• Risk: implementation/regression risk of the fix. Use concise labels such as Low, Medium, or High, optionally with a short reason.

Triage Principles

Default to fixing review comments in the current PR when the PR introduced or amplified the issue.

Mark an issue Fix now when:

• The PR created code that worsens structure, consistency, layering, or architectural clarity.
• The PR expanded an existing weak pattern in a way that makes the codebase harder to maintain.
• The fix is reasonably scoped, behavior-preserving, and can be covered with focused tests.
• The concern is not a product redesign but a local ownership/layering/source-of-truth cleanup.

Mark an issue Defer only when at least one is true:

• The issue clearly predates the PR and the PR did not meaningfully touch or worsen it.
• The fix requires a broader design decision, migration, ownership change, or cross-service contract change that is not justified by the PR.
• The proposed fix is primarily an optimization and risks destabilizing a race-sensitive or recently fixed path.
• The reviewer explicitly filed or points to a follow-up ticket whose scope truly owns the work.

Avoid weak deferral rationales:

• Do not say "current behavior is correct and tested" as the main reason to defer if the PR made architecture or layering worse.
• Do not defer a service/controller/repository boundary violation introduced by the PR when extraction is local and testable.
• Do not defer duplication introduced by the PR when a small helper/table removes it without changing behavior.

When documenting deferred issues, include:

• Why the comment is valid or partially valid.
• Why it is not appropriate for this PR under the criteria above.
• The concrete follow-up owner/ticket if known; otherwise say what kind of follow-up is needed.