Deep Design

Design the implementation contract, not the production implementation. Start from a confirmed Product Brief and finish with a confirmed Build Contract that another agent can execute without inventing material product or design decisions. Isolated visual previews may supply design evidence when requested and permitted by the environment; they are not production edits.

Verify The Input

Locate the Product Brief and the target project's sources of truth. Confirm that the brief states the target user, desired outcome, constraints, non-goals, decisions, success scenarios, and material assumptions. Inspect the existing system before proposing changes.

The brief can be confirmed in conversation; do not require a separate document or repeat settled questions just to satisfy a template. For an existing UI, distinguish required behavior from replaceable presentation. For new UI, use confirmed tasks and states rather than inventing a legacy baseline.

If root product intent is missing or contradicted, return the specific gap to deep-grill. Do not hide a product decision inside architecture, interface, or task design.

Resolve The Design

Trace desired behavior through the relevant system boundaries. Resolve only what the change needs: public behavior, data and state, interfaces, errors, migration and compatibility, accessibility, security, observability, rollout, and rollback. Preserve existing project patterns unless the Product Brief requires changing them.

Use domain, architecture, research, frontend, prototype, visual-design, or other specialists only for a material unresolved design question. Feed their accepted decisions back into the Build Contract. They do not own progression or create parallel workflow state.

When UI structure, visual direction, or interaction design is material, use the conditional UI branch below. Backend-only work skips it. For landing pages, portfolios, or editorial interfaces, design-taste-frontend remains the default aesthetic specialist when available; dashboards, tables, and multi-step product UI need task-appropriate methods. The impeccable skill complements it for improvement-only requests such as polish, critique, or audit; it does not replace the default specialist or open a second lifecycle. Specialists inform this contract rather than starting another lifecycle or implementing production UI.