lean-build
juliusbrussee/caveman
Build focused features with strict scope and explicit stop conditions to avoid overbuilding.
What is lean-build?
Lean-build guides feature development by deriving acceptance criteria upfront, tracing entry points through system layers, and delivering coherent end-to-end paths without unnecessary extensibility or polish. Use it for new behavior, product slices, or integrations where scope discipline and repository reuse are critical.
- Derive observable acceptance criteria and explicit non-goals from requirements and codebase
- Trace entry points through architectural layers to identify ownership and invariants
- Deliver end-to-end feature paths across responsible layers without forcing work into single files or local patches
- Reuse existing seams and refactor only when patching duplicates behavior or hides root causes
- Omit modes, providers, config, extensibility, and polish unless acceptance explicitly requires them
How to install lean-build
npx skills add https://github.com/juliusbrussee/caveman --skill lean-buildHow to use lean-build
- 1.Derive acceptance criteria and non-goals from the feature request and existing repository patterns
- 2.Trace the entry point through system layers to understand which components own invariants
- 3.Design the end-to-end path across layers, ensuring coherent ownership without forcing work into single locations
- 4.Identify and reuse existing seams; refactor duplicated behavior only when necessary
- 5.Omit configuration, extensibility, modes, and polish unless acceptance criteria require them
- 6.Exercise the path with a focused proof and run it to verify acceptance passes
- 7.Report only material omissions and what triggered the stop condition
Use cases
- Building new product behavior with high risk of scope creep or over-engineering
- Implementing narrow product slices that need to fit cleanly into existing architecture
- Adding integrations while maintaining strict boundaries and repository coherence
- Refactoring features to eliminate duplicated behavior and clarify ownership
- Delivering focused proofs of concept that preserve system safety and simplicity
- Backend and full-stack engineers building features in established codebases
- Teams prioritizing architectural clarity and scope discipline over feature velocity
- Developers working in systems where overbuilding creates technical debt or maintenance burden
lean-build FAQ
Use lean-build when building new behavior, product slices, or integrations where overbuilding risk is high, strict scope matters, and you need to preserve architectural coherence and repository reuse.
It means identify and use existing extension points or interfaces in the codebase rather than creating new ones. Only refactor when patching duplicates behavior, weakens ownership, or hides the root cause.
No, unless your acceptance criteria explicitly require them. Lean-build prioritizes delivering the minimum coherent feature that satisfies acceptance over building for future flexibility.
Stop when acceptance criteria pass. Run a focused proof to verify the feature works end-to-end, then report only material omissions and what triggered the stop condition.
It works best for new behavior, product slices, and integrations where scope discipline and architectural clarity are critical. It may be less relevant for highly exploratory or experimental work.
Full instructions (SKILL.md)
Source of truth, from juliusbrussee/caveman.
name: lean-build description: Build feature work with high overbuilding risk. Use for new behavior, product slices, or integrations where repository reuse, strict scope, and an explicit stop condition matter.
Lean build
Native Core's architecture-first simplicity remains mandatory. Turn feature into complete narrow outcome fitting system.
- Derive observable acceptance and explicit non-goals from request and repository.
- Trace entry point through layers owning invariants.
- Deliver coherent end-to-end path across responsible layers; never force work into one file, direct expression, or local patch.
- Reuse fitting seam. Refactor when patching duplicates behavior, weakens ownership, or hides root cause.
- Omit modes, providers, config, extensibility, and polish unless acceptance needs them.
- Add surface, dependency, service, config, or migration only for lifecycle design or acceptance; state material tradeoff.
- Keep work runnable; preserve Core safety.
Exercise path. Run focused proof. Stop when acceptance passes. Report only material omissions and trigger.
Related skills
More from juliusbrussee/caveman and the wider catalog.
migration
Implement reversible, compatibility-safe transitions for schema, data, API, and dependency migrations with rollback.
safe-refactor
Restructure code while preserving behavior through bracketed verification.
surgical-patch
Fix bugs at the narrowest responsible layer with regression proof and preserved surrounding behavior.
verify-and-stop
Prove existing work meets acceptance conditions without expanding scope.
context-canary
Install a per-turn canary signal to detect silent context degradation and trigger recovery when it fails.
fuck-slop
Strip AI writing fingerprints and rewrite text into its target register—academic, tweet, email, blog, anything.