Pe Build

Build

Production UI to the craft bar. This spine routes and carries the shared loop; the craft itself lives in the reference files — load only what the mode needs.

The loop (every mode)

1. Boundary — name the exact target, what must remain unchanged, and the surface's job (persuade / operate / read / experience); read DESIGN.md when present and verify it against tokens, components, and rendered output. Read .product/approved/ for a record matching the target: an approved artifact ranks above your judgment and below the user's words — implement to it, and state any deviation (constraint, platform, accessibility) before making it, never as a silent improvement. Preserve the incumbent identity: polish is refinement, never a concealed redesign.
2. Evidence — read the real code and, where possible, the rendered result before changing anything.
3. Triage — fix in order: blocked tasks and inaccessible paths → missing states and recovery → flow, hierarchy, responsiveness, drift → visual/copy/motion inconsistencies → cleanup. Don't perfect one corner while the path stays below bar.
4. Implement — complete fixes, in the project's stack and idiom.
5. Verify — walk the whole path; check states, viewports, zoom, focus, semantics, console, layout shift. At most two bounded visual rounds — no open-ended loop.
6. Report — what changed, what was preserved, what remains, and the approved record built against (with each stated deviation), when one exists.

Modes

Generation guardrail: when writing new UI from scratch in any mode, also load craft/generation-guardrails.md (terse MUST/NEVER rules).

Course preference: if references/course/ contains files, prefer them for their topics — craft-design-rules.md and friends extend craft; the motion-* files extend and deepen motion (CSS, Motion for React, gestures, scroll, debugging, performance, reduced-motion snippets, and the motion-brief interview). They are a licensed local install; never copy from them into tracked files.

Gates

• Redesign gate: changing the visual identity (fonts, palette, layout language) is forbidden unless the user explicitly asked for a redesign. Only then load craft/deslop-audit.md and work audit-first within the existing stack.
• Read-only requests are not this skill. "Review/audit/critique" → hand to pe-review. Findings received from pe-review are implemented here at their stated file:line.

House rules (bind every mode)

• Press scale is exactly 0.96.
• Spring bounce 0 unless the design direction's register is explicitly playful.
• Reduced motion means gentler-not-zero — keep opacity/color transitions.
• Exits use ease-out; accelerate-away only as a stated deliberate choice. motion/view-transitions/css-recipes.md uses ease-in on several ::view-transition-old (exit) snippets and one enter — apply ease-out instead.
• will-change only on observed first-frame stutter, never prophylactically.
• Custom easing from the named curves in the motion references — never invent novel curves ad hoc.
• Stagger ~30–80ms between list items, ~100ms between semantic groups.
• Never disable submit buttons; validate on submit.

Name mapping

References that route to better-* skills by name resolve inside this skill: better-ui → craft/ui/ · better-layout → craft/layout/ · better-typography → craft/typography/ · better-colors → craft/colors/ · better-writing → craft/writing/ · better-accessibility → a11y/ · better-interface → the pe-review skill.

Handoffs

Verdicts and audits → pe-review. Proof that the built feature works, with recordings → pe-verify (the natural last step after harden). Direction, mockups, variations → pe-design. Standalone brand assets → pe-brand-assets. Documenting the system you built → pe-design, understand mode.