impeccable, command by command.

Build a real feature end to end, from brief to browser-checked production code.

What it does

The full build pipeline in one command. It reads the project to learn what it is building on (framework, component library, icons), runs shape internally to settle a design brief, passes a visual-direction stage (palette and mock approval when the tool can generate images), then writes real code in deliberate passes: structure, visual system, every state, motion and media, responsive behaviour. It then looks at the result in a browser like a designer would, critiques it honestly against the brief, patches real defects, and walks you through what it built.

Reach for it when

You want a feature actually built to shipped quality, not just planned, and you want the whole discover-then-build flow handled in a single run from a rough description.

You get

A working, production-quality feature in the project's real build pipeline, verified in-browser across screen sizes and states, plus a spoken walkthrough of the decisions and any accepted deviations from the mock.

Needs first

Project context from init (PRODUCT.md); the build/dev environment; and some way to view the result (a connected browser, a screenshot tool, or you). It gets its design direction by running shape itself.

Watch out

Craft has several hard stop-gates, not one. A finished shape brief is not a green light to code: with image generation on, it still stops for direction questions, palette confirmation, and mock approval first. Skipping those gates because the brief felt complete is the most common failure.

Plan a feature's look and flow through a short interview, before any code is written.

What it does

Produces a design brief and deliberately writes no code. It runs a short discovery interview (two to three questions per round) to understand the feature: its purpose, the specific people using it and their state of mind, the real content and its ranges, the edge and empty states, plus three forced visual calls (a colour strategy, a one-sentence physical scene that settles light versus dark, and a couple of named reference products). It then presents the brief, compact when the ask is clear or a fuller structured form when it is ambiguous, and stops for you to confirm or redirect.

Reach for it when

You have a feature idea but have not settled what it should be, do, or look like; the request is ambiguous or spans several screens; or you want the thinking locked before anyone commits to building.

You get

A confirmed design brief ready to hand to craft or to any freeform build, plus optional visual direction probe images.

Needs first

Nothing strictly. PRODUCT.md and DESIGN.md, if present, cut down repeated questions, but they do not replace shape, which is task-specific.

Watch out

Shape is planning only; it never writes code, and the confirmation pause is the whole point. For the discover-then-build flow in one step, use craft (which runs shape inside itself) rather than running shape and building separately.

One-time project setup that writes the context every other command reads.

What it does

Crawls the codebase once and turns it into the project's foundation file, PRODUCT.md: the register (brand or product), the platform (web, iOS, Android, or both), the users, the purpose, the positioning, the brand personality, the anti-references, and the accessibility needs. It forms a guess from what it finds, runs a short interview in plain language (no skill jargon), and only writes the file after you confirm. It can then hand off to document for the visual side and close by recommending your best next commands.

Reach for it when

You are starting impeccable on a project for the first time, PRODUCT.md is missing, or another command stopped because there was no project context yet.

You get

PRODUCT.md at the project root; optionally DESIGN.md (via document), a live-mode config, and a short pointer added to the project's agent instructions.

Needs first

Nothing; init is the entry point. It reads any existing PRODUCT.md or DESIGN.md so it can extend rather than replace them.

Watch out

It never silently overwrites; it confirms first. The register choice shapes everything downstream, so it must be settled, not guessed. It deliberately does not ask about colours or fonts; those belong to document.

Capture the project's real visual system into a DESIGN.md so new screens stay on-brand.

What it does

Generates DESIGN.md to a fixed spec: machine-readable design tokens (colours, type, spacing, components) followed by exactly six fixed-order sections. In scan mode (the default, when code exists) it searches the CSS variables, the theme config, the token files, and the component library, extracts what it finds, then asks you only for the creative language a scan cannot infer: a named north-star metaphor, descriptive colour names, and the elevation and component philosophy. In seed mode (a pre-code project) it asks five quick questions and writes a minimal scaffold instead.

Reach for it when

You just ran init and need the visual side captured, no DESIGN.md exists yet, or an existing one has gone stale as the design drifted.

You get

A DESIGN.md at the project root (token header plus the six-section body) and, in scan mode, a sidecar data file the live panel reads.

Needs first

Ideally PRODUCT.md already exists (its anti-references get quoted into the do's and don'ts). Scan mode needs real code or tokens to read; it is often run straight from init.

Watch out

