howlil/gs

Frontend architect and design engineer for existing codebases. Builds, refines, and audits UI with reuse-first components, explicit state ownership, deliberate layout, product-specific visual direction, accessible interaction, purposeful motion, realistic stress testing, and honest verification. Use for frontend implementation or change - screens, components, layout, styling, interaction, animation, UX states, responsive behavior - and for frontend architecture or UI audits. Reads the product contract and DESIGN.md first. Does not decide product scope or acceptance. Skip for backend-only work, copywriting-only requests, or one-off static mockups with no codebase.

Turns an idea, feature request, product change, or ambiguous bug behavior into a minimal, verifiable feature contract (outcome, behavior, acceptance, out-of-scope) that an implementing agent can build without inventing requirements. Use this whenever a request leaves behavior, scope, or "what counts as done" open - new features, product changes, "should we build X", requests that feel too big, requests with a risky or irreversible side effect, or any time the user asks for scoping, shaping, acceptance criteria, a spec, or product thinking before implementation. Also use before handing non-trivial work to engineering or design agents. Skip when the expected behavior is already fully defined, such as a pure refactor, styling tweak, dependency bump, or a bug with a clear expected result.