Implement the work described by the user in the spec or tickets.

Before changing anything, record the current HEAD as the review fixed point.

Classify frontend work before changing it:

If the issue/spec references an approved docs/design/<feature>/DESIGN.md, or an approved contract clearly governs the feature, invoke /frontend-build and treat that contract as the visual source of truth.
If the work introduces or changes a visual direction and no approved contract resolves it, stop only that frontend slice and route the unresolved decision to /frontend-design.
If the task is a prescribed maintenance change that introduces no visual decision — for example a copy correction, bug fix, or specified reuse of an existing component — implement it through the existing design system. A new contract is not required.

Never infer that every frontend diff needs a design contract, and never invent an unresolved direction during implementation.

Use /tdd where possible, at pre-agreed seams.

Run typechecking regularly, single test files regularly, and the full test suite once at the end.

Once done, invoke /code-review with the recorded fixed point. It must review committed, staged, unstaged, and untracked work from this run. Frontend changes receive its independent /frontend-review lane in addition to Standards and Spec. Resolve blocking findings and rerun affected checks before committing; preserve genuinely unavailable checks as explicit Unverified items.

Commit your work to the current branch.