implement-tickets

name	implement-tickets
description	Coordinate implementation of a normalized ticket set — builds the dependency DAG, groups same-file tickets, dispatches each group to a sub-agent with a fresh context, runs a judge LLM against acceptance criteria, and commits one commit per ticket. Use when a batch of tickets should be implemented in parallel/sequential order with per-ticket commits and an end-of-run report. Do not use for a single ticket (implement it directly), tickets not yet generated (use spec-to-tickets first), or non-ticket work.
license	MIT

Implement Tickets

Coordinates the implementation of a group of tickets produced by spec-to-tickets (or any source that has been converted to the normalized ticket format). The skill reads the ticket set, builds the dependency DAG, batches parallelizable work, dispatches each batch to fresh-context sub-agents, runs a judge review against each ticket's acceptance criteria, commits one commit per ticket, and writes an end-of-run report. Live updates use a fixed category prefix vocabulary so progress, errors, deviations, and escalations are scannable in real time.

When to Use

• The user has a set of tickets in the normalized format and wants them implemented end-to-end
• The user asks to "run the ticket implementer", "implement the tickets in tickets/", or "execute the spec-to-tickets output"
• The user wants parallel work across independent tickets, with a per-ticket commit history on one branch
• The user explicitly opts into the local implement-tickets skill over any globally-installed version
• When user input would clarify the request (workspace choice, circuit-breaker threshold override, partial-ticket set selection, attribution policy), invoke ask-questions

When Not to Use

• Tickets have not been generated yet — use spec-to-tickets first to produce the normalized ticket set
• The work is a single ticket — implement it directly with a single agent session; the coordination overhead is not justified
• The user wants to implement one specific ticket by id — dispatch it directly, do not run the full skill
• The source is an issue tracker that has not been converted to the normalized format — run the source adapter first, then invoke this skill
• The work is non-ticket work (e.g., ad-hoc refactor, exploration, single-PR change)

Workflow

The skill runs in six steps. Each step has explicit completion criteria; the next step does not start until the current one reports a stable state.

Step 1 — Mode and workspace resolution

1. Parse the user's natural language input for mode signals:
   • Phrases like "self-contained", "just do it", "no pausing", or "don't ask me" indicate Self-Contained mode.
   • Absence of any signal, or phrases like "check with me", "ask first", "let me confirm", indicates Collaborative mode (default).
2. Record the mode. All subsequent steps branch on this value only at user-facing decision points (Step 3 escalations, Step 6 report acknowledgement).
3. Resolve the workspace:
   • Default: create a new branch named tickets/impl-<run-id> from the current HEAD. Record the branch name; all work stays in this branch unless the user specifies otherwise.
   • Override: if the user specifies a worktree path, branch name, or "use a worktree", initialize a worktree at the resolved path. Record the worktree path.
4. Capture the circuit-breaker threshold override (default = 3 strikes); if the user does not specify, the default applies.
5. Capture the attribution policy ∈ {human-only, human+ai-coauthor, ai-only}.
   • Parse the user's input for an explicit policy signal. Accepted phrasings: "as me", "as me with the bot as co-author", "as the bot with me as co-author", "as the bot", or a literal policy name.
   • If the policy is not stated, invoke ask-questions with one question and three options: ai-only, human-only, human+ai-coauthor. The recommended default is human-only (lowest surprise, matches the default shell git config in most setups). Ask even in Self-Contained mode — identity is an irreversible, audit-visible decision.
   • Record the chosen policy before printing the mode banner. The skill does not advance to Step 2 without a recorded policy.

Before asking the user for the AI identity in sub-step 6, load references/commit-author-policy.md to surface canonical bot identities per host platform.

6. If the recorded policy is human+ai-coauthor or ai-only:

   1. Ask the user for the AI name and email. The user may copy from references/commit-author-policy.md or supply their own. The skill does not propose a default value, does not invent a handle, and does not read the host's CLI version or env vars to auto-fill.
   2. Record the AI name and email as captured strings, verbatim from the user's reply. Trimming whitespace only.
   3. If the user has not provided a name and email, refuse to proceed: emit [DEVIATION] step=1.sub-step-6 reason=ai-identity-required policy=<recorded> and abort the run. The skill does not advance to Step 2.
   4. For human-only, skip this sub-step. The shell's git config user.name / user.email is the implicit human identity; if the shell has none, the eventual git commit fails with git's own error and the failure routes through Step 4.

