Agent-Skills.md

Agent Skills: Issue To PR

Orchestrate and judge an issue-to-PR pipeline without editing artifacts directly. Use when the user wants an issue-to-PR workflow, task-to-PR pipeline, or structured path from request to PR readiness. Routes each stage to the owning skill or subagent, checks gate outputs, asks for revisions when the pipeline drifts, and keeps PR as a placeholder.

UncategorizedID: iamhenry/ai-project-starter-kit/issue-to-pr
53

Install this agent skill to your local

pnpm dlx add-skill https://github.com/iamhenry/ai-project-starter-kit/tree/HEAD/.agents/skills/issue-to-pr

Skill Files

Browse the full folder contents for issue-to-pr.

Download Skill

Loading file tree…

.agents/skills/issue-to-pr/SKILL.md

Skill Metadata

Name
issue-to-pr
Description
Orchestrate and judge an issue-to-PR pipeline without editing artifacts directly. Use when the user wants an issue-to-PR workflow, task-to-PR pipeline, or structured path from request to PR readiness. Routes each stage to the owning skill or subagent, checks gate outputs, asks for revisions when the pipeline drifts, and delegates PR creation to `create-pr`.
<!-- Purpose: Compose independently useful skills into an autonomous path from a task to verified PR readiness, involving the user only for decisions or blockers that require them. Principles: - Match effort to task size and risk. - Reuse settled context and valid evidence. - Preserve independent review and real outcome proof. - Avoid expensive ceremony, duplicate work, and over-verification. -->

Issue To PR

How We Work

  • Each stage does one job. No stage judges its own work.
  • Prove behavior before freezing it. Build writes code and runs existing checks. Regression tests come after verification passes.
  • Fail fast, then unblock. Give each dispatch an expected duration. On a blocker or overrun, find the cause and route the cheapest fix to its owner (another device, setup, test data, or proof route) within your authority. Ask the user only when the unlock needs their action, permission, or intent, and then give the blocker, its unlock, and your recommendation.
  • Stay visible. Every dispatch tells the user the stage, what it proves, the expected duration, and where to watch. Before answering a status question, read the helper's latest output.
  • Rework only the delta. Reuse settled artifacts and evidence the change does not touch.

Anti-Patterns

  • Re-sending a check that is blocked for the same reason.
  • Handing the user a blocker the pipeline could resolve itself.
  • Reporting "still working" from a pending state alone, or ending a turn silently while work is pending.
  • Writing tests before behavior is proven, or treating passing tests as proof.
  • Re-running the full pipeline for a small follow-up, or editing from this wrapper to skip gates.
  • Declaring done on an edit that no gate has seen.

Pipeline Components

| Component | Role | Why | | ---------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------- | | gather-context | Owns intake, research, and proposal options. | Grounds the pipeline before judging or planning. | | judge-proposal | Exact reviewer subagent reviews proposal quality. | Catches weak assumptions before plan creation. | | create-issue | Owns the selected implementation plan. | Keeps planning artifacts with the planning workflow. | | judge-plan | Exact reviewer subagent reviews plan readiness. | Prevents implementation from starting on a weak plan. | | Implementation orchestration | Delegates implementation and repository writes to Task with exact subagent_type: build. | Keeps this wrapper orchestration-only while moving the plan toward working code. | | code-quality-gate | Exact reviewer subagent reviews code quality after implementation. | Catches implementation issues before QA proof begins. | | verification-gate | Exact qa subagent proves completed work. | Keeps QA execution outside this wrapper. | | agent-browser | Browser proof path used by verification-gate. | Supports web and mobile-web validation without defining it here. | | xcodebuildmcp-cli | Apple-platform proof path used by verification-gate (Expo projects prove via Metro dev server first; xcodebuildmcp for native changes and builds). | Supports iOS and macOS validation without defining it here. | | create-pr | Exact qa/general subagent opens the PR with an evidence-based body. | Makes the pipeline end at an opened PR instead of a placeholder. |

