A spec issue with tickets under it becomes a stack of PRs — one PR per ticket — implemented end to end by a dynamic workflow of subagents. The tickets are not a list of steps: they are a task graph with blocking relationships, so there is always a frontier of tickets ready to be grabbed, and the run schedules against that frontier rather than marching through phases. The stack exists so the operator reviews one small ticket-sized diff at a time, then merges the whole stack in one operation.

Your context is the scarce resource here. The spec body, the ticket bodies, the research, the diffs and the review findings all stay inside the workflow; you hold the issue number, fourteen interpolated values, and the summary that comes back. Read no ticket body beyond the ## Validation sections step 2 names, open no source file, and run no search — a discovery agent inside the workflow does that, and it does it better with a fresh window than you do with a full one.

workflow.template.js, beside this file, is the script. It carries every step; you render it and launch it.

Requires a runner for a script of agent() calls — either the Workflow runner, a harness's workflow primitive (Claude Code's Workflow tool, or an equivalent), or the session runner (formerly the Orca runner; ADR-0011, ADR-0017), which needs Node and crew installed: the runner is the crew package's (npm install -g @javrasya/crew, or from a checkout of javrasya/crew npm install -g <crew checkout>), and it runs every agent as a live session on a session host — crew itself, the default, or Orca, which additionally needs a session inside an Orca terminal whose runtime is ready (the crew runner reference). The script is plain JavaScript against four hooks: agent(), parallel(), phase(), log(), and is the same under both but for one rendered value, RUNNER (step 2). Native stack registration additionally requires the gh-stack extension — gated below, never auto-installed.

Steps

The stack gate. Two probes, two different outcomes — run them before touching anything else:
- gh extension list | grep -q gh-stack — missing → stop. Tell the user to run gh extension install github/gh-stack and wait. Install it yourself only if the user explicitly says to.
- gh api "repos/<owner>/<repo>/stacks" --silent — 404 → stacks are not enabled for this repo (org rollout policy, or a host without the preview; installing nothing fixes it). Put it to the user: GitHub's native stacked PRs give a stack map on every PR and a one-click atomic whole-stack merge — enabling is described at https://docs.github.com/en/pull-requests/tutorials/roll-out-stacked-prs — or the run can degrade to a plain --base chain merged bottom-up by hand. Their call, never a silent fallback. HTTP 200 (even with []) → native mode.
The runner. Asked alongside the stack gate, from two probes:

implement-spec-in-workflow

Steps