/opc

name: opc
version: 0.10.2
description: "OPC — One Person Company. Digraph-based task pipeline with independent multi-role evaluation. Builds, reviews, analyzes, and brainstorms with specialist agents. Every path ends with evaluation. /opc <task>, /opc -i <task>, /opc <role> [role...]"

OPC — One Person Company

One principle: **the agent that does the work never evaluates it.**

A full team in a single skill. The digraph engine handles any task — building code, reviewing code, analyzing problems, brainstorming designs. It infers which flow and entry point to use from the task itself, and every path ends with independent evaluation.

Invocation

**Harness path:** The `opc-harness` binary lives at `bin/opc-harness.mjs` relative to this skill's install directory. Resolve it once at session start:

OPC_HARNESS="$HOME/.claude/skills/opc/bin/opc-harness.mjs"

All `opc-harness` references below mean `node "$OPC_HARNESS"`. Set this as a shell variable and reuse it throughout the session.

/opc <task>              # auto mode — infer flow and roles from the task
/opc -i <task>           # interactive mode — ask questions before dispatch
/opc <role> [role...]    # explicit roles — skip role selection, dispatch directly
/opc loop <task>         # autonomous loop — decompose, schedule cron, run 24h unattended
/opc skip                # skip current node, advance via PASS edge
/opc pass                # force-pass current gate
/opc stop                # terminate flow, preserve session state
/opc goto <nodeId>       # manual jump to a node (cycle limits still enforced)

Task Inference + Flow Selection

The orchestrator reads the task, selects a flow template, and determines the entry point.

| Task says... | Flow template | Default entry | |---|---|---| | "review", "audit", "check", "before we merge", "找问题", "开源前看看" | review | review | | "analyze", "diagnose", "what's wrong with", "分析" | review | review | | "build", "implement", "create", "fix bug", "帮我实现", "重构成..." | build-verify | brief | | "quick fix", "small change", "one-liner", "patch", "trivial fix", "快速修复", "小改动" | quick | build | | "brainstorm", "explore options", "what are the approaches", "有什么方案" | build-verify | brief | | "plan", "decompose", "break this down", "scope", "estimate", "拆一下" | build-verify | brief | | "verify", "test", "QA", "check before release", "发布前验收" | pre-release | acceptance | | "post-release", "user test", "onboarding check", "用户验收" | pre-release | acceptance | | Complex, vague, or multi-keyword request | full-stack | discuss | | `/opc loop` or multi-unit feature backlog | **loop-protocol** | plan decomposition |

**Entry override** — user context can shift the entry point (only if target ∈ template nodes):

| User has... | Entry override | |---|---| | A vague idea or brief | First node in template | | A spec or design doc | brief (if ∈ template), else build | | An implementation plan | brief (if ∈ template), else build | | A qualified build-brief.md from prior run | build (skip brief if lint passes) | | Code/artifact that needs evaluation | review, code-review, or test-design (if ∈ template) | | Everything done, needs acceptance | acceptance (if ∈ template) |

**Priority rules:**

• `/opc loop <task>` = enter autonomous loop mode. Follow `./pipeline/loop-protocol.md`: first check `.opc/runbooks/` for a matching runbook, otherwise decompose task into units. Initialize loop state, start cron, execute ticks. Each tick runs the appropriate OPC flow for that unit type.
• `/opc <role> [role...]` without a task = review of current codebase using review flow with named roles.
• `/opc` with no arguments = prompt user to describe their task.
• If task matches multiple rows, prefer the flow that includes build — code changes must precede review.

Show triage result:

📌 Flow: {flow template name}
📍 Entry: {entry node}
⚡ Interaction: auto / interactive
Rationale: {1 sentence}

**Override:** If user explicitly names a task type, respect that. Users can adjust after seeing triage.

Flow Templates

Flow graph structures (nodes, edges, limits) are defined in `opc-harness` code. The orchestrator uses `opc-harness route` to determine next nodes — **do not look up edges yourself**.

Each template below describes which agents to dispatch at each node and which protocol to use.

legacy-linear

Equivalent to v0.4.x behavior. Used as internal fallback only.

| Node | Type | Agents | Protocol | |------|------|--------|----------| | design | discussion | [planner] | design exploration | | plan | build | [planner] | task decomposition | | build | build | [implementer] | implementer-prompt.md | | evaluate | review | [selected roles] | role-evaluator-prompt.md | | deliver | build | — | commit + report |

review

| Node | Type | Agents | Protocol | |------|------|--------|----------| | review | review | [selected roles] | role-evaluator-prompt.md | | gate | gate | — | gate-protocol.md |

Gate loopback: FAIL/ITERATE → review (multi-round with prior findings as context). Review is not limited to code — it evaluates any artifact: architecture proposals, documents, strategies, products.

build-verify

| Node | Type | Agents | Protocol | |------|------|--------|----------| | brief | brief | [architect] | brief-protocol.md | | build | build | [implementer] | implementer-prompt.md | | code-review | review | [selected roles] | role-evaluator-prompt.md | | test-design | review | [tester, + user/domain roles] | test-design-protocol.md | | test-execute | execute | [orchestrator] | executor-protocol.md | | gate | gate | — | gate-protocol.md |

**test-design** is a review node where multiple roles design test cases (API tests, E2E UI tests, edge cases) without executing them. **test-execute** runs the designed test plan and captures evidence. Principle: *the person who decides what to test must not be the person who runs the tests.*

quick

| Node | Type | Agents | Protocol | |------|------|-------