--- 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, which is also the review run key (see Delivery mode). 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 ` through the runtime-specific packaged review CLI path documented by `review-and-fix`, where `` is `file:` 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, delivery mode, review budgets, any escalation trigger, 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. Carry a `reviewerUnavailable` declaration on the initiative task into `state.md` and every child packet and handoff, so each `ticket-to-pr` run records its delivery under the declared-unavailable rule instead of waiting for a review. - For every implementation unit's diff review, override `ticket-to-pr`'s default invocation with `/review-and-fix

`, 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. Every review call also carries the initiative run options described under Delivery mode. 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. ## Delivery mode Every initiative runs in exactly one delivery mode. The mode is recorded in `state.md` and in the keyed run ledger, and the completion report names it. `base` is the default and runs the full review. `lite` runs only when the user explicitly asks for it: never select it automatically, never infer it from size or effort, and never downgrade a base run to lite. Pass the run key to EVERY `review-and-fix` call of the initiative, file-target note reviews and diff reviews alike, together with its project-scoped state directory, budgets and mode: `--initiative-run-key --initiative-state-dir --initiative-max-launches --initiative-max-rounds --initiative-mode `. Size the budgets for the mode before the first launch, record them in `state.md`, and pass the same values on every later call. A review call without the run key is outside the plan. A target that blocks mid-round on `budget-exhausted` stays bound to the exhausted key; the driver stops there and reports it, never changing the run key itself. After reconciliation, add a new key to the source index, record it in `state.md`, and run `carry --from-run-key ` with the new key's initiative options through the runtime-specific packaged review CLI path documented by `review-and-fix` before resuming; the resumed round reuses its completed artifacts and charges the new key only for what it launches itself. Never use `carry` to refresh context or abandon a run that is not genuinely budget-blocked. Lite is eligible only when all of these hold: one repository and one independently testable outcome (`cross-repository` and `multi-outcome` name the two ways this fails); a settled contract (`unsettled-contract`); no public API or deployment-boundary change (`public-api`); no security, authorization, identity, or cryptography change (`security`); no data migration (`migration`); no legal, regulatory, or external-data-rights decision (`legal`); no cross-repository integration (`cross-repository`, the same trigger as the single-repository condition above). Lite replaces the broad gate pair and the gate panel with one design-conformance gate. It keeps the red-to-green evidence, the recorded review revision pair, and the clean confirmation, and it skips the rest of the broad review, including `ac-coverage` detection. Check eligibility once the contract is settled and before any dependent implementation. A lite request that meets an exclusion condition is escalated to base before that implementation: call `escalate ` through the runtime-specific packaged review CLI path documented by `review-and-fix`, with the base budgets, where `` is the matching one of `public-api` (public API or deployment boundary), `schema`, `security` (security, authorization, identity, or cryptography), `legal` (legal, regulatory, or external-data-rights decision), `cross-package`, `cross-repository` (more than one repository, or cross-repository integration), `multi-outcome` (more than one independently testable outcome), `unsettled-contract` (the contract is not yet settled), or `migration`. Record the trigger and the exclusion in your own words in the handoff and in `state.md`. After `escalate`, replace the mode and budgets recorded in `state.md` with base and the base budgets, and pass those on every later call: the ledger now holds them and refuses the lite mode and budgets. Escalation is refused after the first launch and never reverses. When non-local scope surfaces after a lite review has launched, park the dependent work, report it for reconciliation, and continue only after reconciliation on a new base run key and a separate target review state directory: retain the old target ledger as evidence, add the key to the source index, and re-run the review from stage 3. A bound target refuses a different run key or initiative state directory. In the separate target directory, start each ref normally when no ledger exists; use `rerun` only when that directory already contains the matching binding. A confirmed contract or architecture finding parks dependent work for reconciliation. Stop dependent automatic fixing and implementation for that unit, launch no further fixer for it, write the finding into a substantive reconciliation packet in the handoff, and return to the user. Independent units may continue. A confirmed finding is never turned into another local review fix. Launch only the reviewers the plan names, each after its reservation. Never launch a reviewer outside the plan, and never launch one under a new task name to look again. The run charges only reserved launches and accepts evidence only from them. The host can still spawn agents that this skill and the CLI cannot prevent; the contract is that such an agent is kept from producing accepted evidence: its output is never written into a round artifact, unreserved evidence is rejected, and the keyed run fails closed. Record any launch outside the plan in the handoff. When every unit has its disposition and the completion report is persisted, acknowledge each delivered disposition with `consume ` and end the run with `finalise`, through the same CLI path. ## Initiative reconciliation decisions Before the initiative's first reserved reviewer, register the approved source index's complete dependency graph with `initiative-plan ` through the runtime-specific packaged review CLI documented by `review-and-fix` and the original initiative flags. The JSON is `{"version":2,"repositories":{"api":"","web":""},"targets":[{"repository":"api","ref":"feature/A","dependsOn":[]},{"repository":"web","ref":"feature/A","dependsOn":["api:feature/A"]}]}`: declare every repository of the initiative, a single repository included, by a name (letters, digits, `.`, `_`, `-`) mapped to the absolute path of one of its checkouts; include every file/diff review target under its repository; name each dependency `:`. The run stores each repository's Git identity, so every worktree of a declared repository joins the one run, budget and dependency graph, equal refs in two repositories stay distinct targets, and a review from any undeclared repository is refused. Each repository keeps its own target review state directory; only the initiative state directory is shared. The run fixes this plan before launches. Never declare independence or replace a key to bypass a pending decision. With no registered plan the conservative run-wide stop remains; missing or unknown dependencies remain blocked. With a plan, only known independent targets continue while a target or its transitive dependents are held, using the same remaining budget. For a pending unchanged-contract decision, show the exact recorded target and delivery claim, obtain the user's decision, then use `reconcile --claim --by --decision --contract unchanged` with the original initiative flags. Record only direct human authorization, never an agent's invented acceptance. This retires one occurrence and preserves budgets, refunds and history; it neither dismisses findings nor approves a changed contract. A changed contract uses the existing human-authorized new-run procedure. Preserve other pending holds and resume from the ledger; a later round can create a new claim at the same head, and an older decision cannot clear it. ## 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. Do not ask a redundant binary question for an obvious mechanical or symmetric correction within an already user-approved bounded batch after independent verification. Return to the user for reconciliation when a real scope, contract, safety, provider, or lifecycle tradeoff arises, when independent verification identifies a new substantive batch, or when authorization outside the recorded envelope, an irreconcilable review finding, or a blocked exit condition appears. Do not ask again for authority already granted. ## Ticket set One coherent approved ticket outcome is the default implementation unit; keep its atomic changes together. Split only at an explicit independently deployable or revertible boundary, when a prerequisite must merge first, at a multi-repository delivery boundary, or for an ownership split justified in the approved plan. A frontend/backend label alone or arbitrary size does not justify a split. A separate independently acceptable outcome is a separate ticket. For every approved unit, record `{outcome, acceptanceCriteria, repo, base, dependencyRefs, boundaryReason}` before implementation, plus its owner, branch, PR URL, exact package or deployment version when applicable, checks actually run, and hand-off. The default unit's boundary reason records that the coherent ticket outcome stays together. Record one outcome-level acceptance check and its owner. Use one outcome 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. At checkpoint 2, approve the exact unit set and reasons. If a proposed unit contains unrelated outcomes or its boundary has no permitted reason, stop with `unit-boundary-unsettled` and return to planning; do not fragment it by size. Record dependencies explicitly and execute them in order. Report every PR with its boundary reason and dependency references. 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-and-fix

` 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 ` through the runtime-specific packaged review CLI path documented by `review-and-fix`, even if the head is unchanged, rerun the full stage 3 review cycle against the exact local head and integrated base as a new revision pair charged to the same run budget, stopping for human reconciliation instead if the run is parked, including `/review-and-fix

