Vibe Design Engineering

Use this skill to make AI-assisted UI work controllable. Treat design as an input system: explicit product intent, domain semantics, craft rules, component boundaries, templates, and evaluation criteria enter the generation loop before the UI is produced and return as critique after review.

Do not reduce the method to "write a better prompt." Build a workflow where each design problem has an owner: specification, domain semantics, visual craft, design tokens, component contracts, templates, runtime UI contracts, or evaluator gates.

Source note: this skill is an independent workflow adaptation inspired by Alibaba Cloud Design's "Vibe Designing Playbook" at https://alibaba-cloud-design.github.io/vibe-designing-playbook/. It summarizes and operationalizes ideas from the public playbook; it is not an official Alibaba Cloud Design skill and does not reproduce the original playbook text.

Core Model

Map every request onto this loop:

1. Understand and plan: clarify user goal, page type, product context, target users, risk, and success criteria.
2. Build structure: define information architecture, primary task, hierarchy, navigation, and empty/loading/error surfaces.
3. Fill with controlled parts: choose allowed components, data fields, copy patterns, domain semantics, and design tokens.
4. Refine interaction and craft: cover state transitions, recovery paths, density, rhythm, accessibility, and visual restraint.
5. Evaluate and route critique: judge against page type and task, collect evidence when possible, identify blockers, and send fixes back to the responsible layer.

Keep three streams visible throughout the loop:

• Main chain: the artifact advances from intent to structure to UI to review.
• Token injection: colors, spacing, typography, radius, motion, and component variants constrain every generation step, not just final styling.
• Critique return: failed checks return to the specific layer that owns the problem.

Working Rules

• Start from the user's actual task, not from a generic page pattern.
• Make implicit design judgment explicit before generation whenever the request is ambiguous or high impact.
• Separate design declarations from execution contracts:
• Declarations say what good means: spec.md, domain.md, craft.md, design.md, components, template.
• Contracts say how the agent should use and verify them: skills, structured UI contracts, evaluators, gates.
• Prefer constrained generation over open-ended UI generation. The agent may propose structure and intent, but product-owned components, tokens, accessibility rules, and safety constraints should own rendering decisions.
• Treat skills as routers over design knowledge. A skill should tell the agent which declaration or reference to read for the current design problem, not paste every rule into the prompt.
• If a token, component, or domain rule is missing, expose the gap instead of inventing a literal fallback. Record the gap or call it out in the result.
• Treat AI-looking UI as a diagnosable failure mode: unsupported gradients, equally weighted cards, decorative uppercase labels, vague "premium" styling, missing states, and arbitrary colors usually signal missing declarations.
• When reviewing, evaluate the delivered artifact, not the author's intention or hidden plan.

Choose References

Read only the references needed for the task:

• For turning a vague UI request into a spec or implementation plan, read references/design-io-and-declarations.md.
• For agentic products, conversational workflows, dynamic cards, generated reports, GenUI, or A2UI, read references/ax-genui-a2ui.md.
• For UI critique, evaluator design, scoring, screenshot/browser evidence, blockers, or iteration loops, read references/evaluator-and-gates.md.

Output Shapes

For a design plan, produce:

• Intent: target user, job, page type, and product context.
• Design declarations: spec, domain rules, craft rules, design tokens, component constraints, template choice.
• Interaction model: primary path, decision points, states, recovery, permissions, and edge cases.
• Generation plan: what the agent may generate, what must stay controlled, and what evidence will prove success.
• Evaluation checklist: page-type-specific checks and release blockers.

For a critique, produce:

• Findings first, grouped by severity and tied to concrete evidence.
• The layer responsible for each issue: spec, domain, craft, design, components, template, runtime contract, or evaluator.
• Specific revision instructions that can be handed back to a generator.
• A gate decision: pass, iterate, or block.

For a reusable workflow or skill, produce:

• Trigger scenarios and non-goals.
• Required inputs and assumptions.
• A concise step sequence.
• Reference material split by when it should be loaded.
• Validation checks that prove the workflow did not become a vague prompt wrapper.