Imported from woojubb/robota (.agents/skills/backlog-execution-orchestrator/SKILL.md). Install upstream with npx skills add woojubb/robota --skill backlog-execution-orchestrator. Copyright stays with the author.

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. loop: over=finding-set; escape=no-progress; bound=2 rounds invocable: true

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.

Also dispatch finding-depth-triager on the item's problem statement, before the recommendation is formed. Two different questions, and both have to hold: proposal-reviewer asks whether the chosen decision is right AMONG THE ALTERNATIVES; the depth verdict asks whether the problem being solved is the real one (finding-depth.md). An item scoped to a SYMPTOM produces a plan that cannot be right, and every gate after this one will pass it — because each of them judges the plan against the item rather than the item against reality.

A FOUNDATIONAL verdict here routes to the last row of the table below: re-scoping an item is a decision above this pipeline. Asking at this moment is what makes that a cheap answer instead of an expensive one.

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.

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.

Phase 4 — Done gate

Dispatch user-execution-scenario in GATE mode.

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.

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.

What This Skill Does NOT Do

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

Record the run

Open a ledger entry before the first round, record each round's finding count, and close it with the terminal reason it actually reached — converged, no-progress, bound-reached, halted-for-user, or abandoned if it stopped without reaching any of them. A run that leaves no record cannot be told from a run that never happened (a loop run is recorded, which owns what each terminal reason means).

node scripts/harness/loop-run.mjs open  --loop backlog-execution-orchestrator
node scripts/harness/loop-run.mjs round --loop backlog-execution-orchestrator --run <id> --findings <n>
node scripts/harness/loop-run.mjs close --loop backlog-execution-orchestrator --run <id> --terminal <reason>