CtrlK
BlogDocsLog inGet started
Tessl Logo

prp-issue

Autonomously owns one workstream from an issue, PRD, document, existing plan, or free-form request through planning, implementation, pull request, independent review, corrections, and green CI. Always use when the user asks to implement or ship work end to end, take an issue or idea to a reviewed PR, run plan to PR, invokes /prp-issue, or when prp-orchestrate needs an end-to-end delivery engine.

77

Quality

98%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

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.

Repository
Wirasm/prp
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.