orc

orc — Orchestrated Agentic Workflows for Claude Code

A Claude Code plugin that provides structured, multi-agent workflows for non-trivial code changes. Plan collaboratively, then execute autonomously with parallel quality gates.

The Flow

Multi-PR feature:
/orc:decompose → approve → then per step ↓

Single PR:
/orc:plan → approve → /orc:tasks → confirm → /orc:execute → /orc:submit
                          │                       │               │
                   creates branch          worker → review    push → PR → self-review
                   (if needed)             gates → commit          │
                                                            findings? → fix → /orc:submit
                                                            clean? → ready for human review
                                                                       │
                                                              /orc:pull-comments
                                                                       │
                                                              triage → fix → /orc:submit

Direct task:
/orc:execute <task> → review gates → commit → /orc:submit

Eight skills. Five specialised agents.

Phase	Skill	What happens
Decompose	/orc:decompose	Break a feature into PR-sized steps — clarifies boundaries with you first
Plan	/orc:plan	Explore codebase → clarify ambiguity → produce plan → critical review → present for approval
Branch	/orc:branch	Create a feature branch (invoked by /orc:tasks or directly)
Tasks	/orc:tasks	Branch setup → create tasks with acceptance criteria from the plan
Execute	/orc:execute	For each task: worker implements → three parallel review gates → commit
Submit	/orc:submit	Push → create/update PR → self-review → triage findings
PR	/orc:pr	Create or update a PR with project convention detection (invoked by /orc:submit or directly)
Review	/orc:pull-comments	Fetch external PR comments → categorise → triage → route to next step

For simple, direct tasks: /orc:execute <task> skips planning and creates a single task inline.

For Larger Features

When work spans multiple PRs, start with /orc:decompose to break the feature into ordered, independently shippable steps. After approving the decomposition, run each step through the standard /orc:plan → /orc:tasks → /orc:execute → /orc:submit cycle.

Agents

Agent	Role	Used by
worker	Implements code for a specific task	/orc:execute
plan-reviewer	Critiques plans for flaws before execution	/orc:plan
code-reviewer	Checks code against project CLAUDE.md conventions	/orc:execute
semantic-reviewer	Checks naming clarity and comment accuracy	/orc:execute
validator	Runs tests and type checks	/orc:execute

The Review Gates

After the worker implements each task, three agents run in parallel:

worker (implement)
       │
       ▼
┌──────────┬───────────┬───────────┐
│  code-   │ semantic- │ validator │
│ reviewer │ reviewer  │           │
└────┬─────┴─────┬─────┴─────┬─────┘
     │           │           │
     ▼           ▼           ▼
  PASS/FAIL   PASS/FAIL   PASS/FAIL

All PASS → commit
Any FAIL → worker fixes → all three re-run

They check orthogonal concerns — conventions, naming, and correctness — so all three must re-run after any fix.

Verification

Plans include a Verification Plan — concrete, product-level scenarios that prove the feature works end-to-end. These aren't restated unit tests; they're things a human (or integration test) can run against the system:

• "User clicks logout → redirected to login page"
• "Run curl localhost:3000/api/health → 200 OK"
• "Submit form with empty required field → inline validation error appears"

/orc:tasks creates a final verification task (blocked by all implementation tasks) that the validator runs after everything is built. Manual-only scenarios are flagged without blocking.

Interactive Clarification

Both /orc:decompose and /orc:plan pause after codebase exploration to check in with you when:

• Requirements are ambiguous (2x+ effort difference between interpretations)
• Multiple viable approaches exist with meaningful trade-offs
• Decomposition boundaries aren't obvious from the code
• Acceptance criteria can't be defined from the information available

When everything is clear, the step is skipped automatically — no unnecessary interruptions.

Submitting

Once all tasks pass their review gates and are committed, /orc:submit handles the PR lifecycle: