From lo-swe
Build phase. Takes scope.md, design.md, and readiness.md and writes the actual code, tests, and deployment config in vertical slices.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lo-swe:buildThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Read `scaffolding/scope.md`, `scaffolding/design.md`, and `scaffolding/readiness.md`. Write the actual software.
Read scaffolding/scope.md, scaffolding/design.md, and scaffolding/readiness.md. Write the actual software.
preferences.md if it existsskills/build-discipline/SKILL.md throughout BUILD. It is the default workflow for slice sizing, test-first implementation, debugging, and change summaries.scaffolding/readiness.md is missing, materially out of sync with scaffolding/scope.md or scaffolding/design.md, or says the project is not ready to build, stop and run /analyze before writing code.AC-*)AC-* identifier so traceability survives refactorsAC-* from scaffolding/readiness.md
b. Before writing new code, read existing code in the project. Match the style, patterns, naming conventions, and error handling approach already established. Consistency across vertical slices matters — especially when sessions restart and a different model instance continues the work.
c. Keep the slice small enough to verify quickly. If it would touch more than about 5 files or you write more than about 100 lines before checking the verification ladder, split it again.
d. Write the code for it
e. Verification ladder: Does it compile? → Does the unit work? → Does the test pass?
f. Record a brief handoff note before moving on:
AC: which AC-* this slice addressedChanged: what this slice alteredNot touched: nearby code intentionally left aloneConcerns: risks, follow-ups, or scope-reduction pressure worth watching
g. Only move to the next criterion after this one passes
h. RepeatAC-* cannot be completed honestly within the current plan, stop and surface the issue under ## Clarifications Needed or ## Deferred rather than quietly weakening the feature.For each vertical slice:
If the quality tier is house or skyscraper, evaluate whether the architecture has clear roles that would benefit from custom agents in .github/agents/. Only create agents when a role is obvious from the code — don't speculate.
Each .agent.md file should have:
description with trigger phrases for discoverytools — only what the role needsCommon patterns:
tools: [read, search])tools: [read, edit, search])tools: [read, search])tools: [read, search, execute])These agents are project code — they live alongside scaffolding as permanent project artifacts.
Run the post-build gate:
AC-* from scope.md has a corresponding test and traceable proof pathuvx pip-audit, npm audit, cargo audit, etc.) and confirm no high/critical vulnerabilitiesuv.lock, Cargo.lock, package-lock.json, etc.)AC-* is marked complete via placeholder or knowingly reduced behaviorIf any gate condition fails, fix it and recheck. Up to 3 retries.
Log the result to scaffolding/log.md:
## BUILD — [timestamp]
- **Gate**: PASS (attempt N)
- **Evidence**: [list each acceptance criterion with pass/fail]
- **Changes**: [files created/modified]
- **Retries**: [total gate attempts this phase]
- **Next**: REVIEW
Git checkpoint:
git add -A && git commit -m "feat(build): implement [project] core functionality" -m "[list acceptance criteria with pass/fail status]\nGate: post-build PASS (attempt N)."
Auto-continue to REVIEW unless the user specified stepped mode.
When a test or build fails, diagnose before fixing. Never blindly retry.
If you cannot identify the root cause after 3 analysis attempts, STOP and report.
If you hit a red flag, shrink the slice and re-establish proof before continuing.
scaffolding/design.md is a living document. If implementation reveals that the design needs to change (e.g., an interface doesn't work as specified, a dependency behaves differently than expected, or performance requirements force an architectural change):
design.md to reflect the actual architectureIf the project has a data model (scope.md Data Model ≠ "none"), follow these rules for any schema change:
up and down (rollback) migrations. If rolling back is truly impossible, document why.DROP a column/table in the same release that removes the code using it. Sequence: (1) deploy code that stops using the column, (2) next release drops the column.up and down.These rules apply at all tiers. A shed with SQLite has the same data integrity concerns as a skyscraper with Postgres.
npx claudepluginhub rcsnyder/lights-out-swe-plugin --plugin lo-sweProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.