Cadence is a planning and verification workflow for developers using Claude Code on software they will keep maintaining. It adds skills for adopting existing repos, capturing todos, auditing requirements before shipping, and configuring review settings.
Claude Code
> /plugin marketplace add crenshawdev/cadence> /plugin install cadence@cadence
Codex
$ npx skills add crenshawdev/cadence -a codex
Cursor
$ npx skills add crenshawdev/cadence -a cursor
Gemini CLI
$ npx skills add crenshawdev/cadence -a gemini-cli
GitHub Copilot
$ copilot plugin marketplace add crenshawdev/cadence$ copilot plugin install cadence@cadence
OpenCode
$ npx skills add crenshawdev/cadence -a opencode
Windsurf
$ npx skills add crenshawdev/cadence -a windsurf
Appearance is cheap. Verification is the work.
Cadence is a Claude Code plugin that brings engineering practices to software you'll keep running 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.
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:
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.
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/foundation.git
/plugin install cadence@foundation
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@foundation.
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-map | Build or refresh the code map the planner reads. It runs only with planning.code_map on, after a typed yes. |
/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.
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 also reads the host's run file for a workflow under the session directory, read-only, to price each agent and take the result: for a review workflow when workflow.use_workflows is on in both config layers, and for /cad-map after its typed yes. For a review workflow, the findings and rulings come from the run's journal beside that file, also read-only. The journal holds what each reviewer and checker returned, and it stays on your machine. 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.
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.
Stars on GitHub
Helps you take a change from a rough idea or bug report through to a tested, reviewed result, with each step handled by a focused skill. Its skills cover pinning down domain terms, designing module interfaces, diagnosing hard bugs, and reviewing changes against your repo's coding standards.
@mattpocockA development methodology for coding agents that makes the agent brainstorm before building, follow plans, run parallel work and finish branches in a disciplined way. You get fewer skipped steps and more consistent results from your coding assistant.
@obraGives your coding agent a planning, testing and review routine to follow on every task. It plans before building, checks changes with tests, has a fresh reviewer look for regressions, and saves repeated wins as reusable skills.
@affaan-mDeveloper tools for working on the React codebase itself. Provides skills for extracting error messages, managing and debugging feature flags across release channels, running Flow type checks, and fixing lint and formatting issues before committing.
@facebookInstall it with the command on its page. It includes cad-adopt, cad-assumptions-analyzer-contract, cad-audit. Its skills do not fire on their own yet. Free and open source.
Is this plugin yours?
Claim it with GitHubSubmit a pluginPromote it