The six section names are fixed: other tools parse them character-for-character, so do not reorder, rename, or add to them. It is strictly visual and must not duplicate PRODUCT.md's strategy; the tokens are the single source of truth.

Pull repeated UI patterns into reusable components and tokens, then migrate every use to them.

What it does

Consolidates duplication into the design system. It learns the shared-UI directory and its naming, then hunts for genuine extraction targets: a component repeated three or more times, hard-coded colours, spacing, and type that should be tokens, several slightly different versions of one concept. It writes a plan, builds clean reusable versions with a proper props API and built-in accessibility, replaces every existing instance, tests for parity, deletes the old dead code, and updates the catalog.

Reach for it when

The same button or card is copy-pasted across many files, hard-coded hex and spacing values are scattered around, or you want to make a growing UI consistent before it scales further.

You get

New reusable components and semantic tokens in the design system, every call-site migrated onto them, the old duplication removed, and updated docs.

Needs first

An existing (or agreed) shared-UI location, and a target area with real, repeated (3+) usage worth consolidating.

Watch out

Only extract things used three or more times with the same intent; premature abstraction is worse than duplication. Two things that look alike but serve different purposes stay separate, and not every value earns a token.

A design-director review that scores your interface and tells you what to fix first.

What it does

Picks one thing to judge (a page, a screen, a component), then runs two checks that never see each other: a human-style design review (does it look AI-made, how does it score against the classic usability rules, how heavy is the mental load, how would specific fake users cope) and a bundled automatic detector that, in a browser, paints the problems as coloured overlays on the live page. It weaves both into one written critique: a health score out of 40, a blunt AI-slop verdict, what is working, the most important problems each tagged P0 to P3 by user harm, and pointed questions. It saves the critique to a file so later commands can read the backlog, and stops to ask what you want to prioritise.

Reach for it when

You suspect it "looks like AI made it," you cannot tell what to fix first, or you want an honest quality score and an ordered to-do list before showing the work to anyone.

You get

A written design critique (score out of 40, AI-slop verdict, priority issues, persona red flags), a saved snapshot file, a trend line of recent scores, and an ordered list of follow-up commands.

Needs first

A resolvable target: a source file path or a URL (it prefers a source path). A browser makes the overlay evidence richer but is not required.

Watch out

This is the design and subjective review; for measurable numbers (contrast, performance, responsive) use audit. It only evaluates and recommends, it never edits your files, and it deliberately pauses to ask what matters before handing you the action list.

A technical health check of the code behind a web interface, scored and written up.

What it does

Runs measurable checks across five areas: accessibility (contrast, labels, keyboard, semantics), performance (janky animation, missing lazy-loading, wasteful re-rendering), theming (hard-coded colours, broken dark mode), responsive behaviour (fixed widths, tap targets under 44px, sideways scroll), and AI-slop patterns. Each area scores 0 to 4 for a health score out of 20. The report leads with a blunt "does this look AI-generated?" verdict, then every issue tagged P0 to P3 with its file location, its user impact, the standard it breaks, and a concrete fix plus the command that addresses it. It flags repeated mistakes and notes what is done well, but changes nothing.

Reach for it when

You want hard, checkable numbers rather than taste; you worry about accessibility failures or the layout breaking on phones; or you want a severity-ranked defect list before a release.

You get

A technical audit report with a score out of 20, severity-tagged findings (each with location, impact, the standard violated, and a fix), systemic-pattern callouts, and a prioritised command list.

Needs first

A web frontend to inspect. If the project is a native mobile app, it stops and hands off to a separate native audit path.

Watch out

This is the code-level counterpart to critique: use critique for a design eye on hierarchy, tone, and emotion, and audit for measurable engineering quality. It is web-only and it never edits code.

Hands-on redesign in the browser: click an element, pick a direction, flip between versions live.

What it does

You open your running site, click any element (a hero, a card, a button), optionally scribble a note and type a direction, then hit Go. It generates three genuinely different versions of that element and hot-swaps them into the live page, so you flip between them with no reload. Each version can carry a few tuning dials (density, colour amount, type scale) you drag to fine-tune on the spot. By default the versions stay inside your existing brand look, so you are choosing between angles on your product, not three different brands. When you accept one, it writes that version permanently into your real source files.

Reach for it when

You would rather try alternatives on a real page than read a report, you want point-and-click with instant results, or you want to iterate on one element and lock in the winner directly in code.

You get

Live, swappable variants injected into the running page to compare and tune, and, on accept, the chosen version baked into your real source code.

