agent-common
Shared preamble loaded by all cc10x agents — memory protocol, contract format, output rules.
Verification discipline: task completion is not goal achievement. Covers the gate function, self-critique gate, validation levels, evidence array protocol, and goal-backward lens. Loaded by integration-verifier, component-builder, and bug-investigator.
$ npx -y skills add romiluz13/cc10x --skill verification --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/verificationContext preview
The summary Claude sees to decide when to auto-load this skill.
Verification discipline: task completion is not goal achievement. Covers the gate function, self-critique gate, validation levels, evidence array protocol, and goal-backward lens. Loaded by integration-verifier, component-builder, and bug-investigator.
name: verification description: | Verification discipline: task completion is not goal achievement. Covers the gate function, self-critique gate, validation levels, evidence array protocol, and goal-backward lens. Loaded by integration-verifier, component-builder, and bug-investigator. allowed-tools: Read Bash Grep Glob user-invocable: false
**Task completion is not goal achievement.** Verify that the phase achieved its goal, not that prior agents said it did. If you cannot independently reproduce a claimed success, return FAIL.
COMPLETION → TRUTH → PROOF
1. **Completion:** Did the agent finish its task? (contract says PASS) 2. **Truth:** Is the work actually correct? (independent verification) 3. **Proof:** Can you prove it with evidence? (exit codes, test output, screenshots)
A PASS without proof is a claim. When a result surprises you in either direction — a pass that came too easily, or a failure you cannot explain — suspect the observation method before the system: confirm the check runs the right command against the current build and exercises the real code path before theorizing about the code.
<!-- Authoring rule (maintenance, not runtime): every gate in this skill encodes an observed failure mode; understand what a gate prevents before removing it. -->
Before running any test, audit your own work:
**Code Quality:**
**Implementation Completeness:**
**Self-Critique Verdict:** If any check fails, fix it BEFORE running verification. Don't run tests you know will fail on code quality issues — a known-failing run produces noise evidence that then has to be explained away.
| Level | What | Exit Code | When | | ------- | ------ | ----------- | ------ | | **Deterministic** | Automated test | 0/1 | Always — the default | | **Probabilistic** | Test with known flake rate | 0/1 (retry policy) | When deterministic impossible (timing, network) | | **Manual** | Human verifies with checklist | n/a | When automation not worth the cost | | **Live** | Production-like environment | 0/1 | When plan requires live proof |
Every verification must state its validation level — unlabeled evidence lets weak proof masquerade as strong. If manual, state the checklist. If deterministic, state the command + exit code. If live, state the harness command.
When the plan includes `### Live Verification Strategy` or a harness manifest:
**Flaky test handling:** re-run once — one retry separates environment blips from real flake; more retries launder genuine failures. Pass on re-run → mark PASS with `flaky: true`. Fail both → FAIL. Never convert flaky pass into unconditional confidence.
EVIDENCE:
scenarios:
- "[name] | Given [state] | When [action] | [command] → exit [code] | expected=[expected] | actual=[actual]"
regressions:
- "[test] → exit [code]: [result]"
edge_cases:
- "[case]: [command] → exit [code]: [result]"Every scenario needs non-empty Expected and Actual. Every scenario maps to exactly one EVIDENCE entry. SCENARIOS_PASSED must equal EVIDENCE.scenarios with exit 0 + Result=PASS. Run each check against the revision being verified; if the code changes after a check, re-run the affected scenarios before citing them. Record the tested identity with the evidence: the commit SHA, plus a patch or digest when the tree is dirty; evidence that does not identify the revision it was produced from is unverified, not PASS.
Walk backward from the goal to verify it was achieved:
1. **What was the goal?** (re-read the plan's exit criteria) 2. **What would prove it?** (name the specific evidence) 3. **Do I have that evidence?** (run the verification) 4. **Does the evidence actually prove the goal?** (not "tests pass" but "the tests test the right thing")
| Failure | What happens | Fix | | --------- | ------------- | ----- | | **False green** | Test passes without exercising the real code path | Test Honesty Gates (see integration-verifier) | | **Tautological check** | Expected value recomputed the way the code computes it, e.g. `expect(add(a, b)).toBe(a + b)` — passes by construction | Expected values come from an independent source of truth: a known-good literal, a worked example, the spec | | **Scope skip** | "All tests pass" but untested scenarios exist | Goal-backward lens: name every scenario, verify each | | **Stale evidence** | "Tests pass" but you didn't run them this session | Re-run. Evidence must be from THIS session. | | **Claim without proof** | "It works" with no command/exit code | Evidence array is mandatory for PASS | | **Pointer-as-proof** | Path cited as PASS without re-opening it | Re-open the artifact; if it does not show the claim, downgrade or re-run. Never cite it as PASS | | **Untested claim** | A scenario or claim the return never addresses | Mark it untested with its reason; never assume it passed | | **Environment escape** | Test fails with env signal (command not found, ECONNREFUSED) | Classify as
The Loop Engine for Claude Code — engineer the loop, not the prompt. 1 router · 9 agents · 16 skills · 4 workflows. Fail-closed gates, test honesty, anti-anchored review.
Repo: romiluz13/cc10x
Shared preamble loaded by all cc10x agents — memory protocol, contract format, output rules.
Greenfield architecture design: map functionality flows, draw components, design APIs, classify dependencies, plan observability. For multi-component, API,…
Implementation skill for writing production code with TDD. Covers the RED-GREEN-REFACTOR cycle, false-RED detection, vertical slicing, scope escalation, test…
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…
THE ONLY ENTRY POINT FOR CC10X. Activate this skill for build, debug, review, and plan requests. Use when the user asks to implement, fix, review, plan, test,…
Two-mode skill: (1) adversarial review — spec compliance + code quality + security, confidence-scored findings with file:line evidence; (2) receiving review —…