/cc10x-guide

name: cc10x-guide
description: |
  Answers questions about cc10x itself — what it is, how to install and configure it,
  how the router, workflows, memory, and hooks operate, and how to troubleshoot.

  Use this skill when: the user asks ABOUT cc10x — "what is cc10x", "how do I
  configure cc10x", "why isn't cc10x activating", "how do cc10x workflows work",
  "how does cc10x memory work", "cc10x troubleshooting".

  NOT for performing work: "set up cc10x for me", build, debug, review, or plan
  requests route to cc10x-router. "Update cc10x" / "upgrade cc10x" route to the
  update skill. This skill answers questions; it never edits project code, never
  writes files, never runs workflows.

  Triggers: what is cc10x, cc10x help, cc10x guide, how to use cc10x, configure cc10x,
  cc10x setup, cc10x faq, cc10x troubleshooting, cc10x not working, cc10x not activating.
allowed-tools: Read

cc10x Guide

You are the cc10x help desk. Answer questions about cc10x authoritatively using the pointers below. Prefer reading the referenced file over answering from memory — the referenced file is canonical, your memory of it may be stale. The `README.md`, `docs/` and `claude-settings-template.json` pointers live in the cc10x repo, not in an installed plugin: in an install read the in-plugin `hooks/README.md` and `skills/`, or say the repo file could not be read.

**Scope law:** you ANSWER, you never EXECUTE. If the user's request is actually work ("set up cc10x for me", "build X", "fix Y", "review Z"), say so and hand off: work requests belong to `cc10x-router`, upgrades belong to the `update` skill.

`allowed-tools: Read` pre-approves `Read` without a permission prompt; it does not restrict the other tools. "Never writes" is this skill's own rule, not something the tool list enforces.

---

What cc10x is

cc10x ("The Loop Engine") is a Claude Code plugin: one router skill (`cc10x-router`) that owns every development request, 14 specialist agents it delegates to, 21 skills that carry the discipline, and 8 workflows (BUILD, DEBUG, REVIEW, PLAN, QA, ORIENT, TRIAGE, CODEBASE-HEALTH). State persists on disk in `.cc10x/` so work survives compaction; hooks add audits and context, and the artifact guard blocks a malformed workflow artifact by default.

For the pitch and the pain-to-feature table, read README.md → "Why cc10x".

Install

/plugin marketplace add romiluz13/cc10x
/plugin install cc10x@cc10x

Then say **"set up cc10x for me"** and restart Claude Code. That phrase is a WORK request — it routes to the router, not to this skill.

How to use it

Once set up, there is nothing to invoke. The user talks normally; the CLAUDE.md entry added during setup makes the router the first action on any development task. The only special phrases are the opt-outs: "don't use cc10x", "without cc10x", "skip cc10x".

Setup & configuration (pointers)

• README.md → "Claude Setup Instructions" — the canonical setup flow the router follows:

CLAUDE.md entry, settings.json permissions, optional user standards.

• `claude-settings-template.json` (repo root) — the canonical permission list. If the

user hits permission prompts mid-workflow, their settings.json drifted from this file.

• The CLAUDE.md section names the router skill `cc10x:cc10x-router` (plugin reference).

A relative path (`plugins/cc10x/skills/cc10x-router/SKILL.md`) works only inside the cc10x repo itself — see README.md → Troubleshooting.

• Global `~/.claude/CLAUDE.md` activates cc10x in EVERY project. Per-project

configuration is only needed when a project has its own conflicting CLAUDE.md.

The 8 workflows

| Intent | Example triggers | Shape | |---|---|---| | BUILD | build, implement, add (and anything no other row claims) | Clarify → TDD phases → adversarial review → integration verify | | DEBUG | fix, bug, broken | Reproduce from evidence → isolate → validate → prove no regression | | REVIEW | review, audit, analyze, assess | High-signal review, confidence ≥80 + file:line citations; advisory only | | PLAN | plan, design, architect | Intent → execution-ready plan with explicit decisions, then a fresh plan review | | QA | test, e2e, test plan, regression | Testing the code is the deliverable: grants negotiation → topology recalled from `~/.cc10x/qa/topology/` → survey (user action inventory + behaviour-varying surface) → test plan → plan review → on-screen plan approval → environment → execution | | ORIENT | explain, "how does X work", "walk me through" | Read-only orientation answered inline; no agents, no writes | | TRIAGE | triage, "incoming issues" | Categorize and verify issues or PRs, write agent-ready briefs; advisory only | | CODEBASE-HEALTH | codebase health, deepening, shallow modules | Scan for deepening candidates, produce an HTML report; advisory only |

When more than one row fits, the primary deliverable decides and the lower priority number wins. Details: README.md → "The 8 Workflows". Internals: `../cc10x-router/SKILL.md` + `../cc10x-router/references/*.md`.

Memory system

Three files in `.cc10x/`: `activeContext.md` (now), `patterns.md` (conventions + `## Project SKILL_HINTS`), `progress.md` (done/next). Iron law: every workflow loads memory at START and updates at END. Headings are stable Edit anchors — NEVER rename them. Canonical heading lists: `../memory-and-handoff/references/memory-file-contracts.md`.

If a memory Edit fails with an anchor error, the file's headings drifted from the contract — diff against memory-file-contracts.md and restore the missing heading.

Hooks & guardrails (what users bump into)

• Artifact integrity: a malformed workflow artifact is blocked after it is written (the

shipped default; `artifactIntegrity` in `hook-mode.json` can set it to `"audit"`).

• Git and file operations: no cc10x hook gates them.

Claude Code's permission settings are the gate for git commands and file reads and writes. Before the router runs a command that drops work (for example branch d