Implement an SDLC change from its approved plan (Stage 3, Build) with a continuous feedback loop - work through tasks.md, run the project's checks after each step, keep plan.md in sync. Use when the plan gate is approved and the user asks to implement, build, or apply the change.
Installs into .claude/skills of the current project.
Are you the author of Build?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/marin-ai-tech-build)
---
name: build
description: Implement an SDLC change from its approved plan (Stage 3, Build) with a continuous feedback loop - work through tasks.md, run the project's checks after each step, keep plan.md in sync. Use when the plan gate is approved and the user asks to implement, build, or apply the change.
argument-hint: "[change-id]"
license: "PolyForm-Noncommercial-1.0.0 with sdlc Additional Permissions, or sdlc Commercial License (https://github.com/marin-ai-tech/sdlc)"
compatibility: Requires the sdlc CLI (sdlc) from the sdlc package.
allowed-tools: Bash(sdlc *)
metadata:
author: marin-ai technologies
version: "1"
generatedBy: "sdlc 0.23.7"
---
Implement the approved plan - Stage 3 (Build). Every step checks its own work before a person sees it.
**Harness contract** (applies to every SDLC workflow)
- `sdlc` is the source of truth for lifecycle state. Read it (`sdlc status --change <id> --json`) instead of inferring the stage from the conversation, and re-read artifacts from disk before using them.
- Gates are human decisions. Never run `sdlc approve`, `sdlc reject`, `sdlc waive` or `sdlc tests unlock`, and never edit `.sdlc.yaml`. When a gate needs a person, stop, name the people from the hint (`next.people` in `sdlc next --json`) rather than the role, and give them the exact command to run in their own terminal.
- An answer in chat is never an approval: gate approvals, `track set`, `backlog move`/`drop` and other human decisions happen only as a command the person runs in their own terminal. Offer the choice, explain the consequences, and give the exact command.
- OpenSpec is the specification subsystem: `sdlc openspec <args>` runs the bundled OpenSpec CLI (`list --specs`, `show`, `validate`, `instructions`). Change folders live in `openspec/changes/<id>/`.
- **Change selection**: use the change named in the input. Otherwise run `sdlc status --json`; with exactly one active change use it, with several ask which one. Announce "Using change: <id>".
- **Language**: talk to the person, and write notes and artifacts, in the person's language; when `locale:` is set in `openspec/sdlc.yaml`, use that language. Keep command names, file names, ids and the template headings as they are (sdlc and OpenSpec parse those headings).
- End every workflow with the next step from `sdlc next --json` (the exact command when a person must act).
**Input**: the user's request (a change id, or a description of the work)
**Steps**
1. **Check the gate.** `sdlc status --change <id> --json`: the `plan` gate must be `approved` (or `waived`). If it is `stale`, the plan changed after approval: stop and ask the engineer to re-approve. If it is pending, stop - do not implement an unapproved plan.
2. **Load context from disk**: intent.md, proposal.md, specs/, design.md, plan.md, tasks.md. Put the `tasks.md` items into TodoWrite at the start and keep it in step as tasks are checked. `tasks.md` stays the source of truth. Run `sdlc verify --list` to learn the project's checks.
For each artifact you write or update, use `sdlc instructions <artifact> --change <id> --json` and write to its `resolvedOutputPath`.
3. **Parallel streams.** If plan.md marks independent steps `[parallel]` and they touch different files, suggest running them in separate worktrees/sessions; tasks that share files stay sequential in this session.
4. **Bug-fix protocol** (`kind: bugfix`): the first task writes a test that reproduces the bug. Run it, confirm it fails for the expected reason, commit it, then run `sdlc tests lock --change <id>` - from then on the harness blocks edits to test files, so the fix has to change the code.
5. **Work the tasks in order.** For each pending task:
- make the smallest change that satisfies it
- run the most targeted check first (the test for this behavior), then the group's checks
- fix the code until the checks pass - never skip, weaken or delete a test to get green
- mark `- [ ]` -> `- [x]` only when the task's behavior is fully implemented and its check passed
- when the implementation departs from plan.md, update plan.md in the same commit
- end each commit message with the trailers `SDLC-Change: <id>` and `SDLC-Task: <n.m>` (the task number from tasks.md), so `sdlc trace <id>` links the task to its commit
6. **Pause** when a task is unclear, when the design turns out wrong (propose an artifact update), when the work grows beyond the spec, or on any error you cannot resolve. Do not absorb scope silently.
7. **Finish.** When every implementation task is checked, run the `/sdlc:verify` workflow.
The verify gate records the checks and needs no task of its own.
**Output while working**: `Working on task N/M: <task>` ... `✓ done (<check> passed)`; on pause, the issue and options.
<!--
Generated by sdlc 0.23.7 (https://github.com/marin-ai-tech/sdlc).
Required Notice: Copyright (c) 2026 marin-ai technologies (https://github.com/marin-ai-tech/sdlc)
License: PolyForm Noncommercial 1.0.0 (https://polyformproject.org/licenses/noncommercial/1.0.0) with the sdlc Additional Permissions, or a commercial license; see https://github.com/marin-ai-tech/sdlc
-->