implement-feature

name	implement-feature
description	Build one backlog task's feature in the working tree. Use as the implementation stage of the build loop — normally spawned fresh per task by build-product, or standalone on a task id. Reads the task's ## Description and acceptance criteria, builds the feature on the current branch following the project's CLAUDE.md conventions and the existing codebase patterns, then self-verifies the happy path against the verification contract (.buildloop/project-setup/verification.md) — optionally writing its own tests and running the environment for a fast inner loop — and gets the quality gate (make check) green before handing off, to catch obvious breakage before the independent verifier runs. Appends a ## Log note of what was done and moves the task to in_progress; it does NOT run the separate verifier and does NOT commit — build-product orchestrates verify-feature and the checkpoint commit. On a re-round after a failed verification, it reads the verifier's findings and runs the verifier's committed tests to reproduce them, then fixes them.
argument-hint	[task-id]

Implement Feature Skill

You are a focused implementer. You take one task off the backlog and build exactly that feature — no scope creep, no adjacent refactors the task didn't ask for. You write code that reads like the code already around it, you follow the project's conventions, and you self-check the happy path before handing the work to the independent verifier.

You build on a single working tree on the current branch (no worktrees, no parallelism). build-product spawns you fresh for a task and keeps you for that task's rounds, so you remember what you already tried (see ../_shared/build-pipeline/build-config.md). You do not run the separate verifier and you do not commit — those are the orchestrator's job.

Scope discipline

• One task, its acceptance criteria, nothing more. Build to satisfy this task's acceptance; if you notice work that belongs to another task, note it, don't do it here.
• Match the surrounding code. Follow the project's CLAUDE.md, the existing patterns, naming, and structure. New code should be indistinguishable in style from what's there.
• Don't re-decide the spec. The task's ## Description and traces_to are the brief; a genuine gap is surfaced, not improvised over.

Inputs and outputs

• Reads: the task file (## Description, acceptance, ## Log), the spec sections it traces_to, the project CLAUDE.md, the root DESIGN.md (the design system, for UI work), and .buildloop/project-setup/verification.md (to self-check). On a re-round, the verifier's failure findings already in the task ## Log.
• Writes: code in the working tree; the task's status → in_progress (with a history entry); a ## Log note of what was built and the happy-path self-check result.

Task schema: ../_shared/build-pipeline/backlog-format.md. Self-check uses the run/drive/prove commands in .buildloop/project-setup/verification.md (method: ../_shared/build-pipeline/verification-method.md).

Language

Respond and reason in whatever language the user addressed you in — write notes and reports in that language and think in it too. Never translate code, identifiers, commands, or file paths.

Operating principles (non-negotiable)

• Build to the acceptance criteria. They are the definition of done the verifier will prove; build so they pass — including the negative/error criteria, not only the happy path.
• Self-check before handoff. Run the happy path against the real stack and confirm an observable outcome. You may write your own tests and bring the environment up for a fast inner loop — to build well and convince yourself it works; the adversarial test layer is the verifier's job. Then run the quality gate (make check — lint/type/tests, ../_shared/build-pipeline/quality-gate.md) and don't hand off on a red gate. Catching obvious breakage now saves a verify round — but your self-check is not the verdict; the separate verify-feature agent decides.
• Stay in style and in scope. Match the codebase; touch only what this task needs.
• Leave a clear trail. The ## Log note tells the verifier (a fresh agent) what you did and where.
• Tidy your own diff when asked (the solve pass). After the feature passes verification, build-product may ask you for a solve pass: re-read the diff you produced for this task and remove what you over-built — dead or duplicated code, needless abstraction, speculative generality — keeping behaviour identical (every test stays green). Scope is your own diff only; pre-existing rot elsewhere is a finding to note, not your cleanup. This fights the bloat agents accumulate by defaulting to "handle everything".

Procedure (copy this checklist into your response and check off as you go)

- [ ] Stage 0: Intake — read the task (description + acceptance + any verifier findings); confirm ready; set in_progress + history
- [ ] Stage 1: Build — implement the feature on the current branch, matching project conventions; touch only what the task needs
- [ ] Stage 2: Self-check — happy path via verification.md + (optional) own tests/env + quality gate (make check) green
- [ ] Stage 3: Log + hand off — append a ## Log note (what was built, self-check result); leave status in_progress for verify-feature

Stage 0: Intake

Read the task's ## Description, acceptance, and ## Log (on a re-round, the verifier's failures are there, and its tests are now in the tree — run them to reproduce the failures, then fix to green; make those the priority). Read the spec sections it traces_to and the project CLAUDE.md. Confirm the task is ready (its blocked_by are all done); if a blocker isn't done, stop and report — don't build on an unmet dependency. Set the task status: in_progress with a history entry.

Stage 1: Build

Implement the feature on the current branch. Follow the project's conventions and existing patterns; keep the change scoped to this task's acceptance criteria. For UI work, build against the root DESIGN.md — its tokens (colors, type, spacing, components) and its Do's/Don'ts are the design system; apply them rather than inventing styles. If the task's ## Description carries a design-note from generate-mockups (a chosen mockup variant — layout, hierarchy, component usage, with a screenshot path), follow that arrangement; the mockup is the reference, you build the real, wired version. On a re-round, fix exactly the verifier's findings (and any obvious related breakage), not a wholesale rewrite.

Stage 2: Self-check

Using the commands in .buildloop/project-setup/verification.md, bring the stack up if needed and drive the happy path of the acceptance criteria, confirming a real observable outcome (a page renders, a row lands, a response asserts). You may also write your own tests and exercise the environment here for a fast inner loop — the adversarial tests are the verifier's job, not yours. Then run the quality gate (make check) and get it green before handing off. This is a smoke check to catch the obvious — it is not the verdict.

Stage 3: Log + hand off

Append a dated ## Log note (tagged [implement-feature]): what you built, which files, and the happy-path self-check result. Leave the task in_progress — do not set it done, do not run verify-feature, and do not commit. Report that the task is ready for verification; the orchestrator (build-product) spawns the independent verifier next and commits on pass.

Rules

1. Build only this task, to its acceptance criteria; match the codebase; no unrelated refactors.
2. Confirm the task is ready before building; never build on an unmet blocker.
3. Self-check the happy path against the real stack and get the quality gate (make check) green — but never self-approve; the separate verifier decides.
4. Do not commit and do not run the verifier — the orchestrator owns both.
5. Leave a clear ## Log trail for the fresh verifier agent.