/orchestrate

name: orchestrate
description: 'Run ready Tickets from one effort, or the whole store, in parallel — each through run-ticket in its own session — land finished work one Ticket at a time, ticket up the debt runs leave, and keep a status page and one list of what waits on the person. By default it proposes a plan and waits for approval; with --autonomous it acts on its own until no ready work is left. Use when the user wants to work through the queue, run many Tickets at once, or start unattended work from a scheduler.'
argument-hint: '[<effort>] [--autonomous] [--max-batch <n|none>] [--type <type>[,<type>...]]'
user-invocable: true

orchestrate

Work through a Ticket Store's ready Tickets several at a time. A **Ticket** is a self-sufficient work packet in the project's store; an **effort** is a named group of Tickets with one destination and one **front item** (the effort's front file: the tracking item's body, or the effort's README in a file store). Each **run** is one `run-ticket` attempt on one Ticket, in its own session. This skill plans, launches, lands, and keeps the person informed, in **check-ins**: at each one it re-reads the store, gives one finished run its **landing turn** (its merge onto the target branch), gathers debt, and fills free run slots. It keeps no state of its own: everything it knows it reads from the Tickets and git, and from the sources the signposts it meets name, so a new orchestrator, or a second one, rebuilds the same picture. A **signpost** is a `Revisit when` line — a condition in the world and where it is read — on a deferred Ticket, or after a title in the North Star's list of strategy choices in force.

Arguments

• `<effort>` — the effort to work. With none named, the whole store: every effort with open

Tickets.

• `--autonomous` — act without waiting for approval. Without it, propose a plan and wait.
• `--max-batch <n>` — how many runs may be live at once; 10 when unset, and `none` removes the

limit.

• `--type <type>[,<type>...]` — work only Tickets carrying one of these Ticket Types. A Ticket

with no type never matches.

What loads

| Reference | Loads when | What it adds | |---|---|---| | `../ticket-up/references/TICKET_CONVENTION.md`, the venue reference, `../ticket-up/references/AUTOMATED_EXECUTION.md` | always, before reading the store | readiness, priority, what Auto and its absence allow, the records on each Ticket, and the one landing procedure | | `references/PROPOSE_AND_WAIT.md` | by default | proposing each plan, waiting for approval, asking for grants, and proposing the next plan when one ends | | `references/AUTONOMOUS.md` | `--autonomous` | acting at once, granting Auto where the criterion holds, filling slots until no ready work is left | | `references/STATUS_PAGE.md` | at each check-in | the page's data fields, where it is published, and how its live data is written |

Start

1. **Resolve the store.** Read `tickets/store-config.md`, or where the project's context file says the store lives. Resolve the **automation identity** — the account unattended runs claim with and write as — and the human escalation recipient. When this session cannot write as that identity, say which account the store config needs and stop before any launch. 2. **Read the front items.** For each effort in scope, read its front item's destination, its priority override, and its standing settings: a `Paused:` line, and a `Status page:` line holding the page's link. Then read every strategy signpost in the project's North Star (`NORTH_STAR.md`, or wherever the project context file says it lives) at the source it names, whatever the scope: one that reads as met, and one whose source cannot be read, each goes on the list of what waits on the person with its record's title and source. Change neither the record nor the list; reopening a choice is the person's call. 3. **Read the venue's limits.** A file store gets no parallel runs: claims cannot separate runs across working copies, so this orchestrator runs one Ticket at a time inside its own session. On a code host, read whether the target branch requires up-to-date branches or a merge queue, as the venue reference says. 4. **Take an orchestrator ID**, such as the start time and a short random suffix. Every run ID it writes starts with it, which is how it tells its own runs from another orchestrator's. 5. **Read every Ticket in scope whole**, its records included, and sort it. Count a record only when the automation identity wrote it. A run is **live** until it writes an outcome, while the host reports its session alive and its timeout has not passed (`../ticket-up/references/AUTOMATED_EXECUTION.md` → *The attempt record*). A run that is not yours belongs to another orchestrator until its timeout has passed, live or not; leave its Ticket alone until then. Each Ticket takes the first category below whose conditions hold, so it is in exactly one.

• *Left alone*, each with its reason: a person is assigned; its author lacks write access and it

has no Auto; it is escalated; another orchestrator's run holds it; a dependency is open and not itself planned; it is deferred and its signpost reads as unmet; it is deferred and its signpost's source cannot be read, which also puts it on the list of what waits on the person, with that source; the type filter passes it over. Read each deferred Ticket's source at every sort, and never edit its line, whatever the source showed or whether you could read it: only a person does. A Ticket whose open dependencies are all planned joins the plan behind them.

• *Running*: its run facts name a live run.
• *To land*: its record is marked ready to land by a run of yours and no run is live, and the

Ticket was not reopened after its pull request merged. With Auto it waits for a landing turn; without Auto it waits on the person.

• *Answered*: its record holds a drafte