Needs first

A running dev server with hot-reload, or a static HTML file open in the browser. First use writes a small config, and a strict content-security policy may need a one-time dev-only allowance.

Watch out

Unlike critique and audit, this one rewrites your files. It stays inside your current brand about 90% of the time and only rebuilds from scratch when your notes or prompt explicitly ask; getting that wrong produces off-brand versions. After you accept, a mandatory cleanup folds the temporary styles into your real stylesheet.

The final meticulous pass that catches the small details separating good work from great.

What it does

A systematic last-step pass over a finished feature. It first learns the project's design system and aligns the feature to it, classifying every deviation as a missing token, a one-off reimplementation of something that already exists, or a flow that does not match neighbouring features, and fixing by root cause. It then works methodically through alignment and spacing, information flow, typography, colour and contrast, every interaction state, micro-interactions, copy, icons, forms, edge cases, responsiveness, and code cleanup. It can fold in the P0 and P1 items from a prior critique. It ends by swapping custom code for shared components and consolidating stray values into tokens.

Reach for it when

A feature is functionally complete and about to ship but feels slightly off: inconsistent spacing, some buttons missing hover or focus states, alignment not quite on grid, copy using different words for the same thing.

You get

A refined, design-system-aligned version with consistent spacing, complete interaction states, polished copy, handled edge and error states, and cleaned-up code.

Needs first

The feature must be functionally complete (polish is the last step, not the first), a design system or visible conventions to align against, and browser access to actually use the feature.

Watch out

Do not run it on unfinished work. A clean automated result is defect evidence, never proof the design is strong. When time is short, ship functional fixes before cosmetic ones and keep quality even rather than perfecting one corner.

Make a too-safe, forgettable design more distinctive and decisive, without falling into AI cliches.

What it does

Increases impact by making the existing design language more decisive, not by piling on effects. It first rejects the tired AI defaults (cyan and purple gradients, glass cards, neon on dark, gradient text on metrics), then splits register: brand bolder means a stronger point of view, product bolder means stronger hierarchy and sharper density, because theatrics undermine trust in a tool. It diagnoses what feels timid, locks the design system as a boundary, picks one focal point, and amplifies through type, colour proportion, density, and one meaningful motion moment, raising the contrast between primary, secondary, and tertiary content rather than making everything louder.

Reach for it when

The design feels safe and could belong to any product in the category, nothing leads the eye, everything is medium-weight, or a stakeholder calls it bland.

You get

A more distinctive, confident version with sharper hierarchy and one clear focal point, staying inside the documented system.

Needs first

An existing interface, ideally with tokens or a DESIGN.md as the boundary, plus clarity on the brand personality and audience (it asks if these are unclear).

Watch out

Bold means distinctive and confident, not chaotic or "more effects." For a product tool, amplify clarity, not drama. Never invent new colours, fonts, or shadows just because the request says bolder. If someone would instantly believe "AI made this bolder," start over.

Calm a design that is too loud, saturated, or overstimulating, without making it generic.

What it does

Reduces intensity with precision while keeping personality intact. Brand quieter means a more restrained palette, more whitespace, and more typographic air with the point of view preserved; product quieter means cutting visual noise so the tool disappears into the task. It finds the intensity sources (over-saturated colour, extreme contrast, too many bold elements, excess motion, clutter) and refines: desaturate and reduce the palette so neutrals dominate with colour as a roughly 10% accent, lighten weights and add breathing room, strip decorative gradients and glows, gentle the motion, and even out the spacing.

Reach for it when

The design feels aggressive or exhausting, colours are too bright, too many heavy elements compete, or you want a calmer, more premium feel for extended use.

You get

A calmer version with a softer palette, more whitespace, gentler and fewer animations, and consistent rhythm, with hierarchy and character kept.

Needs first

An existing design that is too intense, plus clarity on the purpose, the audience, and what is already working so good ideas are not thrown away.

Watch out

Quieter does not mean boring, grayscale, or flat. Keep hierarchy, keep some colour, keep personality (think luxury, not laziness). Quiet without intent collapses into generic.

Strip a cluttered design to its essence so nothing sits between the user and their goal.

What it does

