orchestrate-project
Orchestrate project
Run a Notion project's ticket graph to completion as a single stacked PR chain. Read the project's dependency DAG, agree the plan with the operator, then launch one T3 worker thread per ticket on a branch cut from the branch below it, keep the stack rebased as its bottom merges, and keep Notion's Status in step, waking yourself as GitHub changes.
Arguments: $ARGUMENTS is the Notion project URL, then an optional phase (default tick, or bootstrap when no ledger exists yet).
Who does what
| Owns | Leaves to others | |
|---|---|---|
| Orchestrator | The queue: launches, restacks, Notion Status, the ledger |
Code, PRs, and every conversation after bootstrap |
| Worker | One ticket's branch, its PR, and that PR's babysitting | Merging, and every other branch |
| Operator | Scope and gates at bootstrap; then each worker directly; every merge |
Bootstrap is where you get in step with the operator. After it you run unattended: wake on GitHub, act, re-arm, sleep. The operator talks to each worker in its own thread — "create a PR", review feedback, a rename — and never needs to answer you. Each tick ends with a short report in this thread, a log the operator reads when they choose. Something only a human can resolve, such as a restack conflict, already surfaces in that worker's thread; name it in the report and carry on with everything else.
Merging is human-gated at Neighbor. PRs squash into staging on a person's click, so throughput is not yours to raise. Your job is queue management: keep the frontier launched, keep the ledger true, keep Notion honest.