# Issue To Pr > Coordinate a GitHub issue from rough intake through planning, implementation, verification, pull request, and manual merge by reconstructing state and delegating to existing skills. Use when a user provides a GitHub issue and asks to start, implement, continue, deliver, or move it toward a PR; when they ask what comes next in an issue workflow; or when work is split across a parent issue and subissues with integration branches. Also trigger on explicit `$issue-to-pr` requests. - Skill: `ilya-valasiuk/issue-to-pr` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add ilya-valasiuk/issue-to-pr` - Raw SKILL.md: https://api.skillmd.com/api/skills/ilya-valasiuk/issue-to-pr/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: ilya-valasiuk (https://skillmd.com/u/ilya-valasiuk) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ilya-valasiuk/issue-to-pr --- # Issue To PR Guide one GitHub issue through delivery without making the user remember the workflow. Treat GitHub and Git as the durable state, recommend exactly one next phase, and wait for explicit authorization before starting that phase. Remain a coordinator. Delegate specialized work to the existing skills named below instead of restating or reimplementing their procedures. ## Dependency Contract Resolve skills by name from the skills available in the current session, regardless of whether they are user-level or repository-local: - `grilling` for requirements interrogation - `refine-issue-plan` for the one-time parent planning decision and any subissue creation - `report-implementation` for the final acceptance-criteria, review, and verification gate for the current issue - `creating-pull-requests` for PR preparation, approval, push, creation, and base routing Before delegating any workflow phase, confirm all four direct dependencies are available. If any are missing, stop and name them. Do not improvise a replacement workflow or assume a filesystem path. Do not call `split-issue-into-subissues` directly; `refine-issue-plan` owns that decision and dependency. Do not call `review-implementation` separately; `report-implementation` owns the review gate, invokes that skill at most once when available, and uses its standalone base gate otherwise. Read each direct dependency's `SKILL.md` completely immediately before using it, then follow it faithfully. Let dependency skills own their own previews, approval checkpoints, and writes. ## Core Rules 1. Reconstruct before acting. Inspect current GitHub and Git state on every invocation or resume. 2. Propose one concrete next phase and wait. A user confirmation authorizes only that clearly proposed phase. 3. Treat approval as transition authorization, not evidence that known failures pass. 4. Never repeat completed planning or reporting work. 5. Never hardcode repository names, issue numbers, branch names, or a default branch. 6. Never infer a release. Use a release PR route only when the user explicitly requests a release. 7. Never stage, commit, push, open a PR, merge, close an issue, or update GitHub outside an authorized phase and the delegated skill's rules. 8. Keep state in GitHub and Git. Do not create a local workflow-state file. ## Reconstruct State Perform read-only discovery first: - Resolve the repository from the current checkout and read the latest issue body, comments, state, relationships, and linked PRs. - Discover the repository's actual default branch from GitHub or authoritative repository metadata. - Inspect the current branch, working tree, commits, merge bases, remote branches, and PR base/head/status. - Determine whether the issue is a parent, a subissue, or a standalone issue from explicit GitHub relationships and established context. - For split work, identify the parent integration branch and each child PR's intended base. Never guess an ambiguous parent branch. - Distinguish work already planned, implemented, reported, opened as a PR, merged, or closed. - Do not infer an issue solely from a branch name. If issue identity, parent relationship, intended base, or branch ownership remains materially ambiguous, stop and ask for the missing fact. ## Choose the Current Phase Use the first matching state: 1. **Needs discovery**: the issue has only a rough idea, links, or materially incomplete requirements. 2. **Needs refinement**: grilling is complete but the parent issue has not received its implementation brief or split decision. 3. **Ready to implement**: the current issue has an adequate brief and testable acceptance criteria, with no implementation yet complete. 4. **Implementation in progress**: code is incomplete, has known failures, or has blocking review feedback. 5. **Ready to report**: implementation appears complete and every acceptance criterion has credible evidence, but `report-implementation` has not successfully completed for this issue. 6. **Ready for PR**: reporting succeeded and no PR exists for the completed branch. 7. **Waiting for merge**: the intended PR is open or under manual review. 8. **Ready for next child**: a child PR merged into the parent integration branch and another unblocked child remains. 9. **Ready for parent integration gate**: every required child PR merged into the parent integration branch, but the parent has not passed integrated reporting. 10. **Complete**: the final PR merged into the intended default branch and the issues it is meant to close are closed. Treat closed or merged states that disagree with the intended route as discrepancies, not completion. Report the mismatch and recommend a corrective next step. ## Planning Route ### Rough issue Recommend a `grilling` phase and wait. After authorization, delegate the session to `grilling`. When it finishes, recommend `refine-issue-plan` and wait again. ### Adequately planned issue If the issue already contains a clear implementation brief, scope, constraints, and testable acceptance criteria, do not rerun grilling or refinement. Recommend implementation directly. ### Refinement Run `refine-issue-plan` only once for the parent issue. Let it decide whether the work remains one issue or is split and let it own subissue creation. After refinement finishes, recommend implementation and pause until the user explicitly says to implement or confirms that phase. Never rerun parent refinement merely because the workflow resumed or moved to a child issue. ## Implementation Authorization An explicit `implement` instruction or confirmation of a clearly proposed implementation phase authorizes: - selecting or reusing the correct implementation branch; - creating the required branch when it does not exist; and - implementing the current standalone issue or selected subissue. For a standalone issue, branch from the discovered default branch. For split work, branch the parent integration branch from the discovered default branch, then branch each child from that parent branch. Follow repository branch conventions. Reuse an existing correct branch; do not create duplicates. Use relevant repository instructions and skills during implementation. Plan mode is optional: use it when explicitly requested, or recommend it when unusual complexity makes an additional implementation plan valuable. It is not workflow state. ### Manual commit checkpoints The user owns commits. Never stage or commit unless explicitly asked. At a logical, independently reviewable milestone, the coordinator may recommend a manual commit checkpoint and pause. Include: - completed scope; - changed files or areas; - verification performed so far; - a suggested Conventional Commit message; and - the next implementation stage. Do not run `report-implementation` at commit checkpoints. Resume implementation after the user reviews and commits or tells the coordinator to continue. ### Finish implementation When the current issue appears fully implemented, map each acceptance criterion to available code, automated checks, or explicit manual evidence. If any criterion is incomplete, failed, or unsupported, remain in implementation and state what is missing. If all criteria appear satisfied, recommend the reporting phase and wait. The user's confirmation authorizes running `report-implementation`; it does not override that skill's acceptance, review, or verification gates. If the gate fails or is blocked, return to implementation. Invoke it again only after the reported gap is addressed and the work again appears complete. A successful posted report is the durable completion signal for this phase. ## Standalone Issue Route Follow this sequence, with a separate authorization before every arrow: `planning complete` -> `implementation` -> `report-implementation` -> `creating-pull-requests` -> `manual review and merge` -> `completion check` Supply the discovered default branch as the intended PR base. After the PR opens, report that the workflow is waiting for manual review and merge. Never merge it on the user's behalf unless separately and explicitly requested outside this workflow. On `continue`, inspect the PR and issue. Mark complete only when the PR merged into the intended default branch and the issue is closed. ## Split Issue Route Keep one parent integration branch and deliver existing child issues sequentially unless the user explicitly chooses another safe order. For each child: 1. Reconstruct parent, child, branch, dependency, and PR state. 2. Select the next unblocked child by dependency order, foundational value, and risk reduction. 3. Recommend that child and wait; allow the user to override the order. 4. Implement it on a child branch based on the parent integration branch. 5. After all child acceptance criteria appear satisfied, recommend and then delegate one `report-implementation` gate for that child. 6. After successful reporting, recommend and then delegate `creating-pull-requests`, explicitly supplying the parent integration branch as the base. 7. Wait for manual review and merge into the parent integration branch. After a child PR merges, reconstruct state and recommend the next unblocked child. Do not rerun parent refinement. After all required child PRs merge: 1. Recommend the parent integration reporting phase and wait. 2. Run one integrated `report-implementation` gate for the parent against the discovered default branch. 3. If it succeeds, recommend the final parent PR and wait. 4. Delegate `creating-pull-requests`, explicitly supplying the discovered default branch as the base and the appropriate parent/child issue closure context. 5. Wait for manual review and merge. 6. Mark complete only after the final parent PR merges into the intended default branch and the issues it is meant to close are closed. ## Resume Behavior Interpret `continue`, `what is next?`, or an equivalent request as authorization to reconstruct state and recommend one next phase, not to execute multiple phases automatically. When waiting for a PR merge, inspect its current state: - Open: keep waiting and report checks or review blockers when relevant. - Merged into parent integration branch: move to next-child selection or the parent integration gate. - Merged into default branch: verify issue closure and completion. - Closed without merge, merged into the wrong base, or issue still open unexpectedly: report the discrepancy and recommend one corrective phase. ## Status Footer End every response with a compact GitHub-oriented footer. Keep the final answer self-contained. For standalone issues: ```text Issue: Phase: Branch/base: -> Blockers: Next step: Awaiting: ``` For split issues: ```text Parent issue: Current child: Phase: Branch/base: -> -> Blockers: Next step: Awaiting: ``` Do not offer several equally actionable next steps. Recommend one, explain a blocker when present, and wait.