Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →hashgraph-online/brownfield-adoption
Step-by-step process for adopting Cavekit on an existing codebase. Covers the 6-step brownfield process, bootstrap prompt design, spec validation against existing behavior, and the decision between brownfield adoption vs deliberate rewrite. Trigger phrases: "brownfield", "existing codebase", "add Cavekit to existing project", "adopt Cavekit", "layer kits on code", "retrofit kits"
Passed 18 of 21 test cases with the skill, and 4 of 21 without it.
and 25 more in the full report
15 fixed4 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
When running a brownfield bootstrap prompt across our microservices (auth, inventory, orders), what exact file names and paths should be generated for individual domain specs and the master index?
| Checked | Without skill | With skill |
|---|---|---|
| Places domain specification files in context/kits/ using the prefix cavekit-. | Missed | Passed |
| Generates the index file at context/kits/cavekit-overview.md. | Missed | Passed |
The instructions your model reads when the skill loads.
Brownfield adoption layers kits on top of existing code without rewriting it. The existing codebase becomes reference material, and kits are reverse-engineered from what the code actually does. Once kits exist, all future changes flow through the Cavekit lifecycle.
Core principle: The existing code is not the enemy -- it is the source of truth for cavekit generation. Respect what works; cavekit what matters.
Brownfield adoption is the right choice when:
Brownfield is NOT the right choice when:
Before starting, decide which approach fits your situation:
| Dimension | Incremental Adoption | Clean-Slate Rebuild |
|---|---|---|
| Objective | Add cavekit coverage around working code | Replace the codebase with a new implementation |
| What happens to existing code | Remains in place, evolves under Cavekit governance | Archived once kits are extracted; new code replaces it |
| Risk profile | Lower -- production system stays functional throughout | Higher -- new system must achieve feature parity before cutover |
| Time to first value | Fast -- kits appear in days, improvements follow | Slow -- significant upfront investment before any return |
| Ideal scenarios | Production systems, incremental improvement, large legacy codebases | Technology stack changes, irrecoverable tech debt, greenfield-quality rebuilds |
| How kits originate | Derived by analyzing existing behavior | Written forward from product requirements |
| Handling broken behavior | Kits capture current state; bugs are fixed through normal Cavekit cycles | Kits capture intended state; fresh implementation avoids old bugs |
| Impact on ongoing work | Low -- regular development continues alongside adoption | High -- team capacity is split between old and new systems |
test cases passed, vs 4 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.