# Pr Readiness > Prepare a pull request for human review and decide whether it may leave Draft. Use when creating or rewriting a PR description, marking a PR ready, responding to review, or checking whether a change is mergeable. Keeps incomplete evidence Draft. Do NOT use as a substitute for human approval or repository merge policy. - Skill: `arcadeai/pr-readiness-3` (Agent Skill) - Install (CLI): `npx skillmds@latest add arcadeai/pr-readiness-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/arcadeai/pr-readiness-3/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ArcadeAI (https://skillmd.com/u/arcadeai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/arcadeai/pr-readiness-3 --- # PR Readiness: Treat the Reviewer as the Customer Make the pull request cheap to understand, verify, and approve. Ready means the author believes the current head can merge immediately after approval—not that the branch merely has a plausible diff or green unit tests. ## Observe and preserve Read the ticket, merge-base diff, commits, current PR body, check rollup, reviews, and unresolved threads at the current head SHA. Generated summaries may supplement this evidence, never replace or obscure it. Keep speculative work on a branch. Open a requested PR as Draft only for concrete CI, AI review, or a narrow human check. Reply before resolving every thread; leave disagreements for the reviewer to resolve; re-request review after a material push. Apply or answer every finding. Changing Draft/Ready state requires explicit authority in the current user request for that exact change. Otherwise observe and report state only. ## Seven hard Ready-for-Review gates Evaluate every gate. Missing, stale, unknown, pending, skipped without an explained consequence, or contradicted evidence is a **hard blocker**: recommend Draft and give the recovery action. 1. **Ticket linkage:** the PR links the Linear ticket or the repository's authoritative tracker item. 2. **Author comprehension:** inspect the complete diff and understand every change; unexplained generated, copied, or agent-authored output blocks readiness. 3. **End-user execution:** exercise the current head through its end-user path. Record steps and results; tests alone are insufficient. If no runnable surface exists, record `not applicable`, why, and the nearest real delivery boundary. Never invent a walkthrough. 4. **Checks:** relevant local checks and CI are terminal and green for the current head. If the repository has no CI, record that and use current-head `$safeword:verify` evidence instead. 5. **AI review:** complete the configured AI review and apply every finding or answer it with a reason. Configured policy decides acceptable independence; `require unsatisfied` blocks. AI review is evidence, never approval. 6. **Fresh self-review:** read the complete current diff top-to-bottom after the final material change. Confirm scope, behavior, clarity, and accidental files. 7. **Merge confidence:** the author can state that the current PR is immediately mergeable after approval, with no known follow-up required to make it safe. When `$safeword:quality-review` or `$safeword:finish-review` returns, resume this same readiness run and evaluate gate 5. Disclose degraded or absent independence. Do not restart the review loop unless a later material change makes its evidence stale. ## Write for the reviewer Build the body from the ticket and diff. Keep only applicable sections and write `None` for a meaningful empty state. - **Why:** job to be done in plain English. - **What changed:** concise approach, non-obvious decisions, scope, exclusions, and direct dependency when stacked. - **Verification:** commands, end-user steps, results, and any patch coverage below the repository's target, with the reason. - **Risks and review focus:** blast radius, rollback, open questions, and where human judgment is wanted. - **Readiness evidence:** use this exact durable handoff shape. Use `PASS` only for complete gates, `N/A` only for gate 3 with its reason and nearest-boundary proof, and `BLOCKED` with the recovery action for all others: ```text Head: 1. Ticket linkage — PASS: 2. Author comprehension — PASS: 3. End-user execution — 4. Checks — PASS: 5. AI review — PASS: 6. Fresh self-review — PASS: 7. Merge confidence — PASS: ``` Never carry this evidence forward after the head changes. Where the Safeword PR review workflow runs, the `safeword/pr-readiness` commit status reports this block as current, stale, missing, or blocked for each head; it observes the block and never judges the gates behind it. Never manufacture verification or describe cumulative stack changes as this slice's work. Prefer a concise reviewer narrative over an implementation manifest. ## Report the decision Report the current head and each gate as `pass`, gate 3 as justified `n/a`, or `blocked`, with concrete evidence. Then provide the reviewer-oriented body or the minimal edits it needs. End with exactly one outcome: - `READY` when all gates pass (including a valid gate 3 `n/a`) and the PR is already Ready, or the user explicitly authorized Ready promotion. - `GATES PASS — awaiting explicit Ready authorization` when all seven gates pass, the pull request is Draft, and the current request did not authorize promotion. - `DRAFT — ` when one or more gates are blocked; this recommends state and does not authorize demotion. Do not run `gh pr ready` or `gh pr ready --undo` unless the current user request explicitly authorizes that exact state change.