ORCH — built this to orchestrate the full coding task lifecycle that ends with a review gate

[oxgeneral]

What I built

ORCH — a TypeScript CLI runtime for orchestrating teams of AI coding agents.

How it connects to PR-Agent workflows

PR-Agent excels at reviewing pull requests autonomously. The gap I hit: who orchestrates the full lifecycle — from task assignment to code generation to the review step?

ORCH models this as a typed state machine:

todo → in_progress → review → done

The review step maps naturally to what PR-Agent does — but ORCH ensures no task bypasses it. An agent (or PR-Agent via webhook) must explicitly transition tasks through review.

Example workflow

1. ORCH assigns a coding task to a Claude Code agent
2. Agent completes → task enters review state
3. A review agent (or PR-Agent webhook) inspects the diff, transitions to done
4. If the coding agent crashes mid-task → retrying state, auto-restarted

orch task add "Add rate limiting to API" --assignee agt_coder
# after code is written:
orch task update tsk_abc --status review
# after review passes:
orch task update tsk_abc --status done

Details

• 1647 tests, TypeScript strict, MIT
• Adapters: Claude Code, OpenCode, Cursor, shell
• npm install -g @oxgeneral/orch

Repo: https://github.com/oxgeneral/ORCH

[momcilosavic1234567-creator]

Clean state machine. One thing worth being explicit about before code can leave review: what "a review agent inspects the diff" actually checks. If it's an LLM (PR-Agent or otherwise) reading the diff and forming an opinion, that's valuable but it's pattern-matching over text — it doesn't know your subquery can return NULL unless it's reading actual schema constraints, and it doesn't know a new route is missing auth unless it's diffing against the actual middleware registration, not just the file in front of it.

Two deterministic checks are worth wiring into the review → done transition alongside the LLM pass, not instead of it: route-table AST diffing (generate the registered-routes-plus-middleware-chain structure from the branch and from main, fail the transition if a new path lacks its expected guard) and execution-plan analysis on anything touching queries (EXPLAIN ANALYZE against prod-shaped fixtures — including the NULLs and skew your dev seed data won't have — failing on sequential scans past a threshold). Both are mechanical yes/no checks against the actual artifact rather than another model's read of the diff, so they catch the specific bug shape that's syntactically fine and passes every test but breaks under real auth or real data volume. Would slot in as a required check ORCH's webhook waits on before allowing the review → done transition, on top of whatever PR-Agent's own pass already does.

[IsmaelMartinez]

Thanks for posting this, and the state machine reads cleanly. One correction on the integration sketch: pr-agent has no outbound callback for "review finished", it publishes a comment and exits, so an ORCH webhook would be parsing published output rather than receiving a verdict. The nearest fit today is the push_outputs section, which emits the review record to a configured webhook sink without touching the git provider, and is probably the cleanest hook for your review to done transition. On the deterministic checks suggested above, I agree they belong at the gate, but they sit outside what pr-agent does and are ORCH's side of the boundary rather than ours.