Cavekit

Why it's ranked here

Its strongest idea is disciplined state with little machinery. The specification survives context resets, links tasks to invariants, and absorbs test failures into future constraints. The current design is intentionally narrow, however, and removes the autonomous, parallel, and cross-model features associated with the older release.

What's good

The verification contract requires each touched invariant to name an exact proving test. Failed builds feed causes and recurrence guards back into the specification. Research findings retain sources, checks remain read-only, and proposed edits show a diff before writing. Plain Markdown also keeps project state inspectable and portable.

Tradeoffs

Current Cavekit runs one thread with the main Claude instance. It has no autonomous stop-hook loop, parallel workers, dashboard, orchestration binary, team mode, design-system workflow, or built-in cross-model peer review. Existing users of the older kit structure get no automated migration because the formats do not map cleanly.

How to use it well

Use it with Claude Code when work benefits from persistent constraints and explicit verification across context resets. Run the short build-and-check loop for small changes. Add clarification, research, and adversarial spec review for uncertain or high-impact changes. Choose another tool for unattended execution, parallel agents, team coordination, or cross-model review.

Observed

License

MIT License

Primary implementation surface

Markdown skill and slash-command definitions

Interface

Claude Code plugin with seven /ck slash commands

Install surfaces

skills CLI, Claude Code marketplace, or direct Git clone

Platform support

Designed for Claude Code

Specification format

One plain Markdown specification at the project root, using fixed sections and pipe tables

Runtime structure

No orchestration binary, shell hooks, TypeScript helpers, sub-agents, or parallel workers in the current design