loop runs a fixed benchmark suite against prompt assets (skills/**/SKILL.md, commands/*.md, agents/*.md, templates/*.md) and promotes the best candidate only inside an isolated codex/loop-… branch. State is resumable in .data/state/loop-active.json; the leaderboard, score history, and winner diff land in .captures/loop-<run_id>/.

/scc:loop list-suites
/scc:loop run write-core --targets skills/write/SKILL.md --parallel 2 --max-generations 2

evolve closes the ring on top of it. When the same gate keeps failing, it harvests those real failures, has the maintainer hand-author the structural check, then hands the asset to the unmodified loop engine. The optimizer never writes its own success criterion, and merging the winner stays a manual decision after reading winner.diff.

/scc:evolve list-failures
/scc:evolve harvest <id> --assertion '/scc:'
/scc:evolve run evolve-<id>

Full design and its adversarial-review history: evolve-ouroboros-spec.md.

--external adds cross-model review through MMBridge (Kimi, Qwen, Gemini, Codex) behind an adapter protocol, so tests keep a deterministic stubbed path. Real external runs need separate setup, and they send the draft to those providers — leave it off for anything confidential.

Every phase transition writes its artifact to .data/cycles/cycle-NNN/<phase>.md and logs the decision to that cycle's events.jsonl. No manual saves.

When a run starts it reads .data/cycles/insights.json first, so it begins with what earlier runs learned. Insights older than 30 days decay in rank, and a category that keeps producing critical findings gets written up as a gotcha proposal for the maintainer to promote into a checklist.

.data/cycles/
├── cycle-001/
│   ├── plan.md / do.md / check.md / act.md
│   ├── metrics.json
│   └── events.jsonl
└── insights.json

pdca_start_run(domain=…) loads a different contract set from config/stage-contracts.json, defining entry criteria, exit criteria, and Definition of Done per phase.

The code domain runs the Code Engineering Lane — the same four phases, tightened around executable acceptance criteria, worker/validator separation, human approval for broad changes, and an explicit handoff state.

pdca_transition returns one of three outcomes: PROCEED, REFINE (bounded improvement round), or PIVOT (wrong phase — re-enter elsewhere, with retry caps).

Cost-optimized, not all opus: 4 opus / 11 sonnet / 2 haiku. Each agent has a focused prompt and limited tools — the writer has no web search, the reviewers don't write. Pokemon names because "Xatu found a logic gap" is easier to track in a log than "reviewer-3 found issue."

When a cycle reaches Act, session-end prints a summary box to the terminal:

┌─── PDCA Cycle #2 ───┐
│ Plan ✓  Do ✓  Check ⚠  Act ✓  │
│ Time: 4m  Issues: 3  Score: 74 │
└────────────────────────────────┘

Check shows ✓, ⚠, or ✗ depending on the verdict; score is 0–100.

It also writes a self-contained HTML dashboard to .data/reports/cycle-N.html (plus a .mmd flow diagram) with the phase timeline, every issue the reviewers raised, and the next action — and prints the path. Generated by hooks/lib/report-generator.mjs, so a finished run leaves a persistent artifact instead of terminal scrollback.

Hooks fire automatically; you never call them. SessionStart initializes state, UserPromptSubmit runs the auto-router, SubagentStart injects review context into the agent, SubagentStop aggregates reviewer consensus, Stop saves output and cleans up, StopFailure blocks delivery when the Check gate fails, and PreCompact/PostCompact serialize and restore state so a compacted session resumes mid-cycle instead of restarting.

The router checks compound intent first: "research and write" matches there and routes to pdca immediately — the cycle is the thing that adds review and correction. Only single-purpose prompts continue to skill scoring and external plugin dispatch.

A dedicated pdca-state MCP server (stdio) exposes 31 tools across PDCA state, cycle memory, soul, project memory, daemon control, session recall, and plugin orchestration. Every transition, gate decision, review score, and action route is event-sourced, so run history is queryable and recurring failure patterns are visible.

Full tool reference: docs/architecture.md.

The orchestrator scans ~/.claude/plugins/ at session start and maps what it finds to PDCA phases. If you have coderabbit installed, "코드 리뷰해줘" dispatches there instead of running the built-in reviewers. commit-commands catches "커밋해줘." Install a plugin and it appears; uninstall it and it's gone. No config files.

With none installed, nothing degrades — the orchestrator finds no match and the built-in reviewers, writer, and committer handle it.

One thing is pinned rather than discovered: which plugin each intent prefers. INTENT_PROFILES ships with review → coderabbit, act → commit-commands, design → frontend-design, memory → claude-mem. Drop a plugin-preferences.json into CLAUDE_PLUGIN_DATA to override it, or an empty array to remove the pin.

daemon_start_background_run returns the command that starts the work; it doesn't run anything itself.

claude --bg "/scc:workflow run weekly-digest"
claude agents

That's deliberate. Claude Code already ships background agents, and reimplementing them in a plugin would mean worse lifecycle handling and no crash recovery. The stronger reason is consent: this plugin gates publishing, pushing, and sending mail behind approval in the conversation, and a background executor has no conversation in which to ask.

Auto-selected from your prompt, or name one directly:

/scc:analyze porter "cloud infrastructure market"
/scc:analyze rice --input features.md