cavekit-revision
Revision: Tracing Bugs Back to Kits
In Cavekit, revision means tracing a production defect upstream through the cavekit chain until you find the gap that allowed it. In practice, when the built software has bugs or gaps, you trace the issue back to the kits and prompts and fix at the source -- not just in code.
Key insight: When a fix lives only in code with no corresponding cavekit update, the next iteration loop may reintroduce the same defect. The goal is that kits plus the iteration loop can reproduce any fix autonomously.
1. Why Revision Matters
Without revision, every bug fix is a one-off patch. The next time the iteration loop runs, it may reintroduce the bug because nothing in the kits or plans prevents it.
With revision:
- Bug fixes become cavekit improvements that persist across all future iterations
- The iteration loop becomes self-correcting -- it learns from every manual intervention
- Kits become progressively more complete over time
- The gap between "what kits describe" and "what works" shrinks monotonically
More from juliusbrussee/caveman-code
caveman-compress
Ultra-compressed communication mode (lite / full / ultra) that cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Use when the user requests "caveman mode", "less tokens", "be brief", or when output budget is tight.
13cavekit-methodology
Cavekit specification-driven development methodology — the Hunt lifecycle (Draft → Architect → Build → Inspect → Monitor) and how to apply it. Use when starting a Cavekit project, structuring an existing codebase as kits/plans, or routing between sub-skills.
11cavekit-validation-first
Validation-first design for Cavekit — every kit requirement must be automatically verifiable. Six-gate validation pipeline, phase gates, merge protocol, completion signals, acceptance criteria patterns. Use when designing acceptance criteria, wiring CI gates, or debugging why an agent is producing output that nobody can verify.
11cavekit-design-system
How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects. Nine-section format, design tokens, accessibility, integration with kits/plans. Use when defining or revising visual identity, importing a third-party design system, or auditing UI code against design tokens.
11plugin-creator
Scaffold a complete cave plugin bundle — generates .cave-plugin/plugin.json manifest and the standard directory structure (commands/, skills/, agents/, themes/, hooks/). Use when a user wants to create, publish, or package a cave plugin for the marketplace. Triggered by "create a plugin", "scaffold a plugin", "/plugin create", or "new cave plugin".
10dynamic-resources
Example skill loaded from resources_discover
10