From cadence
Substance review of an existing design or plan. Reads doc(s); reports on accuracy, internal consistency, completeness, hidden assumptions, contradictions, scope creep. Does NOT review code quality (that's /c-find-bugs) but narrowly verifies plan-cited paths/symbols/imports exist in the codebase. Default: substance only. --format flag adds Cadence compliance checks for hand-imported or hand-edited artifacts. Output never modifies the reviewed doc; report stays in chat.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cadence:c-checkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You review designs and plans for substance — does this make sense, does it hang together, are there gaps, are there silent assumptions that won't survive contact with reality. You do NOT review code quality (that's `/c-find-bugs`). One exception: when the target is a plan, you narrowly read code to verify cited paths/symbols/imports exist — enforcing `/c-plan`'s "Codebase verification" rule fro...
/c-checkYou review designs and plans for substance — does this make sense, does it hang together, are there gaps, are there silent assumptions that won't survive contact with reality. You do NOT review code quality (that's /c-find-bugs). One exception: when the target is a plan, you narrowly read code to verify cited paths/symbols/imports exist — enforcing /c-plan's "Codebase verification" rule from the outside.
/c-check <design-folder-path> — review full design./c-check <plan-folder-path> — review full plan./c-check <single-doc-path> — review one child doc in isolation./c-check --format <path> — also run Cadence format compliance./c-check --any <path> — accept paths outside Cadence's expected folder structure (e.g. imported designs from elsewhere).Refuses when: path doesn't exist; OR path is in a Cadence-managed location (under paths.designs or paths.plans from .cadence/config.yaml) but lacks the expected structure (no overview, missing frontmatter) — unless --any is set.
Each check runs as its own sub-agent in parallel (via Task tool). Each receives the target doc(s) + the check's specific prompt.
| Check | What it asks |
|---|---|
| Accuracy | Do the claims in this doc match related artifacts (linked design ↔ plan, internal cross-references)? |
| Internal consistency | Do sections contradict each other? Do decisions in the overview match what children actually say? |
| Completeness | Are there obvious gaps — missing failure modes, undefined terms, untouched concerns (security, observability, perf)? |
| Hidden assumptions | What is the doc taking for granted that won't be true? (e.g. "user is logged in" without saying when login happens.) |
| Scope discipline | Does the design/plan stay within brainstormed scope, or has it crept? |
| Internal logic | Logical errors in proposed flow — race conditions, infinite loops, ordering violations. |
| Open-questions check (Invariant 1) | Any callouts that read like open questions ("should we…", "we might…", "TBD")? |
| Codebase verification (plans only) | Do the file paths, line ranges, symbols, and imports cited in the plan exist in the current code? Per /c-plan's "Codebase verification" rule: ls/Read every Modify and Test path; Read cited line ranges; grep every symbol and import path; check codebase conventions match. Citation that doesn't resolve = Critical (plan unexecutable as written). Range drift that still points at the right function = Important. Convention mismatch (_lambda vs lambda_, etc.) = Important. Skipped for designs. |
| DAG soundness (plans only) | Do two tasks that reference each other's Touches: files or declared symbols have a Depends: edge between them? A missing edge between mutually-referencing tasks is a parallel-execution hazard the Touches: guard can't catch — flag as Important (the engine could co-schedule them and the dependent task would run against absent code). Also flag any Depends: cycle as Critical (plan unexecutable). Skipped for designs. |
--format mode (Cadence compliance)Adds these additional checks (each as its own sub-agent):
frontmatter.required in config).skills/_shared/obsidian-format.md).These duplicate what /c-design and /c-plan already run in their self-review passes. --format is for artifacts coming from outside Cadence or hand-edited after a status flip.
skills/_shared/config-resolution.md).Task) with the doc(s) + the check's specific prompt + the expected output shape.Advisor opt-in: like /c-brainstorm, can offer to consult configured advisor agents when checks raise architectural concerns. Off by default.
Same shape as /c-find-bugs and /c-audit (consistency is load-bearing).
# /c-check: <design or plan path>
# Mode: substance | substance+format
<one-paragraph plain-English summary of whether this doc is ready for the
next phase (design → approved, plan → execute), written for a non-code-reader>
## Critical (must fix before approval)
- `<section>:<line>` — <plain-English finding>. Fix: <direction>.
## Important (should fix)
- `<section>:<line>` — <plain-English finding>. Fix: <direction>.
## Minor (consider)
- `<section>:<line>` — <plain-English finding>. Fix: <direction>.
## What's working
- `<section>` — <one-line note on what's done well>
## Recommended next action
<one specific sentence: "Ready to flip to in-review" / "Fix the N critical items, then re-review" / etc.>
"What's working" is mandatory (calibration). A review that only criticizes is uncalibrated.
"Recommended next action" is mandatory — one specific sentence, no hedging.
Apply conservatively. Default to Important when uncertain — Critical is reserved for things that block the next phase outright. Sub-agent prompts dispatched by this skill must include this calibration verbatim so individual lenses don't drift upward.
Files: list contradicts the change description; a plan task is impossible to execute as specified; a contradiction inside the same doc with no obvious resolution.Sub-agent heuristic: if a thoughtful developer could finish the task by picking one interpretation and noting the choice in the PR, it's Important. If they'd have to stop and ask the user, it's Critical. When in doubt between two tiers, pick the lower one.
After the report is printed, ask via AskUserQuestion how to handle findings. Default is report-only; any application path is opt-in. Per [[designs/2026-05-17-cadence/00-overview#Decisions log]] TUI decision.
Hard gate — every
AskUserQuestion, no exceptions: (1) thequestionopens with a plain-English lead a newcomer could follow — what's being decided and why it matters now; (2) exactly one option is marked(Recommended)and listed first — triage / "which next?" menus included ("your call" is a non-answer); (3) each option'sdescriptiongives the one-sentence trade-off. Full spec:skills/_shared/ask-user-question.md.
This is load-bearing when there are many findings: by question 14/17 the user no longer has the report in view, so the question text is their only context.
Entry question (single AskUserQuestion):
(Recommended) option when the fix is a direction-style choice).When a tier is being auto-applied (no per-finding prompt):
(Recommended) option silently and apply it.Auto-applied: <section>:<line> — <what was changed>) so the user can scan the batch and revert anything that looks wrong.Auto-applied N findings (M one-liner, K direction-with-recommended). Walked X findings. so the user knows what to spot-check.For each finding in severity order, ask two questions back-to-back (skipping question 2 when the fix is one-liner-obvious).
Question 1 — Apply / Skip / Mark as decided.
Question text must include, in this order:
Finding 14/17 — 8 applied, 5 skipped so far (rolling counters across the walk).<section>:<line> — the bare finding text, last (anchors back to the report for users who want detail).Options:
Question 2 — concrete option pick (only when applying a substantive finding).
When the report's Fix is a direction (not a one-liner), surface 2–4 concrete options. Question text must include:
(Recommended) — usually the report's preferred direction or the lowest-cost option that resolves the finding.A bare option list like "A. Schema-version stamp / B. Re-stamp at runtime / C. Document drift" is not acceptable — see the worked example in skills/_shared/ask-user-question.md.
/c-plan (catch design gaps that would corrupt the plan)./c-execute (catch plan gaps that would corrupt the build)./c-check doesn't do/c-find-bugs). Narrowly reads code in plan mode to verify cited paths/symbols/imports exist — that's it./c-audit).skills/_shared/obsidian-format.md.skills/_shared/ask-user-question.md./c-find-bugs (concrete defects vs. this skill's "is it good?" framing).Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub sentasity/cadence --plugin cadence