Orchestrate and judge the pipeline. Do not create, edit, append, or repair task artifacts outside the artifact and coordination boundaries below.

This skill connects modular skills, checks whether each stage produced the expected artifact, and routes revisions back to the owning skill or subagent when the pipeline is off track.

An explicit request to execute this pipeline authorizes in-scope intake, research, technical approach selection, planning, implementation, and independent acceptance, subject to user limits and host permissions. Pass that authority and the existing handoff contract to each owner; do not ask for implementation approval again. Research-only or planning-only requests retain their endpoint. Commit, push, PR creation, and merge require explicit publication authority; with that authority the pipeline ends at an opened PR via create-pr, without it at PR readiness. Repair owned gaps autonomously within the bounds below; ask the user only for unresolved intent, permission, or a blocker requiring their action.

Use this composition for authorized delivery; focused research, planning, review, or verification calls remain valid and stop at their requested endpoint. Supply scope, authority, and optionally S/M/L/XL with a risk/uncertainty rationale. Each owner calibrates its own inputs, execution, effort, independence, evidence, recovery, and completion; size is not a stage-skip rule. A tiny delivery still passes applicable intake, selection, plan, implementation, fresh quality, and fresh acceptance responsibilities. Size scales gate depth, not a combined session. Do not reproduce owners' operating procedures here or grant publication beyond user authority.

Pipeline

The caller must supply either an accessible existing {ISSUE_DIR}/ticket.md path or a GitHub issue reference before any dispatch. For a GitHub issue reference, delegate ticket materialization to create-ticket, then derive ISSUE_DIR from the returned path; this wrapper does not create or import the ticket itself. gather-context must reuse this ISSUE_DIR rather than creating another directory. If neither input resolves to an accessible ticket path, return BLOCKED. All pipeline artifacts are relative to ISSUE_DIR.

Use existing issue.md, plan.md, and stage reports rather than restarting intake. Before resuming, load the supplied ticket state. Explicit user changes take precedence: route reconciliation to the artifact owner and request the owners' assessment of affected evidence and required rechecks. Preserve sound unrelated evidence; coupled, uncertain, or consequential changes may justify broader fresh assurance, not an automatic whole-pipeline restart. Before dispatch, check the owner's declared inputs and write scope. A missing owner-declared prerequisite is BLOCKED; preserve that result, name the unlock condition, and do not repair another owner's work. Repair pipeline-owned gaps through their owners, not by asking the user to author documents. Ask only for missing intent or permission. Allow one narrow repair per underlying prerequisite or receipt gap, within existing stricter limits; if it remains unresolved, stop with the owner and unlock condition. Renaming a gap or redispatching never resets a budget.

When resolving referenced skills, agents, or commands, check the project's locations and OpenCode's configured global directory (commonly ~/.config/opencode). Projects may rely entirely on global resources rather than importing local copies. Use the available configuration to locate the same owner, pass its resolved path onward, and distinguish a failed lookup from a genuinely unavailable resource before declaring a prerequisite missing.

1. Gather Context And Intake

  • Run gather-context with the raw user issue/request in intake-only mode. Before research, require {ISSUE_DIR}/issue.md with the task classification and a sufficiently clear reported behavior or requested outcome; unresolved intake questions return to their owner under Revision Routing.
  • For bug tasks, delegate reproduce-bug through Task with exact subagent_type: qa at this boundary, before research, proposal selection, or planning. The qa agent configuration owns its model; do not override it here or silently substitute another agent. If qa cannot start by exact name, return BLOCKED. Continue only on REPRODUCED with evidence matching the reported entry point; a mocked or different-path reproduction does not satisfy this gate. On NOT_REPRODUCED or BLOCKED, stop and report its structured result and next action. Safe, bounded prerequisite investigation may resolve a blocker, but does not authorize production edits or bypass reproduction. Reuse valid existing faithful evidence through the reproduction owner rather than requiring another run. If the reproduction owner retained evidence but omitted the structured result, send one conclude-only instruction to use existing evidence, run no new probes, and return the required result. If it still does not return, stop with an output-contract blocker; do not rerun or independently judge the reproduction.
  • For non-bug tasks, skip reproduction. Resume gather-context at Phase 1 in the same ISSUE_DIR, passing the reproduction result and evidence paths for bugs so research and proposals are grounded in observations. Reproduction establishes the symptom, not the cause; research investigates the cause, and the causal gate before implementation still applies.
  • Let gather-context choose investigation depth and applicable evidence locations under its own contract; do not prescribe a research fan-out or option count.
  • Gate: its declared intake, evidence, and supported approaches are present in the existing ISSUE_DIR.
  • If the gate fails, route revision back to gather-context; do not patch artifacts here.