A ruthless editing pass that removes anything not earning its place. It names the complexity sources (competing buttons, redundant information, too many colours and fonts, everything visible at once, decorative noise), asks what the single primary goal is, then simplifies across information (cut secondary actions, one primary action), visuals (one or two colours plus neutrals, one font at a few sizes, remove needless cards, never nest cards), layout (linear vertical flow, generous whitespace), interaction (fewer choices, smart defaults), content (cut every sentence, say it once), and code (remove dead CSS, flatten trees). Anything removed is documented.

Reach for it when

A screen feels cluttered or overwhelming, too many buttons compete, it is unclear what matters most, or users hesitate because there are too many paths forward.

You get

A pared-down version with one clear primary goal, a reduced palette and type scale, less chrome, a simpler layout, and shorter copy, plus a note on what was removed.

Needs first

An existing design that feels complex, plus clarity on the single primary user goal (it asks before cutting if this is unclear).

Watch out

Simplicity removes obstacles, not features. Do not strip necessary functionality, accessibility, or information users need to decide. Mystery is not minimalism; do not make things so bare they become unclear.

Make an interface survive real data, errors, languages, and bad networks, not just perfect inputs.

What it does

Stress-tests and reinforces a design against the reality a tidy demo hides. It probes extreme inputs (very long and very short text, emoji, right-to-left and CJK scripts, huge numbers, thousands of rows, no data at all), error scenarios (offline, slow, timeout, the common HTTP failures, validation, permission, concurrency), and other languages (30 to 40% text expansion, RTL layout, locale-correct dates and numbers). It then reinforces: overflow and wrapping, internationalisation with logical CSS and the Intl API, real error, empty, and loading states, client- and server-side validation, and accessibility and performance resilience, with concrete code patterns for each.

Reach for it when

The design only looks right with clean demo data, long names break the layout, there are no error or empty states, or it has never been tried offline or in another language.

You get

A more resilient interface with overflow handling, real error and loading states, internationalisation-ready layout, input validation, and accessibility and performance safeguards.

Needs first

A functional interface, knowledge of the real inputs and languages it must handle, and the ability to test with extreme data, a throttled network, and assistive technology.

Watch out

Never trust client-side validation alone; validate on the server too. Do not assume English-length text or an always-online user, do not let one component's error take down the whole page, and never ship a bare "Error occurred" message.

Design a first-run experience that gets users to first value fast, not one that teaches everything.

What it does

Designs onboarding whose only job is reaching the moment that proves the product is worth the user's time, not teaching the whole product. It defines that "aha" moment, the users' experience level, and a measurable success signal, then designs the pattern that fits: initial product onboarding (a clear value proposition, minimal setup, one to three core concepts, a guided first success), feature discovery (purposeful empty states, tooltips at point of use), guided tours (a few skippable, replayable steps), or an interactive sandbox. Every empty state gets a job: what will appear here, why it matters, and how to start.

Reach for it when

New users land on blank screens and bounce, they never reach the moment that shows value, empty states are dead ends, or first-session drop-off is high.

You get

An onboarding flow and empty-state design aimed at fast time to value: a welcome and minimal setup, a guided first success, contextual hints, and drop-off tracking.

Needs first

Two inputs it asks for: the specific aha moment you want users to reach, and the users' experience level. Plus a working product where users can reach real value.

Watch out

The job is first value, not teaching everything. Never force a long flow before people can use the product, never patronise with obvious explanations, never re-show onboarding to returning users, and always keep Skip easy to find.

Add motion that explains what the interface is doing, and cut motion that is just decoration.

What it does

Hunts for the spots where motion would actually help: buttons that click with no acknowledgment, state changes that snap, relationships that are not obvious, flat moments. It writes a deliberate plan with one signature "hero" animation plus lighter feedback and transition layers, rather than movement everywhere. It follows hard timing rules (roughly 100ms for feedback, 200 to 300ms for state changes, longer only for entrances) and a small set of approved easing curves, animating cheap properties like transform and opacity. Every animation ships with a reduced-motion fallback, and it checks the result runs smoothly and genuinely clarifies.

Reach for it when

Clicks and toggles feel dead, panels pop in and out abruptly, the page feels static, or loading happens with no acknowledgment. Also when the opposite is true: motion on everything, exhausting to use.

You get

Motion added into the interface code, organised around one hero moment plus feedback and transition layers, each paired with a reduced-motion fallback.

Needs first

An existing interface. On native platforms the setup step must point at the platform motion guide first. It asks if the personality or performance budget cannot be read from the code.

Watch out

