pr-comment

Triage, plan, fix, and resolve GitHub pull request review comments in four phases.

Updated Feb 27, 2026
One-click install
npx skills add https://github.com/Dawaad/skills --skill pr-comment-dawaad
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pr-comment
Source: https://github.com/Dawaad/skills/tree/main/skills/pr-comment
Command: npx skills add https://github.com/Dawaad/skills --skill pr-comment-dawaad

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Handling inline review comments on GitHub pull requests often requires long multi-step sessions that exceed a single context window. This Skill breaks the work into four resumable phases with state persisted in a .pr-review/ directory, so progress survives context resets between phases. ## Core Features & Use Cases - Four-phase workflow: Run /pr-comment:triage, /pr-comment:plan, /pr-comment:fix, and /pr-comment:resolve in order to discover, plan, implement, and close review threads. - Severity classification: Comments are classified as critical, important, moderate, or nitpick, with user confirmation before any code changes are made. - Persistent state: Triage results, resolution plans, and architectural impact notes are stored as JSON in .pr-review/ at the repo root. - Use Case: A reviewer leaves 12 inline comments on your pull request. You run the triage phase to classify them, approve the ones worth fixing, generate resolution plans, implement the fixes, and then reply to and resolve each thread on GitHub. ## Quick Start Ask the assistant to handle the review comments on your pull request, then start the workflow by running the /pr-comment:triage command.

Frequently Asked Questions about pr-comment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle GitHub pull request review comments systematically?

Use a four-phase workflow: triage comments to classify severity, plan resolutions with architectural impact analysis, implement the fixes, then reply to and resolve each thread. State persists in .pr-review/ so you can pause between phases.

How are PR review comments classified by severity?

Comments are classified as critical (correctness bugs, security, data loss), important (logic errors, missing edge cases), moderate (readability, style), or nitpick (subjective preferences). You confirm which comments to address before any changes are made.

Can I pause and resume PR comment resolution across sessions?

Yes. All state is stored as JSON files in a .pr-review/ directory at the repo root, including triage results and resolution plans. Each phase reads this state, so you can reset context between phases without losing progress.

What files does the PR comment workflow create in my repository?

It creates a .pr-review/ directory containing meta.json (PR number, repo, branch), triage.json (classified comments), and plans.json (resolution plans). You should add .pr-review/ to your .gitignore.

Does the workflow resolve review threads on GitHub automatically?

The final resolve phase replies to each addressed comment and resolves the threads on GitHub, but only after the triage, plan, and fix phases have completed and the fixes have been verified.