orchestrator

Triage the review loop's filed findings - the open review:<severity> issues still labelled needs-triage, or with --all (a re-check) every open one whatever its triage label - against the current default branch, putting one numbered batch of proposed outcomes per source PR to the human (close as completed when already fixed, ready-for-agent, ready-for-human, or wontfix, each with its bug/enhancement category kept or flipped; an already-triaged finding in a re-check is proposed only close as completed or leave as is), and applying the answered batch; with --bundle, grouping the open findings already triaged to ready-for-agent or ready-for-human by code area into bundle issues, one batch across source PRs, each member closed as a duplicate of its bundle. Use when the human asks to triage, re-check or bundle filed findings or review:* issues, or runs /orchestrator:finding-triage [--all] [<issue> | --pr <n>] or /orchestrator:finding-triage --bundle. Not for any other issue - upstream triage keeps those.

Drive the plan/spec/implement/review pipeline recorded in .orchestrator/state.json. Use when a planning session's plan has just been approved, when the user asks to start, advance, check, diagnose, redo, abort, or finish a flow, or runs /orchestrator:start, /orchestrator:next, /orchestrator:flow-status, /orchestrator:health, /orchestrator:redo, /orchestrator:abort, or /orchestrator:finish.

Write an orchestrator handoff file into .orchestrator/handoff/ so the next phase can start with fresh context. Use only from the orch-flow skill, at a phase boundary.

Plan a change with the user before any code is written - an interview in rounds that settles every decision and sharpens the project's domain language, ending in a plan the orchestrator can carry to a flow, a quick implementation, or a blueprint. Use when the user asks to plan a feature or change with the orchestrator ("plan this", "let's plan"), or runs /orchestrator:interview. Not for stress-testing an idea for its own sake.

Implement a small, already-understood change directly and hands-off, skipping the plan/spec/implement/review pipeline. Reached when a human picks "quick implementation" at hook-grilling.sh's closing question, runs /orchestrator:quick-implement [<issue>], or is invoked directly for work that plainly does not need the full flow. Still requires a linked issue - possibly rewritten from the plan, unattended - an unattended spec review, a published ticket breakdown, test-driven implementation, and a review pass before the PR opens.

Open the release PR that carries the base branch back into the default branch, closing every still-open issue whose work reached the base branch. Use when the human asks to release the base branch (for instance a uat or feature branch), or runs /orchestrator:release.

Run a base sync on demand - bring the current plugin-made branch (a flow's orch/ branch, including a done flow's, or a quick/ branch) up to date with its base branch by merging origin's tip of the base, inside or outside a flow. Starts a resolver on a conflict, corrects the PR body against the diff after a resolved conflict, records its Merge resolutions and the body corrections as one PR comment, and offers a review pass unless an active flow holds the branch. Use when a human runs /orchestrator:sync, or asks to catch a branch or PR up with its base.

Turn the current conversation into a spec - no interview, just synthesis of what has already been discussed, after one check of the test seams with the user - and either publish it as a new GitHub issue labelled for an agent, or, given a leading issue number (rewrite mode), rewrite that issue's body as the spec. A quick implementation reaches rewrite mode in its Unattended rewrite form, which asks nothing. Use from orch-flow's spec phase, from a planning session's Blueprint route, from quick implementation's step 1, or standalone when a user asks to write up or publish a spec, or runs /orchestrator:to-spec or /orchestrator:to-spec <n>.