# Epic To Prs > Explicit-invocation epic loop, fired only by name or direct command; never self-select it. Works an epic or milestone most-important-first through issue-to-pr to merge-ready PRs. Owns the live queue, persistent goal, unblocker, and shared GPT-6 Astra Pro planning, meaningful batch checkpoints, major-blocker consultations, and final stack review. Astra and Fable coordinators use delegated-implementation: workers code, test, and repair; the parent owns direct review of every deliverable and all skill authorship. Preserve accepted scope and honest receipts; continue independent work around blockers. Never merge or release. Not for status reads, decomposition via arch-epic, or open-ended optimization. - Skill: `aelaguiz/epic-to-prs` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add aelaguiz/epic-to-prs` - Raw SKILL.md: https://api.skillmd.com/api/skills/aelaguiz/epic-to-prs/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: aelaguiz (https://skillmd.com/u/aelaguiz) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/aelaguiz/epic-to-prs --- # Epic To PRs Use only when the user explicitly invokes this lane by name or directly commands this exact job: work a named epic or milestone through its issues to Pro-reviewed, merge-ready PRs. Touching an epic during other work does not authorize this loop. Deliver the epic's accepted scope most important first. Use `issue-to-pr` for implementation and PR delivery, with shared Pro planning and review across related issues. Keep delivering until the queue and required reviews are complete, the user stops the run, or no useful unblocked work remains. For an Astra or Fable coordinator, apply `$delegated-implementation` across the epic. Workers implement, test, and repair; the parent owns decisions, integration, and direct review of every deliverable and changed code line. All skill authorship stays with the parent, including skill work inside a child issue. ## Install ```bash git clone git@github.com:aelaguiz/arch_skill.git cd arch_skill make install ``` ## When to use - "epic-to-prs on ", optionally with a Pro thread. - A /goal ask that directly commands this delivery loop over a named epic. - "Put a goal loop over epic and work it down." Status reads do not trigger execution. If child issues do not exist, decomposition belongs to `arch-epic` or ordinary planning. Open-ended work without an issue queue belongs to native goal mode. ## Queue and delivery contract - Use live GitHub state. Re-read the epic between issues; skip work that closed or changed owner. Follow stated priorities, otherwise use user impact and unblocking value and record the reasoning briefly. - Preserve the user's accepted scope. Agents, reviewers, and bots cannot expand it or quietly deliver less. Decide routine ordering, dependencies, and scope interpretation locally with `$startup-pragmatism`. - The run starts authorized for in-scope work. The armed `$unblocker` resolves self-imposed approval gates and real blockers from intent. Pro consultation follows the cadence below; user authority, access, or a change to the ask goes to the user once with a recommendation. - Run each issue through `issue-to-pr`, carrying the shared review scope. Code must be self-documenting with clear comments at boundaries and role seams. Handle bots with judgment; they are advisory. Never merge, release, apply approval labels, or touch production surfaces. - Track locally ready PRs separately from merge-ready PRs awaiting only the user's merge. A locally ready child may wait for a shared final review while the next independent issue proceeds. Do not close issues or imply they are merged merely because their PRs are ready. ## Shared Pro cadence Begin with one epic planning consultation covering the goal, queue, implementation approach, dependencies, and verification. Reuse relevant existing Pro planning when it still covers the accepted scope. Child plans remain on disk but do not each require another planning consultation. Use Pro again for final review of the completed PR stack against the epic's goal, including interactions between PRs. A small coherent epic may need only initial planning and final review. For larger work, choose meaningful batches or milestones that Pro can credibly assess. A checkpoint after two related issues can be useful when their combined result exposes integration or direction worth reviewing; there is no fixed issue count or mandatory boundary check. Explain briefly what this checkpoint will resolve. A batch checkpoint that reviews finished PRs can satisfy their final review; a planning or status-only checkpoint cannot. Final epic review should focus on the remaining changes and overall integration, using prior batch reviews as context instead of repeating every completed child review. Review early when a batch needs to be merge-ready before the rest of the epic. Between these consultations, the coordinator reasons through architecture, plan refinements, ordering, and scope; workers implement and repair code under the execution contract. Consult Pro for a major unexpected blocker or consequential technical uncertainty that remains beyond the agent's reasoning after reasonable local investigation and is likely to change the approach. An issue boundary, dependency discovery, or ordinary uncertainty alone does not justify a check-in. Never serialize independently buildable issues behind an unrelated blocker. Batch accepted Pro findings. Workers repair code and run affected checks; the coordinator personally reviews the changes and evidence and repairs skill content itself. Do not run an automatic resubmission loop to obtain Pro approval of every edit. Seek another consultation for substantial redesign, unresolved consequential disagreement, or a repair that changes the basis of the review and needs independent judgment. The normal cadence is a baseline, not a hard cap. Have expected edits and relevant checks finished before final review where practical; honor an explicit request for Pro and CI in parallel. Assess post-review changes by their effect on behavior, integration, and review conclusions. A new SHA alone does not invalidate useful review. Consolidate any warranted recheck, and record which revisions Pro actually saw plus later local repairs and verification. ## Pro thread and receipts Use one GPT-6 Astra Pro thread for the epic, supplied by the user or created in the applicable ChatGPT project. Keep the epic's consultations in that thread. `$chatgpt-web` owns browser mechanics and requires reading and applying `$browseros` before BrowserOS calls. Select GPT-6 Astra's literal `Pro` option with Extended thinking in ChatGPT's `Chat` surface. Extra High, xhigh, Ultra, Thinking, and the highest remaining setting are not Pro. Apply `$prompt-authoring` to every submission. Give Pro the user's intent, accepted scope, relevant artifacts, queue and progress, believed critical path, and the consequential questions. It should judge progress and work against the goal, with enough context to catch drift and integration problems. Keep one short existing-worklog entry per actual submission: purpose, artifacts/revisions and thread, and running count. Count retries and failover submissions; response polling is not another consultation. If Pro is missing or disabled, treat it as a probable temporary account rate limit; an explicit cap triggers the same switch. Follow `$chatgpt-web` and `$browseros` to find an available account among the already-open `Work` and variable number of Pro profiles. Note which profile/window works and use it. All should have the same projects. Continue in the same-named project with the epic context restated. Record continuation thread URLs and reuse the original when available. Only after available accounts are exhausted, report their observed conditions and the blocked Pro decision. Continue independent authorized work. Pause the whole run only when no useful independent work remains, and wait for the user to say Pro is back. Never substitute another model for a required Pro review or count it as passed. ## Workflow 1. **Adopt and plan.** Read the epic, live issues, supplied Pro thread, and existing plans. Establish acceptance and the initial order. Write the plan, apply `$startup-pragmatism`, and obtain or reuse shared Pro planning. Identify useful reviewable batches where the work calls for them. 2. **Arm the run.** Stand up `$unblocker` with the user's ask, scope, production boundary, and this Pro cadence. Author the goal prompt with `$prompt-authoring`, including the thread, unblocker contact, queue, shared review scope, execution responsibilities including parent-owned skill authorship, and completion condition. Arm the goal and unblocker using the active harness's supported mechanisms. Carry user-directed cadence changes into the goal, charter, and active dispatch briefs during a run. 3. **Deliver issues.** Refresh the queue and run dependency-ready `issue-to-pr` work with inherited planning, review coverage, and execution responsibilities. Parallelize independent scopes when useful; keep shared design decisions and overlapping work coordinated. Personally review every deliverable and changed code line, including worker-delivered issues. Collect locally ready PRs without duplicate child Pro submissions. Resolve routine decisions locally or through the unblocker, use meaningful batch checkpoints and major-blocker consultations when warranted, and continue independent scope while any real user question pends. Ask once; continuations do not supply an answer or justify repeated questions. 4. **Review and finish.** Obtain final Pro review of the completed stack, using batch reviews as coverage where applicable. Resolve material findings through the same execution contract and personally review fixes. Every delivered issue needs the coordinator's direct review, Pro planning and final review coverage, and passing required checks before merge-ready. Do not mark the goal complete merely because all issues were dispatched; pending reviews and unresolved scope remain unfinished work. 5. **Report.** List delivered issues and PRs, current heads and CI, Pro review coverage and reviewed revisions, later local repairs, and the submission count. Name any unresolved blocker or user escalation and preserve the remaining queue for continuation. Complete the goal only when its accepted work is merge-ready or the user explicitly removed it from scope; otherwise report the precise incomplete state. ## Delegation For Astra and Fable coordinators, `$delegated-implementation` owns worker selection, requirements briefs, direct review, and code repair. The originating coordinator retains every deliverable's acceptance and all skill authorship when assigning issues to workers; an issue handoff does not replace it with another executive. For other dispatches, read the installed `../_shared/agent-orchestration-policy.md` and apply `$prompt-authoring` to the populated brief. Leave spawning mechanics to the active harness. Include accepted scope, boundary comments, unblocker contact, shared planning and review coverage, and the expected handoff. The coordinator owns Pro submissions and the submission count; children return artifacts and consequential questions without launching duplicate consultations. ## References - [references/epic-dispatch-evidence.md](references/epic-dispatch-evidence.md): historical epic prompts and owner corrections for maintainers.