OPC — One Person Company

A full team in a single Claude Code skill. You're the CEO — OPC is everyone else.

16 specialist agents (PM, Designer, Security, Devil's Advocate, and more) that build, review, and evaluate your code through a digraph-based pipeline with code-enforced quality gates.

English | 中文

---

English

What you can build

From a single one-line brief, OPC's build-verify flow ships a complete, production-quality product — design tokens injected and visual quality validated by the design-intelligence extension. Every screenshot below is a real, clickable site (not a mockup), built by the same 16-agent pipeline. Same system, six completely different design languages.

▶ Browse the live lookbook →

<table> <tr> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/saas-dashboard/index.html"><img src="docs/assets/showcase/saas-dashboard.png" alt="Pulse — a SaaS analytics dashboard generated by OPC"></a> <br><b>Pulse</b> · SaaS analytics dashboard<br>_{Dark UI · data-viz} </td> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/creative-portfolio/index.html"><img src="docs/assets/showcase/creative-portfolio.png" alt="Studio Kura — a creative agency portfolio generated by OPC"></a> <br><b>Studio Kura</b> · Creative agency portfolio<br>_{Brutalist · editorial · motion} </td> </tr> <tr> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/cumulus/index.html"><img src="docs/assets/showcase/cumulus.png" alt="Cumulus — a SaaS project-management dashboard generated by OPC"></a> <br><b>Cumulus</b> · Project-management dashboard<br>_{Claymorphism · pastel} </td> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/devtool-docs/index.html"><img src="docs/assets/showcase/devtool-docs.png" alt="Conduit Docs — a developer documentation site generated by OPC"></a> <br><b>Conduit Docs</b> · Developer documentation<br>_{Docs · code · developer} </td> </tr> <tr> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/dtc-brand/index.html"><img src="docs/assets/showcase/dtc-brand.png" alt="Maison Terre — a DTC skincare e-commerce site generated by OPC"></a> <br><b>Maison Terre</b> · DTC skincare e-commerce<br>_{Brand · editorial} </td> <td width="50%" valign="top"> <a href="https://www.touchskyer.me/projects/opc/lookbook/local-booking/index.html"><img src="docs/assets/showcase/local-booking.png" alt="Yuzuki — a local dining platform generated by OPC"></a> <br><b>Yuzuki 柚月</b> · Local dining platform<br>_{Booking · bilingual · mobile} </td> </tr> </table>

Each card in the lookbook flips on hover to reveal the exact prompt that built it — e.g. Pulse came from one line: /opc build a production-quality SaaS analytics dashboard called "Pulse"...

OPC isn't only for UIs. The same zero-trust pipeline also handles:

• Whole products, unattended — /opc loop build features F1–F4 from PLAN.md decomposes the work, schedules a durable cron, and runs 10+ hours without you.
• Code review — /opc review the auth changes dispatches 2–5 independent role agents (security, backend, a11y, devil's advocate) in parallel and computes a mechanical verdict.
• Full-stack features — /opc implement user auth with email/password runs build → independent review → test-design → test-execute → gate.
• Pre-release audits — /opc verify before release runs acceptance + audit + e2e gates before you ship.

How It Works

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

Task → Flow Selection → Node Execution → Gate Verdict → Route Next
                              ↑                              ↓
                              └──────── ITERATE/FAIL ────────┘

1. Task inference — reads your request, picks a flow template (quick, review, build-verify, full-stack, pre-release), and enters at the right node.

2. Typed nodes — each node has a type (discussion, build, review, execute, gate) with specific protocols. Build nodes produce commits. Review nodes dispatch parallel subagents. Gate nodes compute verdicts from code, not LLM judgment.

3. Mechanical gates — verdicts are computed by opc-harness synthesize: any red = FAIL, any yellow = ITERATE, all green = PASS. No LLM gets to decide if a finding is "important enough."

4. Cycle limits — max 3 loops per edge, 5 re-entries per node, 20-30 total steps depending on flow. Oscillation detection catches A↔B loops.

Quality Architecture

The system is built on a zero-trust axiom: every critical output must have an independent verification path. Four layers:

• L0 — Zero Trust: Decision axiom — not code, not prompt. Every critical output needs an independent verification path.
• L1 — Shape Single Agent: Intervene during token generation — persona setting, anti-pattern tables, mandatory output structure, scope anchoring, quality gates.
• L2 — Design Agent Flow: Multi-agent coordination — separation of concerns, flow topology (parallel review / sequential build), context isolation (file-based handoff, fresh agents, no session reuse).
• L3 — Deterministic Enforcement: The only layer that doesn't need LLM compliance — mechanical ops (severity counting, verdict rules, oscillation diff) and hardened verification (file-finding evidence checks, hedging scans, ref validation).

Quick Start

Install

npm install -g @touchskyer/opc

Skill files are automatically copied to ~/.claude/skills/opc/.

Manual install (no npm)

git clone https://github.com/iamtouchskyer/opc.git
cp -r opc ~/.claude/skills/opc

Use it

# Review — dispatches 2-5 role agents in parallel
/opc review the auth changes

# Build — implements + independent review + gate
/opc implement user authentication with email/password

# Autonomous loop — decomposes, schedules cron, runs unattended
/opc loop build features F1-F4 from PLAN.md

# Interactive mode — asks clarifying questions first
/opc -i redesign the onboarding flow

# Explicit roles
/opc security devil-advocate

# Flow control
/opc skip          # skip current node
/opc pass          # force-pass gate
/opc stop          # terminate, preserve state
/opc goto build    # jump to node

Autonomous Loop

/opc loop build the math tutoring app features F1-F4

What happens:

1. Runbook lookup — opc-harness runbook match "<task>" checks --dir flag → OPC_RUNBOOKS_DIR → ~/.opc/runbooks/ for a matching recipe. If one hits, its units / flow / tier become the plan; otherwise fall through to step 2. Disable per-invocation with OPC_DISABLE_RUNBOOKS=1. See docs/runbooks.md and examples/runbooks/add-feature.md.
2. Decompose (runbook miss only) — breaks task into atomic units (spec, implement, review, fix, e2e)
3. Definition of done — establishes verify/eval criteria per unit before any work starts
4. Schedule — durable cron (survives process restart) fires every 10 min
5. Execute — each tick runs one unit through the appropriate OPC flow
6. Guard — opc-harness enforces: git commit required, ≥2 independent reviewers, no plan tampering, no state forgery, artifact freshness, tick limits
7. Terminate — auto-stops when plan complete, tick limit hit, or wall-clock deadline reached

For well-scoped tasks, the system runs 10+ hours continuously without intervention.

Guardrails (code-enforced, not prompt-level)

| Guard | Enforcement | |-------|-------------| | Write nonce | Random SHA256 at init; state written by harness only | | Atomic writes | write → rename (POSIX atomic); no truncated JSON on crash | | Plan integrity | SHA256 hash at init; verified every tick | | Review independence | ≥2 eval files, identical content rejected, line overlap warned | | Git commit required | HEAD must change for implement/fix units | | Screenshot required | UI units must produce .png/.jpg artifact | | Tick limits | maxTotalTicks (units×3) + 24h wall-clock deadline | | Oscillation detection | A↔B pattern over 4-6 ticks = warning/hard stop | | Concurrent tick mutex | in_progress status blocks overlapping cron fires | | JSON crash recovery | try/catch on all JSON.parse; structured errors, not crashes | | External validators | Pre-commit hooks, test suites detected at init and leveraged |

Flow Templates

| Template | Nodes | When | |----------|-------|------| | quick | build → review → gate | "quick fix", "small change", one-liner, ≤3 files, non-UI, no logic branches | | review | code-review → gate | PR review, audit, "find problems" | | build-verify | brief → build → code-review → test-design → test-execute; ITERATE → hotfix → test-execute; PASS → gate | "implement X", "fix bug Y" | | full-stack | discuss → build → review → test → acceptance → audit → e2e → gates | Complex/vague requests | | pre-release | acceptance → audit → e2e → gates | "verify before release" |

quick vs build-verify — quick drops the structured brief node and the test-design/test-execute split, halving nodes and evaluator dispatches. It keeps the core quality gate (independent review + gate verdict). Use it only for true one-liners / single-file, non-UI, no-logic-branch changes. Anything with logic branches, multiple files, or UI → use build-verify, where test-design's enforced L1–L5 coverage check earns its keep.

The brief node (entry of build-verify) produces a structured build brief — resolved design tokens, file plan, component inventory, cons