impeccable

Designs and iterates production-grade frontend interfaces. Real working code, committed design choices, exceptional craft.

Setup

You MUST do these steps before proceeding:

1. Run node scripts/impeccable_adapter.mjs context once per session; if the runtime shows this skill's loaded base directory, run node <skill-base-dir>/scripts/context.mjs instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append --target <path> to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. If it reports NO_PRODUCT_MD: divert into reference/init.md first when the user invoked init, teach, craft, or shape, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do not divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus (step 4), and offer $impeccable init once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an UPDATE_AVAILABLE directive, follow it (ask the user once about updating, then continue). It never blocks the current task.
2. If the user invoked a sub-command (craft, shape, audit, polish, ...), you MUST read the command's reference next: reference/<command>.md, or the native variant from the Commands table (e.g. reference/audit.native.md) when the project platform is native (ios / android / adaptive, per the context.mjs directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects.
3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). Required even when you've loaded a sub-command reference in step 2. Don't reinvent the wheel; use what's there when it works, branch out when the UX wins.
4. Read the matching register reference. This is non-optional; skipping it produces generic output. If the project is marketing, a landing page, a campaign, long-form content, or a portfolio (design IS the product), read reference/brand.md. If it is app UI, admin, a dashboard, or a tool (design SERVES the product), read reference/product.md. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus (the page, file, or route being worked on); (3) register field in PRODUCT.md.
5. If PRODUCT.md's ## Platform is ios or android, also read reference/<platform>.md (HIG / Material 3 conventions). adaptive (cross-platform, ships both) reads both files. web, absent, or unrecognized: nothing extra to read. context.mjs prints the directive when one applies.
6. If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3), run node scripts/impeccable_adapter.mjs palette to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.