2. Proposal Judge Checkpoint

  • Skip this checkpoint when gather-context returns one supported approach and no decision is reserved to the user; record the skip in ## Checkpoint Timeline and continue to planning.
  • Delegate review to a fresh subagent through Task with exact subagent_type: reviewer using judge-proposal. If reviewer cannot start by exact name, return BLOCKED; do not substitute another agent.
  • The subagent must receive only the task artifacts it needs, not accumulated conversation context.
  • Pass the execution request's technical selection authority explicitly, along with any decisions reserved to the user. Grant the judge narrow writeback authority to edit only the Judge Decision section of {ISSUE_DIR}/issue.md, as required by judge-proposal's writeback contract; read-only judging without writeback never satisfies the step gate.
  • Gate: {ISSUE_DIR}/issue.md contains Judge Decision with Status: SELECTED or Status: ASK_USER.
  • If ASK_USER, use Revision Routing to distinguish an owned artifact gap from a user decision.

3. Create Issue Plan

  • Delegate planning after selection using the tracked command .agents/commands/workflow/01-plan/02-create-issue.md, passing the existing ISSUE_DIR and approved artifacts. create-issue below names this command owner, not a required registered skill. It owns plan structure and proportional detail.
  • Gate: its declared output {ISSUE_DIR}/plan.md exists.
  • If the plan artifact appears elsewhere or {ISSUE_DIR}/plan.md is missing, stop and route as a create-issue output mismatch; do not create {ISSUE_DIR}/plan.md here.

