Prp Issue

Arguments: $ARGUMENTS (and $1, $2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.

Deliver One Workstream

Own planning through PR and every correction in this context. Preserve accumulated reasoning across that implementation lifecycle; use fresh contexts only where independence is the feature—review.

Input: $ARGUMENTS (if absent, use the conversation).

Contract

• Continue autonomously through plan, implementation, PR, review, correction, re-review, and CI.
• Compose $prp-plan, $prp-implement, and $prp-review; do not reproduce their craft.
• Keep the plan, implementation report, PR, review report, publication URL, validation, and CI as the workstream's proof. Never reduce a handoff to a private summary.
• Stop only for a product decision, missing prerequisite primitive, inaccessible dependency, permission boundary, or repeated no-progress failure that cannot be resolved in this context.
• Do not merge. The caller or outer orchestrator owns that gate.

1. Resolve and plan in this context

Accept an issue or tracker URL, PRD, document, existing .plan.md, free-form request, conversation context, or reviewed PR.

• Review-only request or contributor PR: use $prp-review and stop.
• Existing plan: use it; publish it first with $prp-plan publish <path> when issue-derived publication is missing.
• Issue with a published plan: let $prp-implement resolve and persist its absolute path from source metadata.
• Existing reviewed PR: resolve its plan and implementation report, then resume correction or verification without repeating completed work.
• Every other input: invoke $prp-plan now in this context. Keep its reasoning available for implementation.

Require the absolute plan path and, for issue-derived plans, the verified publication URL before review.

2. Implement through PR in this context

Invoke $prp-implement with the plan path—or source issue when resolving a published plan—and any explicit base. Keep ownership in this context through validation, scoped commit, PR creation, linked PRD updates, and the implementation report.

Do not start review without VALIDATION: GREEN, the absolute plan and report paths, and a live PR.

3. Review in a fresh context

Start a fresh agent with this prompt:

Invoke $prp-review on <PR URL or number> with scopes <requested scopes, if any>. Applicable caller decisions and scope constraints, verbatim: <decisions or "None">. Read the linked plan and implementation report, publish the complete review to GitHub, and return the verdict, canonical review-report path, verified publication URL, and any blocker. Do not modify the PR.

Require the complete canonical review report and verified GitHub publication. Wait until all selected review agents have finished and the review coordinator has produced the complete canonical report before addressing any finding; never start correction from partial reviewer messages.

4. Disposition findings and re-review

Read the complete report in this implementation context and disposition every finding. Fix valid Critical or Important findings. Prefer fixing a valid Suggestion now when the correction is narrow, low-risk, aligned, and cheaper than another delivery cycle. Use NOT A FINDING with decisive evidence when it is false or already satisfied. Use TRACKED FOLLOW-UP only for clearly valuable, distinct work with a verified issue link. Use DECLINED for speculative defense-in-depth, overengineering, preference, or unclear or undesirable direction; record why and do not create an issue. Never leave a bare deferred state.

Batch every accepted correction and evidence-backed disposition into one coherent pass, then invoke $prp-implement in review-correction mode in this same context. Start one fresh $prp-review --verify-corrections agent with the previous reviewed head, current PR head, complete canonical report, and dispositions. Never start another review when neither the head nor disposition evidence changed. Do not wait for or check CI between rounds; CI clears once, at the end of the workstream, on the final head.

Repeat correction and focused verification only for an unresolved prior blocker, a disproven disposition, or a defect caused by the correction. Return to a full review only when the correction materially changed the PR's outcome, architecture, or scope. Continue until the independent verdict is READY TO MERGE and every finding has a terminal disposition. Resolve REVIEW INCOMPLETE by obtaining its missing validation or evidence; stop only when that is genuinely unavailable.

5. Require green CI

After READY TO MERGE, wait for every required CI check. A pending check is not green. For a PR-caused failure, invoke $prp-implement in CI-correction mode with the PR and complete failing-check evidence in this context, then run $prp-review --verify-corrections against the changed head. When no required CI exists, rerun the repository's authoritative local gate and record it instead.

6. Return proof and follow-ups

Only after review and CI are green, return the outcome, absolute plan and implementation-report paths, PR URL, latest review verdict, review-report path, publication URL, validation, and CI evidence. Then suggest only meaningful remaining non-blocking follow-ups, including already-created tracking issues; do not present required unfinished work as optional follow-up.