Frontend Design

Ownership

Follow the parent workflow's ownership and $adversarial-review's finding-handling contract. Implementation agents mutate frontend code and gather evidence only in their assigned worktrees. When invoked directly without parent workers, the current agent owns the workflow.

The parent or current agent selects any frontend-specific review packet. This lens contributes to that review and schedules none.

Preconditions

• Work in the worktree assigned by the parent workflow, or the current worktree when invoked directly.
• Inspect the existing design system, component patterns, CSS strategy, token files, layout primitives, and validation commands before changing UI.
• For Svelte or SvelteKit work, use official Svelte docs or the Svelte MCP tools when available before changing Svelte-specific patterns.
• For third-party frontend APIs, use Context7 or official documentation before relying on library-specific syntax or configuration.
• For rendered UI, DOM, console, network, accessibility, responsive behavior, or browser smoke evidence, use Playwright, Chrome DevTools, browser tools, or equivalent local validation.

Use The Lens

Evaluate frontend work for:

• product fit, visual hierarchy, information density, layout, responsive states
• component composition, CSS strategy, design tokens, interaction states
• loading, empty, error, permission, disabled, dense-data, and mobile states
• design-system fit, accessibility, keyboard behavior, and visual polish
• design-to-code direction, implementation risk, and validation evidence

Do not use this skill as the authority for backend behavior, security, data modeling, or final correctness.

Planning Pass

The planning agent identifies:

• the strongest UI shape for the feature
• design-system files and components likely to matter
• responsive, empty, loading, error, permission, disabled, and dense-data states
• implementation slices that protect visual coherence
• screenshots, browser observations, or accessibility evidence needed before closeout
• validation commands that prove the frontend result

Contribute frontend planning evidence when the parent or current agent selects a plan review. Follow the parent scheduling and $adversarial-review contract; this lens does not schedule planning critique.

Accepted recommendations must be reflected in decision.md or execplan.md. Do not carry rejected recommendations forward as noise.

Implementation Pass

Implementation agents write frontend code in their assigned worktrees, use the existing design system and tokens, implement applicable loading, empty, error, disabled, permission, mobile, and dense-data states, and gather evidence after editing. Return the evidence to the main workflow agent for integration and acceptance.

Before editing:

• read the target components and adjacent component patterns
• read relevant token/theme/layout files
• inspect existing tests and validation scripts
• gather rendered evidence first when the issue is visual or responsive

While editing:

• keep changes inside the planned frontend paths unless the plan changes
• use existing components, icons, layout primitives, and token conventions
• implement expected loading, empty, error, disabled, permission, mobile, and dense-data states when they apply
• avoid compatibility shims, old aliases, dual paths, and legacy UI surfaces unless the plan records an explicit requirement

After editing, record this status block in the work item or final notes:

---FRONTEND_IMPLEMENTATION_STATUS---
implementer: <agent or provider>
status: changed | no_change | blocked
changed_files:
docs_evidence:
browser_evidence:
validation:
critical:
high:
medium:
low:

The pass succeeds only when the diff contains the intended frontend changes and validation evidence exists for the risk level. If docs or browser evidence were needed but unavailable, record the gap as a blocker or residual risk.

Independent Frontend Review

When the parent or current agent selects implementation review, gather the diff, planning artifacts, rendered evidence, component and token files, and validation output. Contribute a frontend-specific lens to that selected independent review, covering design, ordinary correctness, validation, and adversarial risks in its single packet. Use $adversarial-review's provider-selection and status contract; do not create a separate review for this lens.

Any repeat review follows the parent scheduling and $adversarial-review contract and is never scheduled by this lens.

Ask the reviewer to look for serious issues in:

• visual hierarchy, density, spacing, typography, and responsive behavior
• missing UI states or accessibility regressions
• component boundaries, duplicated styling, token misuse, and brittle CSS
• mismatch between plan, implementation, screenshots, and validation evidence
• unnecessary backwards compatibility or legacy UI noise