Cadence

Cadence

Cadence is a planning and execution system for a single developer working in Claude Code. It runs one disciplined loop, discuss then plan then execute then verify, with an atomic commit per task, opinionated defaults, and a deliberately small surface. Your state lives in files, not in the conversation, so you can /clear aggressively and the next command rebuilds from disk.

It is built to say no. One runtime, no team tooling, no feature catalog. What it keeps, it keeps sharp: model routing that spends tokens like a budget, review gates that stop bad work before it lands, and a git model that guards protected branches from ad-hoc pushes and asks how you publish rather than deciding for you, unless you opt into an autonomous close.

Cadence's methodology descends from GSD, the discuss/plan/execute/verify loop, which is where I first ran into it. GSD is what happens when that loop gets built to government standards, an elephant: hundreds of workflows, dozens of agents, a whole TypeScript product wrapped around a four-step idea. Cadence is the mouse. Same loop, its own implementation, about 3% of GSD's documentary mass (measured 2026-07-10, GSD commit d010ea1). See LINEAGE.md for the measured distance, MANIFESTO.md for the why, and DESIGN.md for the full design.

Why Cadence

Most of what makes AI-assisted development expensive is not the model, it is the mess. Context piles up, the same files get read again and again, the conversation drags a week of history into every single turn, and the bill follows the clutter.

Cadence is built the other way around. One loop, discuss then plan then execute then verify. State lives in files, not in the conversation. Clear between steps and you lose nothing. Every task lands as one commit. The heavy reading happens in fresh-context subagents that hand back a short answer instead of emptying a file into your window. Small batches, clean state, tight loops, the same discipline that has always separated software that scales from software that seizes up.

The effect shows up in the numbers. These are measurements of my own real usage, taken from my account's usage data, not telemetry the tool collects. Cadence ships no instrumentation and phones nothing home. Across roughly a billion input tokens of real work, about 96% of that input was served from cache, the cached prefix was reused around 27 times for every rebuild, and fresh uncached input stayed near six hundredths of a percent. Your numbers will vary with your habits. That is not the tool being clever with your money. It is the tool refusing to let your context rot, which keeps the model reading the same clean prefix instead of a growing pile. You still do real work and spend real tokens. You just stop paying full freight to re-read your own history.

Install

Cadence is a Claude Code plugin. Add the marketplace, then install:

/plugin marketplace add https://github.com/crenshawdev/cadence.git
/plugin install cadence@cadence

Update with /plugin update cadence@cadence, remove with /plugin uninstall cadence@cadence. Requires Claude Code with plugin support, plus node and git on your PATH. The scripts inside are zero-dependency: there is no npm install, ever.

The loop

Cadence runs as slash commands in Claude Code, namespaced /cadence:cad-* (for example /cadence:cad-new-project). They are written below without the cadence: prefix for brevity. A project moves through five steps, each its own command:

1. /cad-new-project — define the project through deep questioning: what, why, who, done.
2. /cad-context <phase> — gather locked decisions and acceptance criteria before planning.
3. /cad-plan <phase> — turn a phase into an executable, checkable plan.
4. /cad-execute <phase> — build it, one atomic commit per task.
5. /cad-verify <phase> — confirm the phase delivered what it promised.

/cad-progress tells you where you stand and what's next at any point, and auto-resumes incomplete work.

A worked example

Say you're starting a small CLI tool. You run /cad-new-project and answer the questions, what it is, why it exists, who it's for, what done looks like. Cadence writes PROJECT.md, REQUIREMENTS.md, and a phased ROADMAP.md into .planning/, and sets a state cursor at phase 1. Nothing is in the conversation that isn't also on disk.

Then you work one phase at a time:

/cad-context 1     # lock the decisions and acceptance criteria for phase 1
/cad-plan 1        # turn phase 1 into a checkable PLAN.md; the plan review fires here
/cad-execute 1     # build it, one atomic commit per task
/cad-verify 1      # confirm phase 1 delivered what it promised, recorded in UAT.md