By name: code-standards description: Dispatch independent adversarial reviews for ZFC, ZFC leveling, root-cause-first, and thermo without duplicating their standards.
Code Standards
Use this skill to dispatch code, diff, PR, or proposed-implementation review against the repo's core standards. This is a pointer/dispatch skill: reference the source skills below instead of duplicating their standards.
Iron Law
NO REVIEW LANE PASSES WITHOUT VERIFICATION EVIDENCE A lane returning PASS must include the specific file/line evidence that proves compliance. A lane returning FAIL must include the exact location and required fix. Rationalizations are not evidence.
This Iron Law mirrors the superpowers systematic-debugging principle: if you can't point to the exact line, the lane hasn't completed its work.
Source Skills
Load the relevant source skills by path and treat them as authoritative.
Path resolution: Prefer personal overrides from ~/.claude/skills/
when they exist, then fall back to the repo-local project skills listed below.
The repo-local .claude/skills/ paths are authoritative for a normal checkout
because they are versioned with this repository. The .codex/skills/ directory
contains pointer/mirror files for Codex-based agents and is not the primary
lookup path.
|- .claude/skills/zero-framework-cognition/SKILL.md (/zfc)
|- .claude/skills/zfc-leveling-roadmap/SKILL.md (/zfclevel)
|- .claude/skills/root-cause-first/SKILL.md (/root-cause-first)
|- .claude/skills/code-quality/SKILL.md (/code-quality, alias /cq) — metric-driven complexity / duplication / coupling / AI-import verification. Out of scope: syntax, naming, formatting, lint rules (those are linter territory, see "Lane ownership" below).
|- Thermo-nuclear: invoke via Agent tool with subagent_type: thermo-nuclear-code-quality-review (/thermo). This is an Agent tool subagent type, not a bash command or external process.
Lane ownership (no overlap)
Each lane has a defined scope. A lane must hand off — not duplicate — work that belongs to a sibling lane.
| Concern | Owner | Why |
|---|---|---|
| Syntax, formatting, import order, lint rules | ESLint / Ruff / mypy / prettier / pre-commit hooks | Mechanical, deterministic, already enforced in CI |
| Naming conventions, file layout | /code-standards style lane + linters |
Project conventions, not metric-driven |
| Logic, architecture, complexity, duplication, AI-import verification | /code-quality |
Metric + pattern reasoning |
| ZFC contract, agent routing, structured fields | /zfc |
Domain semantics |
| Level-up / XP / reward semantics | /zfclevel |
Game-loop semantics |
| Root-cause-first methodology for fix proposals | /root-cause-first |
Debugging discipline |
| Holistic adversarial review | /thermo |
Independent subagent model |
If a finding would belong to another lane, the current lane must name the correct lane and stop rather than produce feedback that conflicts with it.
SUPERPOWERS INTEGRATION (from obra superpowers framework):
- systematic-debugging iron law: Find root cause before proposing fixes. Applied here: a FAIL without file/line evidence is incomplete work.
- verification-before-completion: Before claiming PASS, verify with grep/read. Applied here: lanes must cite specific evidence, not assume compliance.
- finishing-a-development-branch verification: Tests → verify → present options. Applied here: each lane must run verification commands and report actual output.
Workflow
- Define the scope from the command argument. If no argument is provided, review the current diff or active PR context.
- Dispatch five adversarial, independent review lanes every time:
/zfc,/zfclevel,/root-cause-first,/code-quality, and/thermo. Each lane has a defined scope — see "Lane ownership" below. - Give each lane only its scope, the relevant source skill path, and the instruction to look for blockers with file/line evidence. Do not paste or restate the full standard into the prompt.
- For Claude callers, use a Codex subagent or Codex reviewer plugin for at least one independent lane when available, so one reviewer is not relying on the same model/context as the caller.
- The
/thermolane usessubagent_type: thermo-nuclear-code-quality-review(NOT a bash command). Pass: diff summary, file list, working dir. - Require every lane to report PASS/WARN/FAIL, evidence, required fixes, and any N/A caveats. A lane may return N/A for a subsection only if the source skill permits that; the lane itself still runs.
- Reconcile the lane results into one practical report. Do not dilute a FAIL from any required lane into a PASS.
Systematic Debugging Integration
Each lane follows the four-phase process from systematic-debugging:
- Root Cause Investigation: Read errors, check recent changes, trace data flow
- Pattern Analysis: Find working examples, compare against references
- Hypothesis and Testing: Form theory, test minimally
- Verification: Verify fix works before claiming success
Applied to code review:
- Lane sees a symptom → investigates to find root cause (not just flags symptom)
- Lane proposes fix → traces to exact file/line that needs change
- Lane returns PASS → cites grep/read evidence proving compliance
Test Coverage Gate
For any PR touching production code (non-test files):
- Enforce: New production code requires corresponding tests
- Verification: The reviewer runs test commands when execution access is available; otherwise, the reviewer must cite CI run output or require the PR author to provide test execution evidence.
- TDD integration (from superpowers TDD skill):
- If tests don't exist, FAIL with "No tests for changed production code"
- If test coverage dropped, FAIL with specific uncovered areas
- Note: TDD write-first compliance is a development-time practice and cannot be verified post-facto from PR state alone. Do not WARN or FAIL based on assumed write order without CI evidence of the sequence.
Prompt Placement Gate
Behavioral prompt prose belongs in $PROJECT_ROOT/prompts/ markdown files, not in
Python string literals. Python may assemble deterministic structured context,
load prompt files, and substitute explicit placeholders such as current time or
location, but it must not embed new model instructions, behavioral rules, or
audit criteria inline. If a review finds inline prompt prose added or expanded
in Python, mark /code-standards FAIL unless the PR moves that prose into a
prompt file or documents why the text is purely deterministic formatting.
Report Format
Return a concise report:
## Code Standards Report
Scope: <file, diff, PR, or task>
- ZFC: PASS/WARN/FAIL - <evidence>
- ZFC leveling: PASS/WARN/FAIL - <evidence or permitted N/A caveat>
- Root-cause-first: PASS/WARN/FAIL - <evidence or permitted N/A caveat>
- Code-quality: PASS/WARN/FAIL - <evidence or permitted N/A caveat (see "Short-circuit clauses" in code-quality/SKILL.md)>
- Thermo: PASS/WARN/FAIL - <evidence or structural blockers>
Blockers:
- <line-level issue and required fix>
Test Coverage:
- <test command run and output, or CI evidence reference>
- PASS/FAIL for test coverage gate
Next checks:
- <tests, evidence, or review steps needed>
Iron Law Enforcement:
- If there are no blockers, say so explicitly and list any residual risks
- Do not mark any of the five lanes as skipped
- A PASS without file/line evidence is treated as INCOMPLETE (continue investigation)
Anti-Rationalization Checks
From systematic-debugging rationalization tables:
| Rationalization | Reality |
|---|---|
| "Tests are obvious, no need to verify" | Test existence ≠ test correctness |
| "Code is simple, review is optional" | Simple code has simple bugs with simple root causes |
| "I'll verify later" | Later = never; verification must be in this session |
| "Close enough to pass" | A FAIL is a FAIL; reconcile by fixing, not diluting |
If you catch yourself thinking any of these, stop and complete the verification step.