Cadence

Appearance is cheap. Verification is the work.

Cadence is a Claude Code plugin for a single developer who expects to maintain the software after the session ends.

Getting an agent to write code is usually the easy part. Keeping it working toward the thing you actually asked for takes more attention. Decisions get lost between sessions. A small change grows an abstraction nobody needed. The tests pass, but you still have to work out what they established.

Cadence gives that work a structure. Requirements, decisions, plans and results stay in your repository under .planning/. Planning, implementation and review happen in separate contexts. A new session reads where the project stands and picks up from there.

You decide what you're building and the constraints it needs to respect. Cadence carries those decisions through the work.

Testing needs a stopping point

An agent can find a reason to write another test almost indefinitely. Each suggestion may sound reasonable on its own. Taken together, they can cost more to build and maintain than the behavior they protect.

More testing has to earn its place.

Cadence's testing policy sets the scope before implementation. Planning checks what the existing tests cover, chooses the smallest set of additional checks needed, and states what evidence is enough to finish. Fixtures, mocks and test infrastructure count toward that effort too.

Under an accepted policy:

• Required tests run unattended in GitHub Actions, including setup, services and cleanup.
• Coverage starts at a recommended 85% for lines and branches, preserving higher existing thresholds. Unsupported metrics are made explicit; Go has a separate statement threshold.
• Existing tests are reused when they adequately cover the behavior. Bug fixes need a reproducer that fails for the defect and passes after the fix.
• Testing stops when the agreed behavior is covered and the required checks pass. Expanding it needs a demonstrated defect, an uncovered acceptance requirement or a measured coverage shortfall.

A passing coverage percentage doesn't establish that the assertions mean anything. The policy requires both meaningful checks and the accepted thresholds. You shouldn't have to approve every test to keep testing under control.

Setup offers the policy, or you can accept one for an existing Cadence project with /cadence:cad-config --testing. It's opt-in per repository. CI-only checks stay pending until they run, and a phase is called CI-verified only for a commit whose required jobs passed.

Read the testing chapter for the rules, supported coverage tools and enforcement limits.

Get started

You'll need Claude Code with plugin support, Node.js, Git, and a signed-in forge CLI: gh, glab or tea. Testing-policy enforcement currently requires GitHub Actions. Cadence's own scripts have no runtime package dependencies.

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

In an existing repository:

/cadence:cad-adopt

For a new project:

/cadence:cad-new-project

Already worked through the idea? Pass your brief with /cadence:cad-new-project --brief <file>. Cadence reads what's settled and asks about what's still open.

Update with /plugin update cadence@cadence.

The working loop

Commands below use the short names. In Claude Code, use the /cadence: prefix, as above.

Command	What it does
/cad-context <phase>	Settle the decisions and acceptance criteria.
/cad-plan <phase>	Turn them into a plan with a bounded testing scope when a policy is active.
/cad-execute <phase>	Build the plan and run its checks.
/cad-verify <phase>	Check whether the phase delivered what it promised.
/cad-progress	Read the project state and find the next step.

Review findings come back for triage. You can use fresh-context Claude reviewers or explicitly enable other providers. Publishing for verification and unattended landing each need their own authorization.

The record stays with the project, so you can end a session without making the next one reconstruct your decisions from chat.

Documentation

Read the Cadence guide, or browse the Markdown on GitHub.

Start here	What you'll find
Getting started · Working with Cadence	Installation, the project cycle and your first phase.
Commands	The full command reference; also available through /cadence:cad-help.
Configuration	Options, defaults, types and configuration scopes. Use /cadence:cad-config to change them.
Testing policy	Test scope, stopping rules, coverage and required CI jobs.
Permissions and data	Provider calls, credentials, local records, shell permissions and publishing.
How it works · Controls and limits	What the roles do and how the controls work.
Cost	Measured runs and where the spend goes.

Cadence adds no telemetry. Its records stay in your repository and go wherever you push them. It runs inside Claude Code, so your session is still subject to the host's data handling. Optional external reviewers receive project material only when enabled.

Help and attribution

Questions go in #cadence on the jcrenshaw.dev Discord. Bugs go to GitHub issues. See Contributing before proposing a change.

Cadence is maintained by John Crenshaw and derives from GSD by Open GSD. It's distributed under the MIT License, with the original attribution retained in NOTICE. Lineage records where it came from.

Support Cadence on Ko-fi.