orchestrate

Files (5)

• SKILL.md
• critic-prompt.md
• implementer-prompt.md
• profiles.md
• reviewer-prompt.md

SKILL.md (first lines)

# Orchestrate

Request: $ARGUMENTS

`qo` is already on PATH (plugin bin/). Run every `qo` command from the
project root as a single plain command — never `cd`, never chain with `;`,
`&&` or `|`, never look for the plugin directory.

Pure dispatch loop. Never read source files — only ledger output, contracts,
and schema files. Every dispatch passes only a task id and its brief
(≤600 chars), never run history.

## Procedure

1. **Start the run:** `qo run new "<request>"`.
2. **Decompose:** break the request into ≤7 tasks, each with a role, title,
   brief (objective/inputs/scope/output contract), scope glob, and
   dependencies. Add each with `qo task add`, e.g.:
   `qo task add --run <run> --role backend-dev --title "Add hello()" --brief "Implement GET /hello returning 200" --scope "backend/**" --depends <id>`
3. **Critic gate (mandatory):** dispatch `devils-advocate` on the full plan
   per `./critic-prompt.md`. Every objection must be resolved (edit the
   plan) or explicitly waived via `qo ruling` before step 4 proceeds. Read
   `./critic-prompt.md` only now, when dispatching.
4. **Dispatch ready tasks:** for each task with satisfied dependencies, run
   `qo task dispatch <id>` first, e.g. `qo task dispatch a9u17uyi` → `task
   a9u17uyi claim 1`. Put `QO-TASK <id> CLAIM <n>` as the first line of the
   prompt. Choose the model from `./profiles.md` (read it only now) using
   the run's profile (`--profile` arg or `.claude/q-orchestrate.json`).
   Dispatch via the Agent tool with `run_in_background: true`, using the
   template in `./implementer-prompt.md` (read only now, when dispatching).
5. **React to events:** on each `EVENT task <id> ...` line, run `qo events
   pull` to consume it, update dependency state, and dispatch the next
   ready task(s).
6. **Review each task:** after an implementer reports, dispatch a fresh
   reviewer per `./reviewer-prompt.md` (diff + brief only, never the
   implementer's transcript). On objections, re-dispatch a **fresh**
   implementer for the same task with the objections appended. Cap fix
   rounds at 3; round 3 re-dispatches with the escalated model from
   `./profiles.md`. Implementers never spawn reviewers.
7. **Merge:** in dependency order, `qo merge <task>` each worktree branch
   into `orchestrate/<run-id>`. A conflict becomes a new task, not a manual
   fix.
8. **Final QA + close:** dispatch a `qa-engineer` task covering the merged
   branch, print a ≤15-line run report from ledger state, then end with
   `qo run close` (`--status cancelled` if abandoned).

## Rulings, not stalls

Ambiguity, a plan defect, or a cap you would ask to exceed: record a
decision with `qo ruling` and continue. Only four conditions actually stop
the run:

- A destructive operation (`rm -rf`, force-push, `git push` to a shared
  branch).
- A security-sensitive action (credentials, auth, prod config).
- A side effect landing outside a task's assigned worktree.
- The plan is broken beyond guessing (contradictory deps, no valid
  decomposition).

## Rules borrowed from subagent-driven-development

- Fresh implementer subagent per task — never resume one across fix rounds.
- A dedicated reviewer per task, dispatched with a review package (diff +
  brief), never the implementer's transcript.
- Fix rounds capped at 3, with model escalation on the third per
  `./profiles.md`.
- Implementers and reviewers never spawn their own reviewers — that seat is
  always the orchestrator's to fill.

## What you never do

- Never `Read` application source files — only ledger tables (via `qo`),
  contracts, and schema files.
- Never hand-edit the ledger; all mutation goes through `qo`.
- Never dispatch without first running `qo task dispatch <id>`.

From Darkri-X/Q-Orchestrate, MIT.

More from Darkri-X/Q-Orchestrate