/sdlc:orchestrate

Generated from solutions/ontological/plugin/plugins/sdlc/skills/orchestrate/orchestrate.md.

Description

Run one deterministic orchestrate tick by invoking sdlc orchestrate run --once: dispatch ready tasks, classify and act on open PRs, and close out merged ones. Wrap with /loop /sdlc:orchestrate for the hands-off self-driving orchestrator loop.

Allowed tools

• Bash

Source

Usage:

• /sdlc:orchestrate — perform one tick. No arguments.
• /loop /sdlc:orchestrate — Claude Code only: repeat on a wall-clock cadence; see “Loop cadence” below.

What this skill does

Run:

${CLAUDE_PLUGIN_ROOT}/cli/sdlc orchestrate run --once

and report its stdout as your response. That single invocation IS the tick — [[T-XRFD]] moved every dispatch/reconcile/digest decision that used to live in this skill’s prose into the orchestrate run op (lib/services/orchestrator/): the work/prs/merges ticks, the control-plane compatibility gate, per-PR verdict routing, task lease claiming, and the .sdlc/orchestrator-log.md digest line. This skill adds no logic beyond that one invocation — it does not parse verdicts, dispatch sub-agents, or branch on exit codes itself.

Run ${CLAUDE_PLUGIN_ROOT}/cli/sdlc orchestrate run --help for the --loop/--interval flags. --once here is deliberate: the CLI’s own --interval sleep loop is for a long-lived foreground process, not a single skill invocation, so this skill always passes --once and leaves repeat cadence to whatever wraps it (see below).

The op reads orchestrator: config (loops, interval_seconds, review.max_rounds, review.response_policy, router, pr_filters) and the top-level notify: section from the project’s sdlc.yaml — see ${CLAUDE_PLUGIN_ROOT}/conventions/sdlc-yaml.md.

Pausing, and acting on one item

sdlc orchestrate pause|resume|status is a runtime switch this skill’s own orchestrate run --once invocation respects. sdlc pr route --pr <n> and sdlc task dispatch <basename> bypass pause entirely — the manual per-item escape hatch for “handle this one thing now.” See ${CLAUDE_PLUGIN_ROOT}/conventions/sdlc-yaml.md’s “Pausing the orchestrator” / “Manual per-item dispatch” sections for the full contract (including each command’s flags), and orchestrator.router’s doc there for the live/resume/fresh delivery chain pr route and the prs/merges ticks both use.

Loop cadence

In Claude Code only, /loop /sdlc:orchestrate re-invokes this skill on the interval configured in sdlc.yaml’s orchestrator.interval_seconds (default 300s), via ScheduleWakeup. Each iteration is exactly one --once pass; the interval and repeat behavior live in the /loop wrapper, not in this skill.

For fast, event-gated wake between /loop ticks, pair it with a Monitor running ${CLAUDE_PLUGIN_ROOT}/skills/orchestrate/watch_loop.sh <project-root> (see that script’s header for its contract) — it wraps the read-only sdlc orchestrate watch pending-work gate and is independent of this skill’s own logic.

Notes

• .sdlc/orchestrator-log.md (gitignored under .sdlc/*) is the only file this skill’s invocation touches, and the orchestrate run op owns the write.
• This skill never commits; sub-workflows orchestrate run dispatches (task-work, pr-respond, close-out, pr-update) commit on their own and inherit ${CLAUDE_PLUGIN_ROOT}/conventions/commit-messages.md.
• notify fires per event, not on a “stuck” threshold: this is a Phase-2 scope reduction from this skill’s own retired prose, which used to fire “only when genuinely stuck” (routine blockers did NOT notify). Today notify('task.parked', …) fires once for EVERY failing step in the work tick’s dispatched-task workflow sequence (check/judge/implement/…) — whether a blocking hook parked the branch or the step itself failed — and notify('pr.ci_failed'|'pr.needs_response', …) fires once a PR’s review.max_rounds cap trips, then REPEATS every subsequent tick for as long as that PR stays stuck (no dedup or one-shot suppression), per lib/services/orchestrator/ticks/work.ts and ticks/_pr_action.ts. Each channel named by the matching notify.events.<event> list (notify:’s channels — desktop, ntfy, webhook) receives every one of these; expect more frequent notifications than the old prose skill gave, especially on a project with a lot of routine, self-recovering task failures or a PR stuck past max_rounds.