AI Agent & Automation Workflows

Layer 3 cross-repo orchestration driver for the livespec family (invoked as /livespec-orchestrate). Composes /livespec:next and the active impl-plugin's next; dispatches sub-agents (each working in its own self-managed secondary worktree, NOT the harness isolation mechanism) into livespec, livespec-impl-, livespec-dev-tooling, and livespec-runtime; reaps merged worktrees via just reap-stale-worktrees; runs just check + /livespec:doctor as a hard gate; emits a structured iteration journal; halts on architectural ambiguity, broken state, destructive ops, phase boundaries (default; can be pre-authorized), or (defensive) context-budget exhaustion. Per SPECIFICATION/spec.md §"Three-layer orchestration architecture" and §"Layer 3 loop driver — required shape and discipline" in non-functional-requirements.md, this skill is the SINGLE Layer 3 driver across the livespec family — impl-plugin repos do NOT carry their own. The directory name carries a livespec- visual prefix to disambiguate from the harness's built-in /loop skill (recurring-task scheduler); project-local skills have no real namespace mechanism, so the prefix is a convention, not enforcement.

Aggregate the whole livespec fleet's attention into ONE flat merged list. It fans out over .livespec-fleet-manifest.jsonc (fleet members + adopters), invokes each repo's shipped product needs-attention --json, folds in the local needs-attention-internal fleet-dev signals, and concatenates every item into a single flat attention[] reusing the SAME attentionitem schema — each item attributable to its repo via sourceref.repo. It is a PURE AGGREGATOR: NO cross-repo re-ranking (the same restraint impl-next has); it preserves each repo's own item order and never reorders across repos. Grouping (by repo or urgency) is a renderer concern only — the Markdown human view groups; the JSON stays flat. Adopters contribute product needs-attention ONLY; -internal is livespec-fleet-dev-specific. Fail-soft: a repo without a reachable surface is skipped and named, never crashing the fan-out. LOCAL-ONLY to livespec core, maintainer-only, UNSYNCED — not part of the plugin, the spec, the copier template, or any fleet-propagated surface.

Compose the livespec-fleet-DEVELOPMENT signals a fleet maintainer must watch but an end user does NOT control — CI red on any fleet repo, fleet-conformance drift, stale cross-repo pins, cross-repo consistency drift, and ledger status-conformance drift — into one point-in-time attention list. It mostly reads signals already computed elsewhere (GitHub Actions for CI, the dev-tooling conformance and pin-freshness checks, /livespec:doctor for drift); the one exception is the ledger status-conformance scan, which runs a cheap per-tenant ledger-normalize --dry-run directly because no scheduled workflow computes it. All are normalized into the shared attentionitem shape with kind: "internal". This is the internal sibling of the shipped product needs-attention: the dividing test is does an end user have actionable control? — yes routes to the shipped needs-attention (plugin version, their repo's hygiene), no routes here (fleet CI/conformance/pins/drift). LOCAL-ONLY to livespec core, maintainer-only, UNSYNCED — it is not part of the livespec plugin, the spec, the copier template, or any fleet-propagated surface, and never ships to the plugin or to adopters. Emits nothing when the fleet is green.

Keep multiple parallel livespec tracks moving via a TWO-PANE model: a deterministic top-pane daemon (overseerd) that watches every tracked tmux session's context %, injects an ESCALATING wrap-up at threshold, and atomically restarts a session ONLY once that session declares itself ready (exit + claude --dangerously-skip-permissions -n + re-kick from plan/ /handoff.md) — THE CARDINAL RULE: the daemon NEVER restarts a session that has not declared itself ready, because only the session knows whether it is safe to kill; one that declares nothing is REPORTED as not responding and left alone — and this THIN bottom pane, the interactive Claude overseer, which starts the daemon, manages the discovery-driven auto-managed track list via a JSONL topic↔tmux mapping (add/remove/unassign/start), and RELAYS the tracks the daemon reports as non-blocking text naming the tmux session + pane to go to. NOTIFY, NEVER BLOCK: a question may only be asked by the actor that OWNS the decision, so the overseer never raises a blocking prompt for a TRACK's decision (answer that in the track's own pane); it prompts only for decisions it owns (add/remove/unassign/start, threshold). The list is discovered from each watched repo's plan/ dir; declaration is OUT-OF-BAND on the filesystem — ONE .overseer-state file valued ready / blocked: / winding-down — never pane text. The daemon never auto-spawns a session for an UNASSIGNED plan (first launch is deliberate) and never force-kills any session. The overseer does NO track work, never polls tracked sessions on a timer, never hand-codes. LOCAL-ONLY to this repo and usable only from it — a PERMANENT, human-supervised ALTERNATE to autonomous mode (not a stopgap): not part of the plugin, spec, template, or fleet, and not synced.