4. Plan Judge Checkpoint

  • Delegate review to a fresh subagent through Task with exact subagent_type: reviewer using judge-plan. If reviewer cannot start by exact name, return BLOCKED; do not substitute another agent. Grant the judge narrow writeback authority to edit only the Plan Judge section of {ISSUE_DIR}/plan.md, as required by judge-plan's writeback contract; read-only judging without writeback never satisfies the step gate.
  • The subagent must receive only {ISSUE_DIR}/issue.md, {ISSUE_DIR}/plan.md, and relevant {ISSUE_DIR}/research/*.md artifacts.
  • The review must be independent from the proposal judge and main-agent working context.
  • Gate: {ISSUE_DIR}/plan.md contains Plan Judge with APPROVE_PLAN, REVISE_PLAN, or ASK_USER.
  • Continue only on APPROVE_PLAN; route REVISE_PLAN to create-issue and handle ASK_USER through Revision Routing.

5. Implementation Orchestration

  • For bug tasks, require the earlier REPRODUCED result and an evidence-backed causal explanation that distinguishes the proposed cause from competing explanations before dispatching Build — suspicion about code alone is not enough. Pass the reproduction result and evidence paths to Build; do not rerun reproduction merely because the plan is approved, duplicate its SOP, or write reproduction details into plan.md. If the reported entry point or relevant conditions changed, route affected evidence back to the reproduction owner before proceeding.
  • When the causal explanation is not obvious from the reproduction result, route one bounded diagnostic step before implementation: one hypothesis, one smallest discriminating probe that is safe to run without production edits, its observation, then the next action (proceed, or one focused question to the owner). Name bugging-out in that brief so the owner picks the matching playbook. "Obvious" means existing reproduction observations already discriminate the proposed cause from competing explanations; if they do not, run the diagnostic step. Diagnostic probes may be delegated as read/safe work even though causal evidence is still required before any production edit.
  • If the reproduction observations do not discriminate the cause and a probe needs more visibility, the implementation owner may add minimal temporary instrumentation, but only inside a safe, authorized, disposable diagnostic context (branch, sandbox, or explicitly approved run): prefer existing logs first; instrument only at the uncertain boundary, recording the relevant inputs, the decision it enables, its output, and a correlation marker only when needed; count injected inputs, retries, external calls, and side effects as real cost and weigh them before adding it; never log secrets, personal data, or full prompt bodies. This never authorizes an evidence-backed production fix before the causal gate above; instrumentation for diagnosis must be removed or handed to implementation with a removal requirement.
  • Do not implement directly from this wrapper.
  • Delegate every implementation and repository write through OpenCode Task with exact subagent_type: build. Task may omit primary agents from its advertised list; that omission is not a blocker.
  • If Build cannot start by exact name, report BLOCKED. Never fall back to atlas, voyager, or another research agent.
  • Build implements and runs the plan's existing Mechanical checks. It does not verify its own behavior or add new regression tests; independent gates own proof.
  • Delegate relevant read or research operations when needed.
  • Prefer parallel Build dispatch (at most three slices) when the work splits into independent, substantial slices; sequence slices that share files or depend on each other's output. Use the plan's delegation structure when safe; otherwise split ad hoc in context only, without saving or revising plan.md.
  • Give each slice an exclusive file list as its allowed writes. Concurrent slices share one pre-dispatch baseline; attribute the owner delta by each slice's list. Assign shared files (styles, test fakes, generated output) to the integration pass. A slice needing another slice's file reports it instead of editing.
  • Fix any shared interface before dispatch and pass the same definition to every slice. If it is types only, land it first in one short Build dispatch.
  • Slices run only focused checks; no git, installs, full builds, or other shared-state writes.
  • After all slices return, resume the interface-owning slice as the integration pass: run the plan's full Mechanical checks on the combined candidate and fix only cross-slice seams. That candidate goes to code-quality-gate.
  • Collect the implementation summary, changed files, commands run, known risks, and raw Mechanical command output from Build.
  • Build owns initial execution of plan-named Mechanical checks and supplies receipts with command, exit status, exact candidate, and relevant conditions. Review assesses those receipts without rerunning them; verification independently validates reuse under its evidence rules and executes missing or invalidated checks. Build completion does not imply acceptance or require it to duplicate final QA.
  • For bug tasks, also pass the reproduction result and evidence paths (including the reproduction smoke steps) to verification so it can reuse the same faithful smoke for the before/after proof.

6. Code Quality Gate

  • After implementation is complete, delegate code-quality-gate through Task with exact subagent_type: reviewer.
  • If reviewer cannot start by exact name, return BLOCKED; do not substitute another agent.
  • Pass the inputs declared by code-quality-gate, including exact candidate identity and available receipts.
  • Gate: code-quality-gate returns APPROVE_CODE, REVISE_CODE, or ASK_USER with concise evidence.
  • Continue to verification only on APPROVE_CODE.
  • On REVISE_CODE, route the gate's classified findings and requested rechecks to their owners. Enforce its declared verdict ceiling across dispatches, separate from verification failures.
  • If ASK_USER, repair a pipeline-owned missing input under the prerequisite rule above; otherwise stop and ask the focused question.
  • Do not review or patch code directly from this wrapper.

7. Verification Gate

  • After code-quality-gate returns APPROVE_CODE, delegate verification-gate through Task with exact subagent_type: qa. The qa agent configuration owns its model; do not override it here or silently substitute another agent. If qa cannot start by exact name, return BLOCKED. Do not redispatch verification already completed on the same candidate and claims.
  • Pass the inputs declared by verification-gate, including the current candidate and bug reproduction evidence where applicable. It owns the shortest credible proof route and prerequisite recovery.
  • Gate: verification-gate returns PASS, FAIL, or BLOCKED with evidence on disk at {ISSUE_DIR}/verification/result.md.
  • Before treating the work as PR-ready, confirm the cited evidence is accessible (embedded or linked, paths resolve) and each artifact is labeled before/after where the claim depends on a state change, with stated limits. Evidence that does not open or does not support the claim is not PR-ready.
  • After it returns, run only a file-existence check: test -f on {ISSUE_DIR}/verification/result.md and every cited evidence path. Missing file = FAIL. This is not QA.
  • Continue only on PASS when every test -f succeeds. A PASS paragraph with missing files is FAIL.
  • After PASS, resume Build to add the smallest regression test that preserves the proven behavior, then get a code-quality-gate review of that test-only delta. Product code is unchanged, so verification is not rerun; a product-code change returns to step 6.
  • On FAIL or BLOCKED, route the verification owner's classified outcome and requested rechecks; enforce its declared ceiling across dispatches. Source corrections require fresh code-quality approval before acceptance. Do not redispatch against an unchanged blocker or add unrelated edits for a proof gap.
  • Do not run QA directly or define browser, iOS, macOS, or non-UI verification steps in this wrapper.

8. PR Creation

  • After verification PASS and regression-test review, delegate PR creation to create-pr through Task with exact subagent_type: general.
  • PR creation is publication: confirm the user's explicit authority before this dispatch; without it, stop at PR readiness with the verified candidate and evidence package.
  • Pass the exact candidate identity (branch, commit SHA, base), the verified evidence paths from {ISSUE_DIR}/verification/, and the issue title for the PR title.
  • Gate: create-pr returns the PR URL and pushed branch.
  • After PASS, resume Build to add the smallest regression test that preserves the proven behavior, then get a code-quality-gate review of that test-only delta. Product code is unchanged, so verification is not rerun; a product-code change returns to step 6. A test-only delta may ride the same PR via one create-pr body update in place of a second PR.
  • On FAIL at this stage (missing evidence, gh failure), route repairs to the owning gate per Revision Routing; do not patch bodies or retry gh from this wrapper.
  • Do not write PR bodies or define review/merge policy in this wrapper.

Artifact Contract

Allowed task artifacts:

  • {ISSUE_DIR}/ticket.md coordination sections Pipeline State and Checkpoint Timeline, maintained only by issue-to-pr
  • {ISSUE_DIR}/lessons.md workflow lessons timeline, maintained only by issue-to-pr
  • {ISSUE_DIR}/issue.md
  • {ISSUE_DIR}/plan.md
  • {ISSUE_DIR}/research/*.md
  • {ISSUE_DIR}/reproduction/ (retained proof and flows/) owned by reproduce-bug
  • {ISSUE_DIR}/verification/ (result.md, screenshots/, videos/) owned by verification-gate

Other than lessons.md, do not create helper docs, reference files, sidecar state, ADR files, or wrapper-specific metadata. The wrapper must not write {ISSUE_DIR}/verification/; it only checks cited paths exist.

Durable coordination state

Use the existing {ISSUE_DIR}/ticket.md as the durable coordination source of truth, not as a source of domain conclusions. The wrapper may add or update only the ## Pipeline State and ## Checkpoint Timeline sections. It must not edit any other ticket content or grant itself general artifact-write authority.

For every dispatch, including repairs, follow this exact sequence: update pre-dispatch ## Pipeline State; capture the repository-path baseline; dispatch; compute the owner delta; enforce the declared allowed scope; update post-dispatch ## Pipeline State and ## Checkpoint Timeline. The state snapshot contains only these fields: stage, exact candidate, latest checkpoint/receipt, next owner/action, allowed writes, retries consumed, and blocker/unlock condition. The owner delta excludes changes confined to the two mutable ticket coordination sections.

Identify each candidate by a commit SHA, or by a base SHA plus a stable diff identifier over delivery paths. Changes to the two mutable ticket coordination sections do not alter candidate identity or count toward the dispatched owner delta. After each completed or blocked checkpoint or attempt, append one concise, candidate-bound entry to ## Checkpoint Timeline. For an owner artifact, include the stage or checkpoint, exact candidate, outcome, owner evidence link, and next owner/action or unlock condition. When no owner artifact exists, the timeline entry is the durable receipt and includes only the stage and exact candidate needed to bind it plus the returned result's exact native outcome: for gates, failed criterion IDs when supplied, otherwise the exact concise findings or required rechecks and evidence path/line references; for Build/task results, the completed or blocked outcome, exact blocker or remaining work, and evidence path/line references. Never invent verdicts or IDs or paraphrase domain reasoning.

If the ticket state conflicts with an owner artifact, the owner artifact controls. issue-to-pr stops progression, refreshes only the two bounded ticket sections from the authoritative owner verdict or reference, mechanically confirms agreement, and resumes. Never edit the owner artifact. Fresh judges receive only their currently declared inputs. Do not pass the ticket timeline unless the judge's own skill explicitly requires it.

Keep {ISSUE_DIR}/lessons.md as an append-only timeline: create it with a # Lessons heading when ISSUE_DIR resolves, or resume the existing file. As the run progresses, append brief dated entries for mistakes you make, missing context or tools you wish you had, and things learned about the environment, including useful blockers and user corrections. Use - YYYY-MM-DD HH:mm TZ | stage | observation | response or next-run improvement. Keep entries factual and practical; skip routine checkpoints, duplicates, guesses, secrets, and personal data. Do not create MISTAKES.md, DESIRES.md, or LEARNINGS.md. Lessons are advisory, not gate evidence or pipeline state; do not pass them to fresh judges.

Ownership Boundaries

| Artifact or decision | Owner | | ---------------------------------------------------- | ---------------------------------- | | {ISSUE_DIR}/issue.md intake, scenarios, approaches | gather-context | | {ISSUE_DIR}/research/*.md evidence reports | gather-context research agents | | {ISSUE_DIR}/reproduction/ evidence and flows | reproduce-bug via exact qa subagent | | Judge Decision in {ISSUE_DIR}/issue.md | judge-proposal via exact reviewer subagent | | {ISSUE_DIR}/plan.md | create-issue workflow | | Plan Judge in {ISSUE_DIR}/plan.md | judge-plan via exact reviewer subagent | | Implementation code changes | Build via Task subagent_type: build | | Code quality decision | code-quality-gate via exact reviewer subagent | | Verification proof | verification-gate via exact qa subagent | | {ISSUE_DIR}/verification/ | verification-gate via exact qa subagent | | Pipeline State and Checkpoint Timeline in {ISSUE_DIR}/ticket.md | issue-to-pr | | {ISSUE_DIR}/lessons.md | issue-to-pr | | Pipeline order, gates, revision routing | issue-to-pr |

When an artifact is missing or malformed, ask the owner to revise it. Do not fix it inside this wrapper.

Delegation Rule

Judge, Build implementation, code quality, and verification work is delegated:

  • Use Task with exact subagent_type: reviewer for judge-proposal and judge-plan in fresh subagent sessions.
  • Use Task with exact subagent_type: build for all implementation and repository writes. If Build cannot start, report BLOCKED; advertised-list omission never permits an atlas or voyager fallback.
  • Use Task with exact subagent_type: reviewer for code-quality-gate after implementation is complete.
  • Use Task with exact subagent_type: qa for reproduce-bug and for verification-gate after APPROVE_CODE; the agent configuration owns model selection.
  • Do not reuse main-agent context for judge decisions, code quality decisions, or verification proof.
  • Apply Durable coordination state when resuming the pipeline and for every dispatch.
  • For an initial handoff, pass authoritative artifact paths plus only the concise framing needed for the next action and its stopping condition. For a repair, resume the original owner with only the failed criterion, relevant evidence, and the delta since its prior attempt. Do not duplicate an owner's procedure or accumulated conversation context.
  • An unexplained owner-delta path outside the declared scope blocks continuation and returns to that owner.
  • Treat judge, code quality, and verification feedback as gates before continuing to the next phase.

Revision Routing

Before any correction, compare the failed criterion with prior findings: what changed, and why would this repair resolve the underlying failure? A rejection is not automatic permission for more code. Reconsider recurring failures before the cap; if no supported repair remains, stop with the evidence and decision needed. Never use exhaustion to waive safety or independent acceptance.

Blocker triage. The pipeline runs unattended; contact the user only when triage ends at step 3. Triage every BLOCKED before acting on it:

  1. Evidence. Does the report show what the owner observed (command output, error, screenshot) and name an owner and an unlock? If it only asserts, or the answer sits in the plan, ticket, or user request, it is a false blocker: re-dispatch once with the missing context as a delta. Example: "no permission to load the plugin" when the request said to test it live.
  2. Authority. Can a pipeline owner or the user's request supply the unlock? Route it there; do not ask the user.
  3. Hard. Would more effort or a different tool change the answer? If not, or the same BLOCKED returns after step 1, it is true: stop and give the user the blocker, the unlock, any partial proof, and your recommendation (for example narrowing scope). Example: App Store review cannot run on a simulator.

One repair dispatch per blocker. This is the "prerequisite bound" referenced above.

  • Missing gather-context-declared intake, cited evidence, or approaches: route repair to gather-context; compact inline research is not a missing report.
  • judge-proposal returns ASK_USER: route pipeline-owned gaps to gather-context within the prerequisite bound; ask the user only for the remaining decision.
  • Missing {ISSUE_DIR}/plan.md: rerun or revise create-issue.
  • judge-plan returns REVISE_PLAN: route notes back to create-issue and request a revised {ISSUE_DIR}/plan.md.
  • judge-plan returns ASK_USER: route pipeline-owned gaps to their artifact owners within the prerequisite bound; ask the user only for the remaining decision.
  • code-quality-gate returns REVISE_CODE or ASK_USER: use step 6's classified routing and unchanged verdict ceiling.
  • verification-gate returns FAIL or BLOCKED: use step 7's classified routing and unchanged verdict ceiling. A blocked gate does not restart itself; its owner may repair the prerequisite within the existing bound before a new dispatch.
  • verification-gate returns PASS but test -f fails on result.md or a cited path: treat as FAIL.
  • User feedback on a verified candidate or open PR that keeps the acceptance criteria: resume Build with only the delta, review that delta, and verify only the changed behavior. Re-plan and re-judge only when acceptance or scope changes. Route a build-only or publish-only request straight to its owning skill.
  • Any unexpected state: stop with the artifact path, expected state, actual state, and owning stage.

Constraints

  • Keep this skill lean: orchestration only.
  • Do not create, edit, append, or repair {ISSUE_DIR}/issue.md, {ISSUE_DIR}/plan.md, or {ISSUE_DIR}/research/*.md directly.
  • Do not write implementation code directly; delegate implementation and repository writes through Task with exact subagent_type: build.
  • Do not create files or saved plans for ad hoc delegation; keep ad hoc delegation in memory/context only.
  • Do not duplicate decision logic from gather-context, create-issue, judge skills, implementation skills, verification skills, or PR workflows.
  • Do not define detailed implementation execution prompts.
  • Do not perform code quality review directly or skip code-quality-gate before verification.
  • Do not run QA directly or define web, mobile-web, iOS, macOS, or non-UI verification flows beyond verification-gate delegation. The wrapper may run test -f on cited verification paths only.
  • Do not define PR creation, review, or merge details beyond create-pr delegation.
  • Prefer artifact handoff over hidden state.
  • Prefer modular delegation over bloating this wrapper.

Output Check

The wrapper checks create-issue output against {ISSUE_DIR}. If create-issue writes the plan artifact anywhere other than {ISSUE_DIR}/plan.md, stop and route that as a create-issue output mismatch.