implement-spec-frontend

/implement-spec-frontend — Implement an approved frontend redesign

Purpose

Implement an approved /spec-frontend artifact faithfully, then prove the redesign in the rendered product with independent specialist review.

Invocation

/implement-spec-frontend <spec name or path>

Accepted input

An approved .agent/specs/*.md file with work_type: frontend-redesign, baseline conditions, an implementation plan, and browser acceptance scenarios.

Prerequisites

• The spec exists, is readable, and has status: approved.
• The target route, preview, stable fixture/data, and required source paths are available.
• Material brand, product, information-architecture, dependency, and shared design-system decisions are already approved.

Procedure

1. Read the entire spec and confirm generated_by: spec, work_type: frontend-redesign, status: approved, repository revision, source paths, preservation constraints, requirements, tasks, tests, browser scenarios, and approval-sensitive decisions. Stop if the spec is unapproved.
2. Apply context-discovery, then verify change-sensitive claims against source. If the target, design system, route behavior, fixtures, or relevant source has materially drifted, return to /spec-frontend for an amendment; do not reinterpret a stale direction while coding.
3. Reproduce the spec's baseline before editing with browser-visual-validation. Use identical route, data, state, viewport, theme, and interaction conditions. If comparison conditions changed, repair the fixture or stop—the final cannot be compared against a different baseline.
4. Load and apply the curated canonical skills required by the approved scope: frontend-guidelines, code-quality-guidelines, frontend-design-direction, visual-craft, design-system-integration, ui-state-design, responsive-ui-engineering, accessible-ui-engineering, motion-design, test-design, and browser-visual-validation. Load architecture-guidelines only for approved shared frontend architecture, routing, data-flow, or design-system ownership changes.
5. Inspect active packs. If more than one primary aesthetic pack is enabled, stop and ask the user to choose exactly one; do not rely on priority order to reconcile contradictory visual directions. Otherwise apply at most one explicitly enabled primary aesthetic pack (frontend-design, taste-skill, or ui-ux-pro-max) plus optional emil-design-engineering. Do not silently enable packs, blend conflicts, fetch remote prompts, execute upstream installers/scripts, or add a dependency because a third-party skill prefers it.
6. Hand the approved brief, context capsule, reuse map, preservation list, tasks, and acceptance matrix to frontend-implementer. Use one coherent production-code writer by default; do not assign overlapping UI files to parallel agents. Parallelize only truly independent read-only research, isolated tests, or non-overlapping assets explicitly marked safe by the spec.
7. Implement in dependency order: semantics and content, state/behavior, structure and responsive transitions, visual system, then justified interaction/motion. Reuse local primitives, keep scope coherent, and add the specified unit/component/E2E/visual/accessibility tests.
8. Run independent final checks, in parallel when native isolated subagents are available and otherwise as honestly labelled separated passes:
   • visual-qa-tester: like-for-like baseline/final browser comparison, relevant viewports/states/themes/zoom/long content, console, and network;
   • accessibility-reviewer: keyboard, focus, semantics, names/states, contrast, reflow, reduced motion, forms, and recovery;
   • visual-craft-specialist: approved direction, hierarchy, typography, color, spacing, density, alignment, shape, icon/image, and anti-slop fidelity;
   • ux-reviewer: named task outcome, comprehension, friction, copy, and recovery;
   • motion-design-reviewer when interaction or motion changed: purpose, responsiveness, interruption, reduced motion, and performance.
9. Consolidate only reproducible, in-scope blockers. Have frontend-implementer perform at most one correction pass, then re-run the affected checks. Do not create a hidden unbounded loop. If blockers remain, stop with evidence and use the configurable improve-ui-ux loop only when the user explicitly wants additional bounded iterations.
10. Run configured gates. Write or update .agent/evidence/ui/<spec-name>/report.md with baseline/final conditions, evidence paths, changed files, requirement coverage, specialist execution mode and verdicts, states/viewports, accessibility, motion, console/network, tests/gates, deviations, remaining blockers, and untested coverage.