backlog-execution-orchestrator

name

backlog-execution-orchestrator

description

The state machine for executing ONE backlog item or named work unit end to end. Sequences five phases — recommendation gate, scenario planning, implementation, done gate, completion — dispatching proposal-reviewer and the user-execution-scenario sub-pipeline, and routing on each outcome (advance / repeat / return to an earlier phase / terminate). It holds NO backlog policy: every gate definition, PR contract, status invariant, and stop condition is owned by the project's backlog-execution rule and is pointed at, never restated. Use when working a backlog item; for an initiative spanning several items, multi-backlog-initiative is the entry point and dispatches this once per item.

Backlog Execution Orchestrator — pipeline only

The state machine for one backlog item or one explicitly named work unit. This skill owns ordering and routing between phases and nothing else. It does not define what a recommendation must contain, what a valid scenario is, when status may be set, or when to stop — those are invariants owned by the rule below, and restating them here would create a second copy that drifts.

Entry. One item enters here. An initiative spanning several items enters multi-backlog-initiative, which dispatches this pipeline once per item against the initiative's base branch. Do not run several items through this pipeline concurrently — the rule's one-item-at-a-time constraint is not a preference.

Rule Anchor

• backlog-execution.md — the policy SSOT for everything this skill sequences: "Agent Decision Authority", "Recommendation Gate" (required contents), "One-Backlog-At-A-Time Rule", "PR Unit Rule" (including the PR-description contract), "User Execution Test Scenario Rule", "Done Gate" (the mandate), "Completion Steps", "Status Invariants", "Stop Conditions".
• git-branch.md — branch safety, clean-tree requirement, commit cadence, merge approval.
• enforcement-architecture.md — worker / guardian / orchestrator.

Preconditions (refuse to start otherwise)

1. Exactly one target item or named work unit is identified.
2. No previous item from this session is unmerged (a Stop Condition in the rule).
3. The working tree is clean of anything unrelated to this item.

If any precondition fails → terminate and report which one.

Phases and routing

Phase 1 — Recommendation gate

Form the recommendation the rule requires, then hand it to proposal-reviewer rather than judging it here. See "The recommendation is not self-judged" below — this is a deliberate behavioural change from the rule's previous self-assessment wording, made because an orchestrator forming a verdict on its own output is exactly what enforcement-architecture.md forbids.

Outcome	Route
The decision is one the rule reserves for the user	Terminate — halt for the user before dispatching anyone. An independent review is not a substitute for approval the rule says only the user can give.
REVIEW VERDICT: ENDORSE	Advance to phase 2. Record the endorsed recommendation; it is what the PR description must later reflect.
REVIEW VERDICT: REVISE	Revise the recommendation against the reviewer's findings and repeat phase 1. Bounded: 2 revisions; on the third, terminate and hand the reviewer's findings to the user.
REVIEW VERDICT: REJECT	Terminate — halt for the user with the reviewer's reasoning. Never proceed by overriding a REJECT; the reviewer exists precisely to be able to say no.
The reviewer's finding is that the item's own premise is wrong	Terminate. Re-scoping an item is a decision above this pipeline.

Phase 2 — Scenario planning

Dispatch user-execution-scenario in PLAN mode. It runs before implementation, not after: the rule requires the scenario to exist first.

Outcome	Route
PLANNED	Advance to phase 3. Phase 4 will run the same pipeline in GATE mode.
NOT-APPLICABLE	Advance to phase 3 carrying the recorded reason. Phase 4 is skipped, and the PR description states the not-applicable reason instead.
HALT	Terminate with the sub-pipeline's reason. Do not implement first and plan the scenario afterwards.

Phase 3 — Implementation

Route the actual work to the owner skills (table below). This pipeline sequences; it does not implement, and it does not absorb what an owner skill defines.

Outcome	Route
Implementation and engineering verification complete, tree clean	Advance to phase 4 (or phase 5 when phase 2 returned NOT-APPLICABLE).
The work turns out to need a decision the rule reserves for the user	Terminate — halt for the user. Disclosing it in a PR body later is not approval.
The scope grows beyond the endorsed recommendation	Return to phase 1 with the enlarged scope. A recommendation endorsed for smaller work does not cover larger work.
The work splits into genuinely separate units	Terminate and re-enter once per named unit; each unit gets its own phase 1.