Register pulls opposite ways: in brand work one rehearsed entrance wins, but the fade-and-rise reveal on every scrolled section is the tired AI tell; in product work motion mostly conveys state. Bounce and elastic easing are banned, and ignoring reduced-motion is an accessibility failure. If the motion does not clarify state, it should not ship.

Turn a timid grayscale or single-accent design into a deliberate, meaningful palette.

What it does

Diagnoses the current state (pure grayscale, one nervous accent, or colour at random) and identifies where colour would add meaning, hierarchy, or wayfinding. It commits to a colour strategy and a tight palette of two to four colours beyond neutrals, assigning a dominant, a secondary, and an accent by the 60-30-10 rule. Colour is applied with intent: consistent semantic meanings (green for success, red for error), accent reserved for the primary action and current selection, brand-tinted neutrals, and OKLCH for harmonious shade scales. It enforces contrast and colour-blind-safe pairings throughout.

Reach for it when

The design is all gray or leans on one washed-out accent, states are not visually distinct, everything is equally colourful so nothing stands out, or it has fallen into the purple-to-blue gradient look that reads as generic AI output.

You get

A strategic colour palette applied across the interface (semantic states, accent for primary actions, brand-tinted surfaces, contrast-checked), built in OKLCH with defined roles.

Needs first

An existing interface, and to know whether brand colours already exist (it asks if the direction or audience is unclear).

Watch out

Brand and product diverge sharply: a brand palette can let one colour own the page, while a product palette is almost always restrained and semantic-first. There is an absolute ban on coloured side-stripe borders thicker than 1px, on gray text on colour, and on the reflexive purple-blue gradient and warm cream tint. Use OKLCH, not HSL.

Replace generic default fonts at a flat scale with type that reflects the brand and has real hierarchy.

What it does

Runs two assessments kept deliberately apart: a human-judgment typography review (font choice, hierarchy, sizing, readability) and a mechanical scan that checks literal font sizes against the project's spec, so the machine's findings do not bias the visual judgment. It merges both and rebuilds the type system: a real font that fits the brand, a modular scale with clear size and weight contrast, comfortable line lengths and line-heights, and semantic token names. Verification is strict: each check is answered by citing a specific file or value, and the scan is re-run until nothing is left unresolved.

Reach for it when

The design uses invisible defaults (Inter, Roboto, Arial, system fallback), headings and body and captions are hard to tell apart, sizes sit too close together, body text is below 16px, or the type does not reflect the brand.

You get

A rebuilt typography system: brand-appropriate fonts with proper loading, a committed modular scale with real contrast, readability fixes, and semantic type tokens.

Needs first

An existing interface. The mechanical scan needs Node installed (a missing Node halts the scan rather than skipping it). It reads the DESIGN.md type ramp when one exists.

Watch out

Brand versus product changes what "good" means: brand work uses expressive, fluid sizing with a strong ratio, while product UIs can use familiar system stacks at a fixed scale (fluid sizing undermines dense layouts). A clean scan is a floor, not a pass: a generic font at a flat scale satisfies every automated rule, which is exactly what the human review catches. Bans include more than two or three font families, body text under 16px, and px font sizes.

Fix the spatial bones of a screen, spacing, hierarchy, and rhythm, instead of repainting the surface.

What it does

Treats space as the design material and hunts for the structural fault that makes a screen feel "off" even when colours and fonts are fine. It runs two checks kept apart: a human-style assessment (is spacing consistent or random, does the squint test still reveal what matters, are identical card grids repeated endlessly, is the page cramped or sparse) and a mechanical scan for off-scale spacing values. It merges them and establishes a consistent spacing scale (it prefers a 4-point base), tight grouping for related items and generous gaps between sections, the right tool for the job (flexbox for rows, grid for 2D structure), and stronger hierarchy from the fewest dimensions that work.

Reach for it when

The interface feels wrong but you cannot say why and the colours and type already look fine, padding is equal everywhere so nothing has a beat, the same card grid repeats down the page, or you cannot tell the most important element within about two seconds.

You get

A restructured layout with one consistent spacing system, clearer hierarchy, and deliberate tight and generous rhythm, plus a single findings list where each item is fixed or logged as an accepted exception.

Needs first

A target file, and the Node runtime reachable so the mechanical detector can run (a missing Node halts it rather than being skipped). A documented spacing scale sharpens the checks.

Watch out

