← ClaudeAtlas

resolve-issuelisted

Orchestrate the whole issue-to-PR pipeline for one ticket: fact-check the issue, draft a plan, harden it, implement the fix, write tests, review the fix, and open the PR — behind a plan-approval gate, pausing again wherever a decision is yours. Use whenever someone wants an issue / bug / Jira ticket taken from diagnosis all the way to a pull request, even if they don't name the skill. Resumable across sessions. Do NOT trigger when the user wants only ONE stage — route those to the component skill directly: "just fact-check this issue" is review-issue-fact; "review this plan" is review-plan-risk; "review my fix / diff before the PR" is review-code-risk; "add tests" is test-authoring; "open / raise a PR" is open-pr; "address / resolve the PR comments" is resolve-pr-comments. Also do NOT trigger for merging / completing a PR, or plain git operations. Trigger phrases: "resolve this issue", "run the issue-to-PR pipeline", "take this Jira from diagnosis to PR", "/resolve-issue".
softwareone-platform/issue-to-pr · ★ 1 · Code & Development · score 67
Install: claude install-skill softwareone-platform/issue-to-pr
# Resolve issue Drive one ticket through the full issue-to-PR pipeline, from fact-checking the issue to opening the pull request, by invoking the already-built component skills in order and holding the human gates the flow needs. This skill is a **sequencer, not a re-implementation**: it never re-derives what a component skill does, and it never threads a component's verdict, risk table, or test selection into the next as a program argument — each component reads its own input (the issue text, the plan file, the git diff) and produces its own output behind its own gates. The orchestrator's whole job is ordering, the human gates it owns, and the durable handoff artifacts that make the pipeline resumable. Run this in the **main conversation loop**, never as a subagent. The component skills spawn their own fresh verifier subagents, and the gates here are interactive — a subagent context loses the human gates and `ExitPlanMode`, and eats the depth budget those verifiers need. If this skill finds itself running inside a subagent, it stops (see the preamble). The pipeline splits at plan approval — its Phase A→B pivot — into **Phase A (diagnose and plan)** and **Phase B (build and open the PR)**, and ends at PR-created. Phase B adds conditional review checkpoints (b-security-review and the b-code-risk→b-open-pr checkpoint) that pause only when a review surfaces something the human must disposition, and otherwise pass through. **Plan approval is not the last stop, though**: `b-ope