Phase 4 — Done gate

Dispatch user-execution-scenario in GATE mode.

Outcome	Route
VERIFIED	Advance to phase 5.
IMPLEMENTATION-DEFECT	Return to phase 3, fix, then re-enter phase 4. Bounded: 2 rounds; on the third, terminate — a defect that survives two targeted fixes is not understood.
HALT	Terminate. Status is not set, the item is not moved, and the PR does not claim the gate passed.

Never advance past this phase on anything other than VERIFIED or a phase-2 NOT-APPLICABLE. This is the single edge the rule marks absolute.

Phase 5 — Completion

The status change and the file move are one commit, in the order the rule states. They are one atomic act, not two steps that usually happen together.

Outcome	Route
Both staged and committed together	Advance to close-out.
The move fails or conflicts	Do not commit the status change alone. Revert the status edit, resolve the move, then redo both. A half-landed pair is the state the placement floor exists to catch — do not create it deliberately.
A previous commit already landed one half	Complete the pair in the next commit, before any other work. Nothing else advances while status and location disagree.
The item is ending unimplemented rather than done	Take the same one-commit path with the terminal status the rule defines for that case. An abandoned item still gets closed properly.

Close-out

1. Open the PR — one item or one named work unit per PR, sized per the rule's PR Unit Rule. Its description carries every field that rule requires, including the gate result or the not-applicable reason.
2. Route the PR through the project's review and merge path; this pipeline does not merge protected branches on its own authority.
3. Report the outcome, and — when the gate passed — tell the user what was verified, the exact command or steps they can run, the expected result, and the evidence already observed.

The pipeline ends here. It does not start the next item.

The recommendation is not self-judged

Previously the same actor formed the recommendation and then decided whether it was coherent with the project's rules, layering, and architecture. That is a role producing and judging its own output, which enforcement-architecture.md prohibits, and it is the reason phase 1 dispatches proposal-reviewer.

What this changes, stated plainly: an independent review is now required at the recommendation gate, where before there was none. What it does not change: the reviewer is a guardian, not an approver. Decisions the rule reserves for the user still halt for the user, and an ENDORSE never converts a user decision into an agent one.

The artifact under review is the recommendation — the approach and its fit — not the implementation, which has not happened yet. That bounds what is handed over, not how hard the reviewer looks at it: its charter mandates testing premises against real source and checking architecture placement, and neither should be curtailed.

Record the verdict. The rule requires the REVIEW VERDICT and its date to land in the work item or the PR description. Until a scan reads it, that record is the only thing distinguishing an endorsed gate from a self-approved one — do not skip it because nothing currently fails when you do.

Terminate edges that belong to this level

• Any Stop Condition in backlog-execution.md becomes true at any point → terminate immediately, whichever phase is running. Each condition listed there is a terminate edge of this pipeline; they are owned by the rule and are not restated here.
• The user interrupts → record the current phase and the item's state, leave the tree in a committed or cleanly-stashed state, and stop.
• A defect in the process itself is discovered mid-item → record it as its own item; do not fold the fix into this one, unless it directly blocks the active phase, in which case take that phase's failure edge.

Owner skill routing (phase 3)

Load only what the item needs.

Work	Owner
Branch safety and protected branches	branch-guard
Impact → verify → summarize loop	repo-change-loop
Contract boundary or package-ownership change	spec-first-development
SPEC authoring / drift after spec changes	spec-writing-standard, spec-code-conformance
Tests	tdd-red-green-refactor, vitest-testing-strategy
Architecture and layering boundaries	architecture-patterns
Type contracts and trust boundaries	type-boundary-and-ssot
Post-implementation release/docs checklist	post-implementation-checklist

What This Skill Does NOT Do

Not this skill's job	Owner
Judge whether the recommendation is right	proposal-reviewer (agent)
Author or judge a verification scenario	user-execution-scenario and its roles
Define gates, PR contracts, or status invariants	backlog-execution.md
Sequence several items under one initiative	multi-backlog-initiative
Merge a protected branch	the user

If you find yourself forming a verdict, defining a gate, or doing an owner skill's work here, stop — route to the owner instead.