| name | build |
| description | Build phase workflow. Implements the sprint plan by writing code, running tests, and producing a build output. Use after sprint planning is complete, or when the user says "build", "implement", "code this", "start building", or "let's build". Also use when the user says "let's go" after validating a plan. Always use this skill after /sprint-plan.
|
Build Phase
You are running the build phase. Your job is to implement every task in the
sprint plan — efficiently, correctly, and with tests.
Step 1 — Load context
Read the sprint plan: find the latest tasks/sprints/sprint-*/plan.md.
Read tasks/lessons.md — avoid repeating past mistakes.
If design-system/MASTER.md exists and any task modifies frontend/landing
files, read it before implementing visual changes.
Step 2 — Implement tasks
For each task in the plan:
- Assess complexity — if it touches 3+ files, switch to plan mode first
to design the approach before writing code.
- Implement — write the code, following project conventions from CLAUDE.md
and applicable rules.
- Test — run the test suite after each task. If tests fail, fix before
moving to the next task.
- Save progress — after each completed task, update
tasks/sprints/sprint-XX/build-output.md with what's done. This is your
checkpoint — if context is lost, you resume from here.
If Agent Teams is available and tasks are parallelizable (e.g., independent
frontend + backend + tests), parallelize them. Otherwise, sequential is fine.
Step 3 — Monitor context
Check your context usage periodically.
- If approaching the limit: use
/compact (NOT clear context).
/compact preserves your task progress. Clear context does NOT.- If context was compacted or cleared: re-read
tasks/sprints/sprint-XX/plan.md
and your partial build-output.md before continuing. These files are your
recovery mechanism — always save progress incrementally.
- After each completed task, update
build-output.md with what's done.
This way, if context is lost, you can resume from the last saved state.
If the build would exceed ~60% of context, signal to the human that a session
split is recommended. Save progress to build-output.md and stop.
Step 4 — Produce the build output
When all tasks are done, finalize:
tasks/sprints/sprint-XX/build-output.md
# Build Output — Sprint XX
## Tasks completed
### Task 1: [Name]
- **Files modified**: [list]
- **What was done**: [description]
- **Tests**: passing ✅ / failing ❌
### Task 2: [Name]
...
## Tasks deferred
- [Task]: [Reason for deferral]
## Notes
[Anything the reviewer should know — decisions made, trade-offs, concerns]
## Status
All tasks completed: ✅ / ❌
All tests passing: ✅ / ❌
Step 5 — Notify and stop
Signal to the human: "Build complete, ready for /review."
Channel mode (remote execution)
If invoked via Channel (Telegram/Discord), adapt your output:
- Send a SHORT summary (5-10 lines max) via the Channel reply
- Full detailed output goes in the sprint file as usual
- End with: "Phase complete.
/clear then [next phase command] when ready."
- Never continue to the next phase automatically
- Keep Channel messages concise — the human is likely on a phone
Gotchas
- Use
/compact mid-build to preserve progress when context grows. "Clear context" wipes state and is forbidden during a build.
- Save build-output.md after each task — it's your checkpoint if context is lost.
- Grep for all occurrences before changing a hardcoded value (count, price, URL). One source of truth per value.
- Stay within sprint scope. Refactoring unrelated code during a build expands surface and breaks the review boundary.
- Read design-system/MASTER.md first when touching frontend, if it exists.
Memory
After completing the build, append a one-line entry to tasks/build-history.log:
[YYYY-MM-DD] Sprint XX — X tasks, X files modified, X tests — [clean/issues]
This log helps future sprint planning estimate velocity and spot trends.
STOP. Your deliverable is build-output.md.
The human will open a new session and invoke /review separately.
Do NOT start reviewing your own code.
