crenshawdev/cadence

4 stars · Last commit 2026-07-30

Phased planning and execution for Claude Code. Roadmap, plans, and progress live in files that survive a /clear.

README preview

# Cadence

The failure that costs you is the one that looks like success: generated code that is present, plausible, and wired to nothing. Cadence is a planning and execution system for Claude Code built around refusing to let that pass. It runs one loop, plan then build then verify, and a check that did not run never reads as a check that passed.

## What it costs you

Cadence is slower than not using Cadence. It makes you gather context before you plan and plan before you build, it stops you at gates you did not ask for, and it says no to things you did ask for. Most of it is not configurable, because most of it is not a preference.

That trade pays off when the code has to keep working. When somebody maintains it later, when it touches money or auth or user data, when a quiet failure costs you more than the extra twenty minutes cost you. If you are sketching something you will throw away Thursday, the ceremony is pure friction and you should skip it. Nobody needs a blocking review gate on a script that renames photos.

## How it works

Cadence assumes the model will fail. Not that it is bad at the job, that it will now and then hand you something that looks finished and is not, and that you will not always catch it by reading. Everything else follows from that assumption, the same way it would for anything you cannot fully trust. Keep the state somewhere durable. Make the workers disposable. Put the rails where the worker cannot argue with them. Never let a check that did not run look like one that passed.

Nothing important lives in the conversation. The roadmap, the per-phase plan, the summary, the verification checklist, the four-line state cursor, all of it sits in `.planning/` and in git history, and the working window carries almost nothing a file does not already hold. Clear at any phase boundary and the next command rebuilds what it needs from disk. The subagents are disposable on purpose. There is no resume and no continue-where-you-left-off, a continuation is a fresh spawn that reads the prior artifact off disk and picks up from the task table it was handed. That one decision is what everything else rests on.

A check that could not run never passes a gate. A reviewer that failed says why out loud instead of quietly dropping out of the set. The verifier scores every claim as verified, failed, or uncertain, and uncertain counts toward neither side, so ambiguity cannot launder itself into a pass. A test file that exists proves nothing and a named test that passes proves one thing, which is why the coverage audit reads the assertions instead of counting files. A test that would still pass if the behavior were wrong is not coverage.

The git rails are a PreToolUse hook, not a paragraph of instructions. A model will talk itself around a paragraph. It will not talk itself around a hook. Every push it tries to run stops and asks you first.

View full repository on GitHub →