The register split is load-bearing: for a brand surface, asymmetry and intentional grid-breaking are on-brand; for a product surface, predictable grids and consistent density are the goal. A clean scan is a floor, not a verdict: a monotone grid with perfectly uniform spacing passes every rule. Never introduce off-scale values, wrap everything in cards, or nest cards inside cards.

Add personality and small moments of surprise at the exact points that earn them, not everywhere.

What it does

Looks for the handful of moments where a bit of unexpected polish makes a functional interface memorable, on the principle that delight everywhere just reads as noise. It locates the natural moments (success states, first-run empty states, loading waits, milestones, hover, error recovery, hidden touches) and reads the context (is the brand playful or elegant, what is the emotional state, what is appropriate). Then it applies delight against firm rules: amplify and never block (quick, under a second, skippable), reward discovery rather than announce itself, match the emotional moment, and stay fresh on repeat use.

Reach for it when

A product works but feels forgettable, the success, empty, and error states are flat, the copy is bare system text like "Error 404" or "No projects," and every wait is a generic spinner.

You get

A small set of earned delight moments: micro-interactions, success celebrations, warmer copy, custom empty and error illustrations, and optional easter eggs, each quick, skippable, and accessible.

Needs first

A target interface plus a clear read on brand personality, audience, and the emotional tone of each moment (it pauses and asks if those are unclear). Optional animation or sound libraries if the technique needs them.

Watch out

Register decides the dose: a brand surface can carry personality throughout, while a product surface confines delight to specific moments. Match copy to the brand (a bank can be warm but not wacky), and avoid the AI-slop loading lines like "Herding pixels." Never delay core functionality for a flourish or make every interaction special (then none are).

Push one part of an interface past what people expect a web page to be able to do.

What it does

Aims to make one part of an interface feel extraordinary using the full power of the browser, and crucially that means how things feel, not just flashy visuals: a table that scrolls a hundred thousand rows smoothly, a dialog that morphs out of the button that opened it, a form that validates as you type. Because it has the highest chance of misfiring, it is forbidden from jumping to code: it must sketch two or three distinct directions with their trade-offs, stop and ask you to pick one, and only build the confirmed direction, drawing from a toolkit of view transitions, scroll-driven animation, spring physics, WebGL, virtual scrolling, and more, always with a graceful fallback.

Reach for it when

A design is already solid and you want one ambitious, signature moment; a hero should feel cinematic; a table, search, or form should feel impossibly fluid; and you are willing to pick a direction before code is written.

You get

One high-ambition, progressively-enhanced effect on a chosen surface, built only after you confirm a direction and refined through repeated browser previews, shipped with a fallback and a reduced-motion alternative.

Needs first

A target whose fundamentals are already sound (weak fundamentals get fixed with other commands first), browser preview available, and your approval of one proposed direction before any code (non-negotiable).

Watch out

Context is everything: a particle system that dazzles on a portfolio is embarrassing on a settings page. This changes how an interface feels, not what the product does. Never skip the propose-and-confirm step, ship effects that jank on mid-range devices, or stack several competing "extraordinary" moments; focus creates impact, excess creates noise.

Find the confusing or badly written words and rewrite them so people can finish the task.

What it does

Inspects the existing copy for clarity problems (jargon, ambiguity, passive voice, wrong length, unstated assumptions, tone mismatch) grounded in who the audience is and what state they are in. It sets a plan for each piece of text (the one thing the user must know, the action to take, the tone) and rewrites across specific surfaces one by one: error messages, form labels, buttons, help text, empty states, success and loading messages, confirmation dialogs, and navigation. It verifies the result for comprehension, brevity, and consistency. The reference also carries a deep UX-writing guide (an error formula, button patterns, a voice-versus-tone table).

Reach for it when

Copy is generating support tickets, buttons just say OK or Submit, errors read "Invalid input" or "Error 403," empty states are dead ends like "No items," or the same thing is called three different names.

You get

Rewritten interface text across the flagged surfaces: clearer errors, specific button labels, welcoming empty states, honest loading and success messages, consistent terminology.

Needs first

The actual interface text or target file. It asks for two things: the audience's technical level and the user's mental state in context.

Watch out

It only changes words, not layout, logic, or visuals, so it is the wrong tool for a structural problem. Never use humour for errors, never blame the user, and never vary a term just for variety.

Rework a design for a new context (a different screen, device, or use case), not just shrink it.

What it does