` 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=:`, 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 except for the separate Deep specialist and any independent reviewer required by the architecture decision gate. Otherwise delegate only when isolated context, independent work, or specialist judgment saves time or protects review independence. Keep dependent mutations sequential. An implementation child runs only through the next review boundary: after committing the stage-3 design note, or after completing the stage-6 implementation and its focused checks, it writes the execution packet in `handoff-contract.md` and returns `AWAITING_REVIEW`. It must not invoke either review gate, push, or create a PR. This is an intermediate disposition, not completion or a blocked gate. The orchestrator reads back the artifacts and starts one fresh review driver for that target; the driver runs the unchanged `review-and-fix` contract and its reviewer/fixer workers. Build its packet from the approved contract and source evidence, excluding the implementer's conversation and reasoning. After design review passes, resume implementation in a fresh context with the approved note, ticket and execution evidence. After diff review passes, complete the remaining ticket gates and final mutations sequentially. Keep a review driver's lifetime to one target. Evaluate the session handoff policy below at completed round boundaries, and for an implementation worker at completed coherent batches. Persist the exact next CLI step, target/base/head, artifact paths, completed worker identities and unchanged initiative options before replacing context. Do not restart a round, duplicate a live worker, reset a ledger, or allocate a new run key to refresh context. Raw logs stay in files; return a short verdict and artifact paths. ## Completion report Report the delivery mode (and the escalation trigger when the run escalated), the review run key and budget use, the approved ticket set, ticket-to-PR result for each implementation unit, exact PR URLs and heads, each PR's delivery disposition (`mergeable-clean`, `mergeable-with-follow-ups` with its follow-up ticket URLs, `mergeable-without-review` with the statement that no automated review ran, or `blocked` with its reasons), 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. The review run's own machine-readable report is rendered by `finalise` into the initiative state directory as `initiative-report-/report.json` and `report.md`, with a project-level index `initiative-reports.jsonl`; cite its path instead of copying its figures, and note that a run that never finalised has no report. ## Session handoff policy Accept `--session-handoff off|suggest|stop-at-checkpoint` on the initiative invocation; default to `suggest`. Record this policy in `state.md` and every child packet and handoff, including review drivers. It is independent of delivery mode and review budgets. `off` disables efficiency checkpoints; `suggest` offers a saved continuation prompt while allowing work to continue; `stop-at-checkpoint` ends the current context after a verified safe handoff. A stopped worker returns to its orchestrator; only an orchestrator stop ends the user's main session. Do not create a chat automatically or claim that the CLI terminates a host process. At each completed stage, implementation batch or review round, evaluate input context (only when exposed by the host), tool calls in this context, and consecutive tool calls without meaningful progress. New verified evidence, a resolved decision, a committed change or a completed gate resets the no-progress count; repeated polling or rereading unchanged material does not. Initial triggers are 128,000 input tokens, 50 tool calls, or 10 consecutive calls without meaningful progress. They are heuristics, not dollar limits. Cumulative cache reads are not input context. When measurements are unavailable, record them as unmeasured; never invent token usage. Follow the checkpoint protocol in `handoff-contract.md` using the existing review run key and unchanged initiative options. At a trigger, drain owned children and finish the safe boundary before handing off; do not start another batch or round while a stop is pending. For `suggest`, present each distinct trigger once per context, with the saved prompt and checkpoint paths, and continue unless the user selects a fresh context. For `stop-at-checkpoint`, read back the saved prompt and checkpoint, present the prompt as a copyable continuation with its paths, and return immediately. Resume from those artifacts in a fresh context, verifying source hashes, authoritative versions, head/base, blockers and remaining live budgets first. Session replacement never overrides terminal dispositions, reconciliation or budget exhaustion. ## Review feedback Use one durable project-level feedback directory per repository identity, outside tracked files and shared across this project's initiative runs. Record its absolute path as `feedbackStateDir` in the project index and `state.md`; propagate it with the resolved review CLI path in child packets. A worktree shares its repository's store. Keep each repository's feedback separate for multi-repository work. Missing durable storage or a feedback error is reported as unavailable feedback, never a reason to bypass a delivery gate or invent lessons. Follow the feedback protocol in `handoff-contract.md`. Before proposing the contract, writing a ticket or committing a design, select at most three accepted lessons matching that stage and the traced affected surfaces. Derive applicability tags from the actual work; do not retrieve the whole store or create tags merely to force a match. Record selected IDs and how each was applied or why current authoritative sources make it inapplicable. Lessons suggest questions and checks; they cannot add scope, settle a product decision or override approved requirements. After a target reaches a terminal or blocked disposition, use its existing ledger and verified evidence to propose at most three useful cause-based lessons, without another reviewer launch or round solely for feedback. Distinguish requirements/design omissions, implementation errors, verification gaps, review noise and environment failures. Ask whether the earlier stage could have known and prevented the issue from the evidence available then. High round counts alone do not establish weak design. Collect unresolved or killed findings only as non-promotable observations; do not label them verified defects. Accepted rules need confirmed fixed findings from two distinct runs and review attempts, plus an explicit attributed evidence review. Never automatically edit common skills or approved tickets/designs to incorporate a candidate. At delivery completion or a blocked handoff, record reported recurrence outcomes for lessons actually applied to that unit, with the existing review evidence. A missing measurement is `unmeasured`; no observed recurrence after a clean review is not proof of absence. Include the bounded feedback report and its measurement limits alongside the existing round/cost report. A feedback failure preserves the review and delivery results and is reported separately. Reusing or replacing a context never creates a second occurrence or exposure for the same run/unit. ## Approved contract for diff review The stage-3 design note includes the approved acceptance criteria and contract, and its reviewed fixes are committed before stage 7. Record the reviewed note's repository-relative path and content digest in the handoff. Before the diff review, verify that the committed note still represents the approved contract; a material contract change returns to the design checkpoint and note review before dependent implementation or review continues. Start the unit's diff review with `--intent-path ` through `review-and-fix`. The CLI uses an existing project-configured intent command first. Otherwise it reads the regular Git blob from the exact reviewed head, never the working tree or agent prose, and records the source commit/blob, hash and byte count. Do not write review.config.json merely to inject a contract, and do not substitute `--intent-file` for this workflow. The latter remains a separate explicit-input interface for other callers. Carry the selector unchanged on resume and cite the actual selected source in the handoff. An unchanged note may have a new commit identity; changed contract bytes stop against the pinned cache rather than being silently adopted. Preserve that evidence and use the applicable contract-reconciliation and fresh-attempt procedure before adopting an approved revision. A file-target note review does not use `--intent-path`. A stage-7 review must report `intent: applied`; missing or invalid committed intent is a named stop, not permission to run without the contract.