---
name: initiative-to-prs
description: >-
  Use when a product brief, problem report, strategic objective, or set of incomplete tickets must be
  investigated, turned into one or more implementation-ready tickets, and driven through verified PRs.
  Do NOT use when one ticket is already implementation-ready; use ticket-to-pr instead. Do NOT use for
  ticket drafting without implementation; use ticket-writing instead.
---

# Initiative to PRs

Turn an initiative into the smallest implementation-ready ticket set, then carry every ticket through Concord's existing delivery contracts. An initiative is a coordinated body of work, not a required tracker issue type.

## Contract

The explicit request to take an initiative to PRs authorizes the ordinary mutations needed by this pipeline at its checkpoints. Checkpoint 1 authorizes creation or update of the approved tickets and any specifically approved design record. Checkpoint 2 authorizes implementation mutations: unambiguous in-progress and review transitions, branches and worktrees, commits and pushes, and PR creation. Follow narrower repository or provider rules when they exist. Closing or superseding tickets still requires explicit approval.

The pipeline ends with one or more verified PR URLs, or with evidence that no code change is required. Never merge, release, or deploy to production. A blocked gate remains blocked; do not turn it into a PR-body caveat.

## Bootstrap

1. Read the applicable project instructions and discover the authoritative brief, tracker, repositories, documentation system, target branches, validation commands, and available agent mechanisms. Infer these from the workspace when one answer is clear. Ask only when multiple plausible destinations or materially different interpretations remain.
2. Maintain a project-scoped index that maps each immutable source URL or tracker identifier, and otherwise a normalized objective fingerprint, to one stable run key. Search the index before creating a key; add a new mapping only when no match or supplied handoff exists. Locate or create a separate directory for that key under project-scoped Concord state. On every reuse, reread each authoritative source and compare its provider version or content digest with the source version persisted in the latest handoff. Also compare the current initiative objective and authorization envelope with the persisted values. Treat a source-version change or an objective or authorization difference as an invalidation: invalidate the affected contract, approvals, tickets, execution evidence, and terminal dispositions; re-arm every affected file-target and diff review ledger by invoking `rerun <ref>` through the runtime-specific packaged review CLI path documented by `review-until-green`, where `<ref>` is `file:<path>` for a file target; then restart at stage 1 before trusting saved state. If the objective or authorization envelope differs, require reconciliation before any mutation. Before each mutation-capable stage and completion, recheck every authoritative source version against the persisted versions; detected drift follows the same invalidation and reconciliation path. When the harness exposes no state root, use the active runtime's durable user-state root with a deterministic project fingerprint and run key; if no durable user-state root is available, stop and require a supplied durable handoff directory. Do not use an operating-system temporary directory for resumable state. Never reuse one run directory for another key. Keep `state.md` there with the run key, initiative, authoritative source identities and versions, current stage, artifact paths, ticket and PR URLs, decisions, authorization envelope, requested and resolved models, exit verdicts, and blockers. Never record secrets or customer-identifying data.
3. Read [references/stages.md](references/stages.md), [references/model-routing.md](references/model-routing.md), and [references/handoff-contract.md](references/handoff-contract.md). Execute one dependency-ready stage at a time and persist its handoff before advancing.

## Composition

- Apply `ticket-writing` to create or repair each ticket. Do not reproduce its ticket schema or weaken its grounding and read-back requirements.
- Apply `ticket-to-pr` independently to each implementation-ready ticket, or to each repository implementation unit under an approved multi-repository outcome ticket. Preserve one repository, one branch, and one PR per execution unit and every applicable red, design, review, green, documentation, and PR exit condition.
- For every implementation unit's diff review, override `ticket-to-pr`'s default invocation with `/review-until-green <branch> <target-base>`, using the target base recorded in the execution handoff. For ordinary units, fetch the target remote and resolve the base to an immutable fetched commit SHA. For stacked units, use the immutable fetched prerequisite head SHA. Pass and record that SHA explicitly on every diff-review run so the gate covers only that PR's diff. When an independent reviewer role is authorized, give that reviewer the contract and evidence packet separately; it must not inherit the implementer's reasoning context.

If any required Concord skill or command is unavailable, stop at the current stage and report the missing dependency instead of approximating its contract.

## Human checkpoints

There are two mandatory human checkpoints:

1. After the read-only evidence and contract stage, present the observed reality, material decisions, proposed contract, and proposed ticket set. Continue only with the user's exact decisions and ticket-set approval.
2. After the approved tickets and external design records have been written and read back, present their URLs, dependency order, acceptance criteria, Definition of Done, and preserved metadata. For repository-backed design records, present the assigned ticket and repository unit, planned branch, and PR disposition; read those records back with that unit's implementation PR. Continue to implementation only when the user approves the read-back ticket set.