Names the design's original context and the assumptions baked in (big screen, mouse, fast connection), then defines the target context in detail: device, input method, screen size and orientation, connection speed, and what users expect on that platform. It calls out what will not fit and what will not work (hover on touch, tiny tap targets), then follows a playbook for mobile, tablet, desktop, print, or email, each with concrete layout and interaction moves. Implementation uses responsive breakpoints, grid and flexbox, container queries, and responsive images, verified on real devices before handing to polish.

Reach for it when

A desktop layout breaks or feels cramped on a phone, controls only appear on hover and so are unreachable on touch, tap targets are too small, or a screen needs a proper print or email version.

You get

A reworked, context-appropriate version (responsive CSS, adapted layout and touch behaviour, or a dedicated print or email variant) that feels native to the new context.

Needs first

An existing design to adapt and a clearly defined target context. Web only: native iOS, Android, or adaptive projects route to a separate native file.

Watch out

The central trap is treating adaptation as scaling; the job is rethinking the experience, not resizing pixels. Do not hide core functionality on mobile, do not use a different information architecture across contexts, and do not trust device emulation alone.

Find the one thing actually making an interface slow, fix it, and prove the numbers moved.

What it does

Insists on measuring first: current Core Web Vitals, load time, bundle size, frame rate, and the network waterfall, so the real bottleneck and who it hits are known before any change. It then applies targeted fixes by area: loading (modern image formats, correct sizing, lazy loading, code splitting, critical CSS), rendering (batching reads and writes, content-visibility, virtual scrolling), animation (GPU-friendly properties, 60fps), framework work (fewer re-renders), and network (fewer requests, pagination, compression). A dedicated section gives the target thresholds. It verifies with before-and-after measurements on real low-end devices and throttled connections.

Reach for it when

Pages take too long to load, scrolling and animation stutter, the JavaScript bundle is heavy, Core Web Vitals fail, or the layout visibly jumps as it loads, especially on mobile or slow connections.

You get

Concrete performance fixes aimed at the measured bottleneck, plus before-and-after metrics that show the user-facing numbers actually improved.

Needs first

The running interface and the tools to measure it (DevTools or Lighthouse, real devices, a throttled network). A baseline measurement is effectively required, since the whole method is measure-first.

Watch out

Do not optimise what is not slow; polishing micro-issues while ignoring the biggest bottleneck is a named failure. Do not sacrifice accessibility or break functionality for speed, do not sprinkle will-change everywhere, and do not lazy-load above-the-fold content. Measure on real devices, not desktop Chrome on fast wifi.

Make a standalone shortcut so a command can be typed directly.

What it does

Creates a shortcut so that, for example, typing /polish runs /impeccable polish directly. It writes the shortcut into every coding-tool directory the project has.

Reach for it when

You use one command constantly and want to stop typing the full /impeccable <command> form every time.

You get

A new /<command> shortcut available in the project.

Needs first

A valid command name from the set above.

Watch out

It is a convenience, not a new capability; the shortcut runs the exact same command.

Remove a shortcut created by pin.

What it does

Deletes a standalone /<command> shortcut that pin created, across the project's coding-tool directories.

Reach for it when

You no longer want a shortcut you pinned earlier, or it is colliding with something else.

You get

The /<command> shortcut removed.

Needs first

A command name that was previously pinned.

Watch out

Only affects the shortcut; the underlying command stays available through the full /impeccable <command> form.

Turn the automatic design-quality checker on or off, quiet it, or record deliberate exceptions.

What it does

Controls the impeccable "design detector" that runs automatically on direct edits to UI files. The first argument is an action, defaulting to status (prints the current state and every ignored rule, file, and value); on enables it and installs the hook, off disables it, the ignore actions register intentional exceptions, and reset clears the config. Different coding tools behave differently: one blocks a bad write before it lands, the others push a short reminder after the edit.

Reach for it when

The design nudges fire too often and you want them quieter or off, a flagged finding is actually intentional and you want to whitelist just that, or you are setting up a new project and want the checker installed.

You get

Updated hook settings (enabled or off, quiet mode, and the ignore lists), and a printed status report of exactly what is on and what is ignored.

Needs first

The skill installed for the on action. Some tools need a one-time approval before the hook fires.

Watch out

Never hand-edit the config files; always go through the command so the file stays valid. Only record an exception after confirming a finding was intentional, and prefer the narrowest one (ignore a single value, not a whole rule).