mcpField
P
pr-to-ready

pr-to-ready

github.com/owainlewisDevelopment42380 installsUpdated 2w ago
Repository

About pr-to-ready

A skill for taking a pull request from review to a readiness assessment. It guides agents through inspecting live PR state, addressing actionable feedback, running checks, and reporting status without merging.

Key features

  1. 01Inspect live PR details and local Git state
  2. 02Classify reviewer feedback
  3. 03Make focused fixes and respond to threads
  4. 04Run checks and re-check after pushing
  5. 05Report readiness without merging

Use cases

  1. 01Triage reviews on an open PR
  2. 02Resolve actionable review comments
  3. 03Check readiness before requesting merge
  4. 04Identify blockers and remaining review items

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/owainlewis/blueprint --skill pr-to-ready

After installing, type/pr-to-readyin Claude Code to confirm it loaded.

Details

From the project README

PR To Ready

  1. Identify the PR from $ARGUMENTS, the current branch, or open repo PRs.
  2. Inspect the live PR: diff, commits, checks, reviews, unresolved threads, comments, mergeability, and local git status.
  3. Classify feedback: actionable, disputed, resolved, outdated, informational, needs-human.
  4. Fix actionable items, keeping changes small. Push back on disputed items with a comment on the thread explaining why, and do not change the code. Stop for product, security, code-owner, or risk decisions.
  5. Run the smallest checks that prove the fix, wider checks when shared or user-facing behavior changed.
  6. Re-check the PR after pushing. Reply on each addressed thread with what changed. Update the linked ticket with proof when accessible.
  7. Report Ready, Not ready, or Blocked, with changes, checks run, pushed-back items, and remaining items.
  8. If asked "merge?", answer directly. Never merge.

Rules

  • Never merge.
  • Push back only with a concrete reason: correctness, scope, or a documented convention. Preference disagreements from a human reviewer go to needs-human, not a rebuttal.
  • Do not expand the task for nice-to-have feedback.
  • Do not mark ready while required checks fail or actionable feedback remains.
  • Trust the live PR state, not stale summaries.
  • Do not hide skipped tests, placeholders, partial fixes, or assumptions.

Comments

Markdown supported