After the second checkpoint, proceed through PR creation without routine pauses. Return to the user only when a new material product decision, scope expansion, authorization outside the recorded envelope, irreconcilable review finding, or blocked exit condition appears. Do not ask again for authority already granted.

## Ticket set

Prefer one ticket for one independently testable user-visible outcome. A repository boundary requires a separate implementation unit and PR, not automatically another outcome ticket. Use one ticket with multiple repository units only when the repositories are necessary for the same acceptance criteria, one owner can verify the combined result, and the tracker can retain an ordered implementation record. For each unit, record the repository, owner, branch, PR URL, dependency, exact package or deployment version when applicable, checks actually run, and hand-off. Record one outcome-level acceptance check and its owner. Create a separate ticket for an independently acceptable outcome, or when distinct owners or release lifecycles need independent tracker status. Use a tracker subtask only when it provides that status; otherwise keep the units as a checklist on the outcome ticket. Record dependencies explicitly and execute them in order. Parallel execution is allowed only when units use independent branches and worktrees, share no mutable state, and neither one's contract can change the other.

When a downstream ticket in the same repository depends on an unmerged prerequisite PR, use an explicit stacked delivery: branch from the prerequisite PR head and target the downstream PR at the prerequisite branch. For every downstream diff review, override `ticket-to-pr`'s default invocation with `/review-until-green <downstream-branch> <fetched-prerequisite-head-sha>` so the review covers only the downstream PR diff. A verified stacked PR is a completion disposition when its handoff and PR body record the prerequisite branch, normal base, and named owner for the follow-up. After the prerequisite merges, that owner fetches the live downstream PR head and integrated base. Before checking out or resetting the local downstream branch, require a clean worktree and no unpushed commits; otherwise stop and reconcile the local work. Check out the branch and reset it to the exact fetched PR head. Before retargeting or restacking, rerun the discriminating acceptance check against the exact fetched integrated base. If that check is no longer red, return through the approved `NO PR NEEDED` or contract-reconciliation path. Integrate the exact fetched integrated base into the local downstream branch according to repository policy; if that policy forbids integration, leave the ticket `BLOCKED`. Check the three-dot diff against the integrated base. If prerequisite commits remain in that diff, as can happen after a squash or rebase merge, the owner restacks only the downstream changes locally onto the integrated base. Re-arm the clean review ledger by invoking `rerun <downstream-branch>` through the runtime-specific packaged review CLI path documented by `review-until-green`, even if the head is unchanged, rerun the full stage 3 review cycle against the exact local head and integrated base, including `/review-until-green <downstream-branch> <fetched-integrated-base-sha>` and every required independent review, and rerun required checks against that base. Only after those reviews and checks pass does the owner update the remote. If the branch was restacked, push with `--force-with-lease=<remote-ref>:<fetched-head-sha>`, using the fetched head SHA as the expected value, only when repository policy authorizes history rewriting; otherwise leave the ticket `BLOCKED`. Without a restack, push normally. Retarget the PR to the integrated base, wait for required checks on that exact remote head, and read back the final head SHA, resolved base SHA, diff, and check results. Compare the final head and resolved base SHA with the recorded review pair. If either drifted, restart this follow-up by fetching the live downstream PR head and integrated base, repeating the clean-worktree and no-unpushed-commits guard, resetting the local branch to the fetched head, and rerunning the discriminating acceptance check before integration and the full stage 3 review cycle. This follow-up is outside initiative completion because this pipeline does not merge PRs. If repository or provider rules do not permit that stack, keep the downstream ticket blocked until the prerequisite is integrated.

## Delegation

Keep the main agent on orchestration, decisions, state, and concise user briefings. Route evidence gathering, implementation, independent review, and final mutations according to `model-routing.md`. Give each child only the applicable project root, stage instructions, previous handoff, exact user decisions, and authorization envelope. For independent review, omit the implementer's handoff and build the packet directly from the approved contract, source evidence, exact reviewed head and base, verification commands, and authorization envelope. Never pass the full conversation.

Model assignment is a plan, not an obligation to spawn. Delegate only when isolated context, independent work, or specialist judgment saves time or protects review independence. Keep dependent mutations sequential.

## Completion report

Report the approved ticket set, ticket-to-PR result for each implementation unit, exact PR URLs and heads, checks actually run, tracker and design-document read-backs, blocked or no-change outcomes, and remaining risks. For a multi-repository outcome, name the integration owner, exact artifact versions, outcome-level verification status, and the gate that remains before `READY FOR TEST`. Distinguish PR creation from merge, release, deployment, QA acceptance, and customer availability.