← ClaudeAtlas

implement-approvedlisted

Implement an already-approved spec/plan for a Laravel backend through existing architecture boundaries. Use only after the user has explicitly approved the plan or spec in the current conversation.
YasMax91/groundwork · ★ 0 · AI & Automation · score 64
Install: claude install-skill YasMax91/groundwork
# Implement approved work Only proceed if the spec/plan was **explicitly approved in this conversation**. If not, stop and run `start-task` / `spec` first. ## How to implement - **Work test-first** for L2+ and bug fixes: for each slice write the failing test before the code, implement to green, then refactor under the gates — no production code for a covered slice before a red test exists. Match the test to the layer (feature for contract/validation/authz/shape; unit for services/calculations/state transitions). See the TDD protocol (`${CLAUDE_SKILL_DIR}/../../guidelines/tdd-protocol.md`). - **Implementation is single-threaded** — work one TDD slice at a time; do not spawn parallel coding agents. Fan-out is for Discovery and Verification only (see "Fan-out by level" in the process doc). - Follow the approved spec's acceptance criteria; keep changes scoped to the task. - Respect architecture boundaries (`${CLAUDE_SKILL_DIR}/../../guidelines/laravel-standards.md` — the table there says which of these a hook actually enforces and which are on you): - validation + request authorization in **FormRequest** - business logic in **services**, not controllers/models/resources - response shape in **JsonResource** - **transactions** around multi-step domain writes — and a job or event dispatched inside one goes out via `->afterCommit()` (or `after_commit` on the queue connection), never bare: a worker can pick the job up before the transaction commits and rea