7. Print a one-line mode banner in this exact shape:

   [OK] mode=<Collaborative|Self-Contained> workspace=<branch-or-worktree> breaker=<n> attribution=<policy>

   If the policy is human+ai-coauthor or ai-only, append a single space and ai=<name> <email> to the banner.

Completion criterion: mode recorded, workspace initialized and clean, breaker threshold recorded, attribution policy recorded, AI identity recorded (if policy involves AI), mode banner printed.

Step 2 — Ticket loading and dependency graph

1. Resolve the ticket source:
   • Default: load markdown files from tickets/ matching the normalized ticket format (frontmatter with id, title, status, Depends on:, Acceptance criteria).
   • If the user provides a path or glob, load from that location.
   • If the user names an external source (e.g., "GitHub Issues in repo X"), abort with a clear message: "External sources must be converted to the normalized format by a source adapter before this skill runs. Run the adapter for first, then re-invoke."
2. For each ticket file, parse the frontmatter and body. Validate that the ticket has all four required normalized fields: id, title, status, Depends on:. Reject tickets missing any field with a per-file error.
3. Filter the ticket set to those with status ∈ {ready, in-progress} and whose dependencies all resolve to other tickets in the set. Tickets with status: blocked or with unresolved dependencies are listed in the run summary as Skipped with a reason.
4. Build the dependency DAG from Depends on: edges. Detect cycles; if any cycle exists, abort with the cycle printed and a recommended resolution (re-derive the dependency graph via spec-to-tickets).
5. Compute topological batches: a batch is a maximal set of tickets with no inter-batch dependencies (all tickets in batch N depend only on tickets in batches < N).
6. For each batch, group tickets that share at least one file path (in their recommended workflow's Where: lines or in their Files context pointer). Each group becomes a single dispatch unit. Tickets with no file overlap remain individual dispatch units.
7. Print the batching result: [OK] loaded=<N> ready=<N> skipped=<N> batches=<N> dispatch-units=<N>. List the dispatch units with their constituent ticket ids and shared files.

Completion criterion: ticket set loaded, DAG acyclic, batches and dispatch units computed, batch summary printed.

Load references/sub-agent-dispatch.md before Step 3 for the full dispatch template variables and prompt shape; load references/judge-prompt.md before the judge-loop sub-step in Step 3.

Sub-Agent Contract (MANDATORY)

These rules are non-negotiable. They apply to every sub-agent dispatch regardless of ticket content, batch, or mode. The coordinator enforces them; the sub-agent is bound by them. Violations are contract breaches, not suggestions.

• REQUIRED: All work happens inside <STAGING_PATH>. No file outside the staging area may be written. VIOLATION: return status: error with notes: wrote-outside-staging.
• REQUIRED: No commits. The sub-agent must not run git add, git commit, git push, git checkout to a different branch, or any commit-related or branch-switching command. The coordinator owns all commits. VIOLATION: return status: error with notes: attempted-commit.
• REQUIRED: The sub-agent must return the structured response format exactly as specified (status / files_changed / criteria_check / notes). VIOLATION: treat as status: error with notes: malformed-response.
• REQUIRED: The sub-agent must not ask the coordinator questions mid-dispatch. One prompt in, one structured response out. VIOLATION: treat as status: error with notes: attempted-interaction.
• REQUIRED: The sub-agent must not see other in-flight staging areas. Each dispatch gets a clean, pinned checkout.
• REQUIRED: Changes must be scoped to the ticket's acceptance criteria. No refactoring unrelated code; no reformatting untouched lines.

Step 3 — Per-dispatch-unit execution

For each dispatch unit (in batch order; units within a batch may run in parallel via multiple sub-agents), the following sub-steps apply. The per-ticket loop inside the dispatch unit runs in ticket order within the group.

1. Extract completion criteria from the ticket body:
   • Read the Acceptance criteria section.
   • If absent, read the Definition of Done section.
   • If neither is present, treat the ticket's Goal + What to build sections as the criteria and surface a [DEVIATION] ticket=<id> no explicit criteria — using Goal+What to build line.
2. Create a per-sub-agent staging area:
   • Default: a directory at .implement-runs/<run-id>/staging/<ticket-id>/ reachable from the shared branch.
   • The sub-agent's working copy for this ticket is a clean checkout pinned to the commit at which the dispatch began, plus all already-applied staging areas from earlier (DAG-respecting) tickets in the same run.
   • The sub-agent does not see any other in-flight staging areas.
3. Dispatch a sub-agent with a fresh context:
   • Pre-dispatch checklist — before sending the dispatch prompt, verify every item:
     • Prompt includes the no-commit rule (verbatim from the Sub-Agent Contract above).
     • Prompt includes the staging-area-only rule (verbatim from the Sub-Agent Contract above).
     • Prompt includes the structured response format (status / files_changed / criteria_check / notes).
     • Prompt includes the no-interaction rule (one prompt in, one response out).
     • Prompt uses imperative language (REQUIRED / VIOLATION) for all constraints — not advisory language ("should", "please", "try to").
     • If any item is missing, abort the dispatch and fix the prompt before sending. Do not dispatch with a partial contract.
   • Load references/sub-agent-dispatch.md and follow the dispatch template.
   • The sub-agent is told: ticket id, normalized ticket body, the resolved completion criteria, the list of files it owns, and the staging-area path.
   • The sub-agent accumulates all changes silently. No WIP commits appear in the shared branch's history. Sub-agents are forbidden from committing during dispatch; the coordinator owns commits.
4. Capture the sub-agent's diff and validate:
   • Capture the staging area's git status + git diff once the sub-agent reports done.
   • Post-dispatch validation — verify every item before proceeding to the judge loop:
     • The sub-agent did not run any commit-related command (check the staging area's git log; only <STARTING_COMMIT> should be reachable before the coordinator commits).
     • All paths in files_changed are within <OWNED_FILES>. If not, treat as status: error with the offending path in notes and increment the strike counter.
     • The sub-agent returned the structured response format (status / files_changed / criteria_check / notes). If unstructured or missing required fields, treat as status: error with notes: malformed-response and increment the strike counter.
     • The sub-agent did not write outside <STAGING_PATH>. If it did, treat as status: error with notes: wrote-outside-staging and increment the strike counter.
     • If any check fails, do not proceed to the judge loop. Record the violation, increment the strike counter, and route through failure handling (Step 4).
5. Run the judge loop:
   • Load references/judge-prompt.md and follow the judge template.
   • The judge receives: the ticket's completion criteria, the sub-agent's diff, and the staging-area state.
   • The judge returns one of three verdicts: approve, reject-with-feedback, reject-with-ambiguity.
   • On approve: proceed to commit (step 6).
   • On reject-with-feedback: re-dispatch the sub-agent with the judge's feedback as additional context. Increment the strike counter for this ticket.
   • On reject-with-ambiguity: surface the ambiguity to the user immediately with [ESCALATION] ticket=<id> ambiguity=<one-line-summary> (Collaborative mode) or auto-skip with a recorded reason (Self-Contained mode).
6. Commit on the shared branch:
   • Subject line: starts with the ticket-id bracket prefix, followed by a plain-language description.
     • Single-ticket dispatch: prefix is [<ticket-id>]. Example: [TK003] add subject-quality gate to commit step.
     • Same-file-group dispatch (multiple tickets in one commit unit): prefix is [<ticket-id-1>,<ticket-id-2>,...] (comma-separated, no spaces). Example: [TK003,TK007] add subject-quality gate and post-commit identity check.
     • The bracket prefix stays in the subject. It is what makes commits greppable against the ticket set. It is not moved to the body footer.
     • Treat 72 characters as a soft cap, not a hard limit. A 90-character self-explanatory subject is preferable to a truncated cryptic one.
     • The rest of the subject (after the bracket prefix) reads as a public changelog entry. The reader has not read the ticket, the decision ledger, or any prior work.
     • The negative rules (no ledger IDs, no other-ticket IDs, no host-tool acronyms, plain-language verb/noun) are enforced by the subject-quality gate below; the format description does not restate them.
   • Body: bullet list of what was done (one bullet per discrete change).
   • Footer: references to related tickets and decision-ledger records (Refs: ticket-<id>, DECISIONS-<name>.md#Dxxx), and any BREAKING CHANGE: line if applicable.
   • Commit invocation by policy:
     • human-only: git commit -m '<subject>' -m '<body>' -m '<footer>'. The shell's git config user.name / user.email is the human identity.
     • human+ai-coauthor: the coordinator reads git config user.name and git config user.email immediately before the commit to obtain the shell human identity, then runs git -c user.name='<shell-human-name>' -c user.email='<shell-human-email>' commit -m '<subject>' -m '<body>' -m '<footer>' -m 'Co-authored-by: <ai-name> <<ai-email>>'.
     • ai-only: git -c user.name='<ai-name>' -c user.email='<ai-email>' commit -m '<subject>' -m '<body>' -m '<footer>'.
     • In all three cases, the identity is supplied at commit time via the -c flag. The skill does not call git config user.name / git config user.email to mutate the shell's persistent git config.
   • Subject-quality gate (run before the commit invocation): the coordinator inspects the subject against the following rules; any failure rejects the subject. These are the canonical home for the negative rules — the subject-format description above does not restate them.
     • No ledger IDs in the subject: subject does not match the regex \bD\d{3}\b or \bT\d{3}\b outside the ticket-id bracket.
     • No other-ticket IDs in the subject: subject does not match TK\d{3} for any ticket id other than the one in the bracket prefix.
     • No host-tool acronyms in the subject: the subject must not contain host-tool acronyms that the repo glossary in GLOSSARY.md does not recognise as universal (e.g. MTP, VSTest, CPM, TFM, AOT).
     • Plain-language: subject contains at least one verb or noun phrase that names the user-visible effect of the change.
     • On rejection: the coordinator increments the strike counter for this ticket and re-dispatches the sub-agent with the gate's feedback (mirroring the reject-with-feedback re-dispatch path). A second rejection on the same ticket escalates to the user via the circuit breaker.
   • One commit per ticket. No WIP commits, no merge commits inside a ticket's staging area, no squash — the per-ticket commit is the source of truth.
7. Post-commit identity check (run immediately after the commit, before reconciling the staging area):
   • Skip rule: if the attribution policy is human-only, skip this sub-step entirely. The shell's git config user.{name,email} is the contract.
   • Capture the expected author string:
     • ai-only → expected = <ai-name> <<ai-email>> (the strings recorded at Step 1.6, byte-identical to the user-supplied values).
     • human+ai-coauthor → expected = <shell-human-name> <<shell-human-email>>, where shell-human-name and shell-human-email are captured by running git config user.name and git config user.email immediately before the commit invocation in sub-step 6, and stored in local variables for use here. If either git config lookup returns an empty string, abort with [DEVIATION] ticket=<id> reason=human-identity-missing and route through references/failure-categorization.md as persistent.
   • Capture the recorded author: run git log -1 --format='%an <%ae>' in the shared branch's working tree and trim trailing whitespace.
   • Compare the recorded author to the expected author (string equality, case-sensitive on name, case-insensitive on email). On match, continue. On mismatch, go to the "Mismatch" branch below.
   • Co-author trailer check (only if the policy is human+ai-coauthor): run git log -1 --format='%B' and grep for the regex ^Co-authored-by: <ai-name> <<ai-email>>\s*$ (case-insensitive on the name and email). On match, the post-commit check passes. On miss, go to the "Mismatch" branch below.
   • Mismatch branch: emit exactly one line in this shape — [DEVIATION] ticket=<id> author=<actual> expected=<expected> — then call the failure handler with category=persistent, task=commit-identity-verify, and the deviation line as the signal. The strike counter for this ticket increments. The run summary records the failure under Failures. The per-ticket loop does not advance to the next ticket until the failure is routed per references/failure-categorization.md.
   • Completion signal: either a recorded match on both checks and the per-ticket loop advancing, or a recorded [DEVIATION] line and a routed failure under Failures in the run summary.
8. Reconcile the staging area into the shared branch: the commit is the reconciliation artefact. Staging-area files are now on the shared branch in DAG order. Staging directories are retained until end of run, then removed.
9. Live update after each ticket:
   • [OK] ticket=<id> commit=<sha> batch=<n> on success.
   • [ERROR] ticket=<id> reason=<one-line> on judge rejection that hits the circuit breaker.
   • [DEVIATION] ticket=<id> <detail> on criteria-source fallbacks, conflict-resolution events, or other plan deviations.
   • [ESCALATION] ticket=<id> <detail> on user-facing interrupts.

Completion criterion (per ticket): either a commit on the shared branch, a recorded skip with reason, or a recorded escalation to the user. Strike count for the ticket is reset to 0 on commit.

Common Sub-Agent Violations

These are contract violations, not warnings. Each one increments the strike counter and routes through failure handling (Step 4). The coordinator must detect and record every instance.

• Sub-agent committed: The sub-agent ran git add, git commit, or any commit-related command. Contract violation — the coordinator owns commits. Treat as status: error with notes: attempted-commit.
• Sub-agent wrote outside staging: The sub-agent modified a file outside <STAGING_PATH> or <OWNED_FILES>. Contract violation — the staging area is the only writable surface. Treat as status: error with notes: wrote-outside-staging.
• Sub-agent returned unstructured response: The sub-agent's response does not match the required format (status / files_changed / criteria_check / notes). Contract violation — the judge cannot evaluate an unstructured response. Treat as status: error with notes: malformed-response.
• Sub-agent attempted interaction: The sub-agent asked the coordinator a question or waited for input mid-dispatch. Contract violation — one prompt in, one response out. Treat as status: error with notes: attempted-interaction.
• Sub-agent refactored out of scope: The sub-agent changed code outside the ticket's acceptance criteria (unrelated refactors, reformatting of untouched lines). Not a hard error, but the judge should flag it; if the judge rejects, route through the normal re-dispatch path.

Step 4 — Failure handling and circuit breaker

Every failure is categorized and routed. The categorization rules live in references/failure-categorization.md (load on first failure, not before).

1. Categorize each failure as one of: transient, persistent, dependency, ambiguous. Rules in the reference file.
2. Route by category:
   • transient → auto-retry, with exponential backoff capped at 3 retries before falling through to the circuit breaker.
   • persistent → auto-skip with a recorded reason; do not retry.
   • dependency → auto-skip and mark downstream tickets as blocked in the run summary.
   • ambiguous → escalate to the user (Collaborative) or auto-skip with a recorded reason (Self-Contained).
3. Circuit breaker: any task (commit, file edit, sub-agent dispatch, judge call) that fails more than N times for the same ticket — regardless of category — escalates to the user with [ESCALATION] ticket=<id> task=<name> strikes=<n> (Collaborative) or aborts the run (Self-Contained). The threshold N is the Step 1 value (default 3).
4. Visibility: every auto-handled failure and every circuit-breaker escalation appears in the run summary (Step 6) with its category, ticket id, and one-line reason.

Completion criterion: every failure has a recorded category, a recorded route, and either an action (retry / skip) taken or a recorded escalation. The strike counter for each ticket is consistent with the route taken.

Step 5 — Cross-dispatch conflict resolution

When two dispatch units within the same batch touch the same file, the rule below applies. Conflict-resolution rules live in references/conflict-resolution.md; load on first conflict.

1. Detection: at the end of each batch, the coordinator diffs the per-ticket commits in topological order and flags any overlapping file regions.
2. Default resolution: last-writer-wins (LWW) by commit order on the shared branch. The overlapping region in the earlier commit is preserved only if the later commit's diff did not touch that region.
3. Escalation: if the LWW rule would produce a result that contradicts a ticket's stated acceptance criteria, escalate to the user with [ESCALATION] ticket=<id> conflict=<file> reason=<one-line> and pause that batch.
4. Recording: every conflict, the rule applied, and the resulting resolution is recorded in the run summary under Conflicts.

Completion criterion: every detected conflict has a recorded resolution, and either a follow-up commit (if LWW is re-applied) or a recorded escalation. The shared branch's history contains no unresolved overlap.

Step 6 — End-of-run report

1. Compose a markdown report at tickets/.runs/<run-id>.md with these sections:
   • Run header: run id, mode, workspace, breaker threshold, start/end timestamps, total wall-clock.
   • Stats: loaded, ready, skipped, batches, dispatch units, committed, escalated, conflicted.
   • Per-ticket outcomes: one row per ticket with id, title, status (committed / skipped / escalated / pending), commit sha, strikes used.
   • Failures: category, ticket id, one-line reason, route taken.
   • Conflicts: file, tickets involved, rule applied, result, escalation flag.
   • Deviations: any plan deviations surfaced during the run (e.g., criteria-source fallbacks, skipped tickets, escalation events).
   • Next steps: tickets remaining in the ticket set, blocked tickets, and recommended follow-up actions for the user.
2. Commit the report to the shared branch with subject [run/<run-id>] implement-tickets end-of-run report.
3. In Collaborative mode: print the report to the conversation and ask the user to acknowledge before finalizing. In Self-Contained mode: print a one-line summary to the conversation and commit.
4. Clean up staging directories under .implement-runs/<run-id>/staging/ after the report is committed.

Completion criterion: report file exists at tickets/.runs/<run-id>.md, report is committed on the shared branch, staging directories are removed.

Output Mode

This skill writes a structured end-of-run markdown report to tickets/.runs/<run-id>.md and commits per-ticket changes plus the report to the shared branch. It does not draft in conversation by default; the conversation receives live updates and a final one-line summary. The user may request an additional tickets/.runs/<run-id>-draft.md in conversation before the report is committed by pausing after Step 6.3's report composition.

Transitions

• write-changelog — may run after this skill to summarize the per-ticket commits as user-facing release notes. The per-ticket commit subjects ([<ticket-id(s)>] <plain-language description>) are designed to be changelog-friendly.

Validation

• Step 1 resolved mode, workspace, breaker threshold, and attribution policy before any ticket work began.
• Mode banner was printed at Step 1 completion in the form [OK] mode=... workspace=... breaker=... attribution=<policy>[ ai=<name> <email>].
• Step 2 rejected tickets with missing normalized frontmatter fields with a per-file error.
• Step 2 detected cycles in the dependency DAG and aborted with the cycle printed, or confirmed acyclic.
• Step 2's batch summary was printed ([OK] loaded=... ready=... skipped=... batches=... dispatch-units=...).
• Same-file tickets were grouped into a single dispatch unit.
• Each sub-agent received a fresh context (no shared scratchpad, no carry-over context from prior tickets).
• Pre-dispatch checklist was completed before each dispatch (all five items verified; no dispatch sent with a partial contract).
• Post-dispatch validation was completed after each sub-agent response (all four items verified; no judge loop started with a failed validation).
• Common sub-agent violations (commit attempts, writes outside staging, unstructured responses, interaction attempts) were detected, recorded, and routed through failure handling.
• No WIP commits appear on the shared branch between per-ticket commits (the per-ticket commit is the only commit authored for the ticket).
• Each per-ticket commit subject matches the form [<ticket-id(s)>] <plain-language description>. The 72-character limit is a soft cap.
• Each per-ticket commit's cross-references appear in the body footer in the Refs: ticket-<id>, DECISIONS-<name>.md#Dxxx format, never in the subject.
• Step 1 captured the attribution policy before any ticket work began. The mode banner shows attribution=<policy> (and ai=<name> <email> when policy involves AI).
• For human+ai-coauthor and ai-only policies, the user supplied the AI name and email; the skill did not auto-fill, did not invent a handle, and did not mutate the shell git config.
• For human+ai-coauthor policy, the per-ticket commit carries a Co-authored-by: <ai-name> <<ai-email>> trailer; for ai-only policy, the commit's author is the AI identity.
• references/commit-author-policy.md was loaded before sub-step 6 of Step 1 when the policy involved AI.
• The post-commit identity check ran for every per-ticket commit where the policy involved AI; the recorded author matched the expected; for human+ai-coauthor the Co-authored-by: trailer matched the AI identity. The check did not run for human-only commits.
• An identity mismatch produced exactly one [DEVIATION] ticket=<id> author=<actual> expected=<expected> line and was routed through references/failure-categorization.md as persistent; the strike counter for the ticket incremented; the run summary recorded the failure under Failures. The per-ticket loop did not advance past the failing ticket.
• The subject-quality gate ran before every per-ticket commit and rejected any subject that violated the four rules in Step 3.6.
• Each per-ticket commit body is a bullet list of changes; each footer has references or is explicitly empty.
• Judge loop ran for every ticket; no ticket was committed without a judge approve verdict.
• Sub-agents did not see other in-flight staging areas (verified by the staging-area path and the pinned starting commit).
• Cross-batch conflicts were detected, resolved per the rule in references/conflict-resolution.md (default LWW until that reference overrides it), and recorded in the report.
• Every failure has a category from {transient, persistent, dependency, ambiguous} and a recorded route.
• Circuit breaker escalated or aborted after N strikes (default 3) for any task on any ticket, regardless of category.
• Every auto-handled failure and circuit-breaker escalation is visible in the run summary.
• Live updates used the four-prefix vocabulary ([OK], [ERROR], [DEVIATION], [ESCALATION]) consistently.
• End-of-run report exists at tickets/.runs/<run-id>.md and is committed on the shared branch.
• Staging directories under .implement-runs/<run-id>/staging/ are removed after the report is committed.
• In Collaborative mode, Step 6.3 asked the user to acknowledge before finalizing; in Self-Contained mode, only a one-line summary was printed.
• references/sub-agent-dispatch.md, references/judge-prompt.md, references/failure-categorization.md, and references/conflict-resolution.md exist as referenced (or the skill surfaces their absence as [DEVIATION] missing-reference ...).
• External ticket sources (e.g., GitHub Issues) were converted to the normalized format by an adapter before the skill ran; the skill did not consume a non-normalized source directly.