ladder-build

name: ladder-build
description: Incremental build pipeline that decomposes projects into small, verifiable milestones. Enforces a verify-before-continuing contract — each rung is built, tested, and confirmed before climbing to the next. The end goal stays visible; the path evolves as the picture becomes clearer. Use after miltiaze exploration or when starting any build project.

Decompose any project into small, verifiable milestones and build them one at a time. Each milestone is built, tested, and confirmed before the next begins. The build plan is a living document that adapts as the picture becomes clearer, but the end goal stays fixed.

Check for existing build plans in [cwd]/artifacts/builds/. If one exists for this project, route to workflows/continue.md. If this is a new project, route to workflows/kickoff.md. If a milestone is already in progress, route to workflows/build-milestone.md.

Building is climbing. Each milestone is a rung — small enough to step on, solid enough to hold weight, and always leading upward toward the end goal. You can see the top from any rung. The ladder might grow new rungs or lose some as you climb, but the destination stays fixed.

The end goal is the North Star. Defined at kickoff. Stays visible in every plan update. Milestones shift, but the destination doesn't — unless the user explicitly changes it.

Small, verifiable milestones. Each one is small enough to build and verify in one sitting. If you can't test it, it's too abstract. If you can't finish it, it's too big. Split it.

Build, test, verify, next. No stacking unverified work. Every milestone produces something the user can see, run, or confirm before moving on.

The plan is alive. Milestones can split, merge, appear, or disappear as you learn. The plan reflects reality, not the original guess. Update it after every milestone.

Sample data is not optional. If a feature needs data to test, create it. Mock APIs, seed databases, generate fixtures. A feature you can't exercise is a feature you can't verify.

Bugs die where they're born. Found during a milestone? Fix it now. Don't defer. Stacking bugs is how projects rot.

Artifacts survive sessions. Build plan and milestone reports live on disk. Any session picks up where the last left off. Context never lives only in memory.

Handoffs are explicit. Receiving from miltiaze? Read the exploration. Completing a session? Save the state. The chain never breaks.

Build first, polish later. Core functionality before refinement. Tooltips, chart aids, cleaner UI — these are milestones too, but after the thing works.

Every milestone adds visible progress. The user should see/feel the difference. Invisible milestones need to be combined with something user-facing.

Adapt, don't abandon. When the picture changes — and it will — update the milestones. Don't restart. The work done is still valuable; the path forward just got clearer.

Use the right tools — high-confidence sources only. Look up documentation with Context7. Use WebSearch for current information. Test with real commands. Write real code. This is building, not theorizing. When researching, only use high-confidence sources: official documentation, official GitHub repositories, well-established technical publications, and recognized industry blogs. Never rely on random Medium articles, SEO-farm blogs, content aggregators, or any source where authorship or accuracy is questionable. If the only source is low-confidence, flag it explicitly.

Build for sharing. Everything we build should be straightforward for someone else to pick up and run. If setup requires installations, keys, or configuration — provide exact steps, direct links, and known gotchas inline. The user should never have to leave the project to find answers. If a dependency has common failure modes, document them with fixes. If there's a setup script, it should tell you what's happening and what to do if something fails.

Analyze the user's input to determine what to build and where we are.

If the user referenced a miltiaze exploration or a specific project:
- Look for the exploration file in [cwd]/artifacts/explorations/
- Look for an existing build plan in [cwd]/artifacts/builds/

If the user described something new to build:
- Extract the core project, constraints, and preferences

Then proceed to routing.

Default: If there's an existing build plan for this project, route to continue. Otherwise, kickoff.

All in references/:

All in workflows/:

All in templates/:

The ladder-build skill succeeds when:
- The end goal is defined and confirmed
- The project is decomposed into verifiable milestones
- Each milestone is built, tested, and verified before the next begins
- The build plan is kept current on disk after every milestone
- All milestone reports are saved to disk
- The user confirms each milestone before moving on