Generated banner for Impeccable
Generated logo for Impeccable

Impeccable

Paul BakausCommunityCreated by Paul Bakaus

  • Skill
  • Workflow
  • Design and creative
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Use to design, redesign, critique, audit, polish or animate a frontend: websites, landing pages, dashboards, app UI, components, native iOS/Android screens, or a design system (DESIGN.md).
— the description by Paul Bakaus

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Impeccable provides a structured approach to designing, auditing, and refining frontend interfaces including websites, dashboards, and mobile applications. It operates by establishing product context through documentation and applying specific design modes—Persuade, Operate, Read, and Experience—to guide the visual and functional direction of a project. The skill supports a wide range of tasks from initial planning and documentation to technical audits, visual refinements, and animation, ensuring that design changes remain consistent with the established visual world.

What it does

  • Audits UI for accessibility, performance, and responsive behavior.
  • Generates design documentation from existing project code.
  • Refines visual elements through commands like colorize, typeset, and layout.
  • Provides tools to plan UX and UI before implementation.
  • Manages design system tokens and component extraction.
  • Supports iterative design through live variant generation and testing.

When to use it

  • When you need to perform a UX critique or technical audit of an existing interface.
  • When starting a new design surface or defining a new visual world.
  • When you need to polish or refine UI components before a release.
  • When you need to adapt an interface for different screen sizes or platforms.
  • When you need to add purposeful animations or improve typography hierarchy.

Advantages

  • Provides a consistent framework for design decisions across different project types.
  • Integrates technical audits directly into the design workflow.
  • Supports specific modes to align design output with user intent.
  • Enables structured documentation of product and design context.
  • Offers granular control over UI refinements through specialized commands.

Usage examples

“impeccable audit src/components/Dashboard.tsx”
The agent performs a technical quality check on the dashboard component, reporting on accessibility, performance, and responsiveness.
“impeccable polish src/landing-page.css”
The agent executes a final quality pass on the landing page styles to ensure visual consistency and adherence to the design system.
“impeccable animate hero-section”
The agent applies purposeful motion and animation to the specified hero section based on the project's design mode.
“impeccable init”
The agent captures the current project context and creates a PRODUCT.md file to serve as the foundation for future design work.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/pbakaus/impeccable/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip impeccable.zip -d .agents/skills

Documentation by Paul Bakaus

This skill gives you the tools and permission to make design that earns the name out-of-distribution craft. Work as an award-winning design director would: production-grade code, a clear POV, a deep grasp of what the client and its users need, and exceptional craft.

Core principles:

  • Finish the job. No hedging, no shortcuts: the deliverable is complete, except assets the user must provide.

  • Scale ambition to the surface's mode (see Modes). Persuade and Experience get full commitment: bold, distinct work with a point of view. On Operate and Read, ambition shows as precision and restraint, and patterns the visitor already knows earn their place.

  • Verify by looking at the rendered result at the sizes it ships at, and batch the checks: fix what one look shows before looking again, rather than screenshotting after every tweak.

Setup

  1. Run "${CLAUDE_SKILL_DIR}/scripts/impeccable" context once per session, where ${CLAUDE_SKILL_DIR} is the directory that contains this SKILL.md (the skill folder, not a plugin root two levels above it); keep cwd at the user's project. Every "${CLAUDE_SKILL_DIR}/scripts/impeccable" <verb> command in this skill and its references resolves against that base directory. In reference files, replace the skill-base-dir placeholder with this directory before running commands; it is not a shell variable. On a Windows shell without sh, call & "${CLAUDE_SKILL_DIR}/scripts/impeccable.cmd" instead. The launcher runs a self-contained binary that ships next to it or is downloaded once on first run; no Node or other runtime is required. Pass a named source file or route as --target <path>. It loads PRODUCT.md, DESIGN.md, the matching surface brief, and native-platform guidance when applicable; follow its directives and do not rerun it.

  2. Load the request's playbook: its Commands-table reference for an explicit/implied sub-command, or reference/new-work.md for a new surface or replacement visual world. Inspect target and incumbent visual truth before editing. When the app cannot run, start with committed visual-regression goldens or screenshot fixtures; verify target and freshness against current tokens, CSS, components, or assets, resolve conflicts, and compare theme/variant captures.

  3. After resolving analysis and direction, read reference/craft-floor.md immediately before any UI edit, including small refinements. It carries the quality floor, the absolute bans, and the reflexes no detector catches. Do not load it for planning-only work.

Launcher unavailable: On refusal or failure, send a separate message before the next tool call: “Context loading did not run; I’ll read the existing project context directly.” Then read existing PRODUCT.md and DESIGN.md without inventing missing context, follow applicable steps 2–3, including reading reference/craft-floor.md immediately before any UI edit, and continue through permitted tools. This applies to planning and editing; launcher failure alone does not block either.

How to design

  • The brief wins. Honor pinned aesthetics, eras, materials, fonts, and palettes even when they conflict with a saturated-pattern warning. Redirecting a clear brief toward your taste is failure.

  • Refinement preserves; redesign replaces. Refinement keeps the incumbent identity, behavior, copy, and everything outside scope. Ask before replacing factual copy or adding claims. Redesign keeps product truth, content, function, native affordances, and constraints, but treats the old look as evidence and anti-reference; choose a replacement world in new-work and replace DESIGN.md. Never split the difference into polish on the discarded look.

  • Loaded symbols stay out of the decoration. A subject's world does not license emblems tied to militarism, supremacy, or hate movements as motifs, badges, or ornament, such as the Rising Sun flag's rays, the Confederate battle flag, or Nazi-era insignia and their stylised variants; reach for that world's neutral forms instead. Content that documents such a symbol as fact stays as it is.

  • Visual authority is evidence, not a filename. Missing DESIGN.md alone does not make a project greenfield; new-work decides whether to preserve, expand, or replace the incumbent world.

Modes

The mode names what the visitor's success looks like on this surface.

  • Persuade: the visitor decides and acts; design is the product. Landing pages, marketing, campaigns, pricing. Earn attention and action. Ship real imagery when the brief needs it; follow the committed world, not category habit.

  • Operate: the visitor completes a task. App UI, dashboards, editors, admin, settings, tools. Scanability, consistency, native expectations, and the real usage scene outrank expression. Brand lives in precise details.

  • Read: the visitor understands something. Docs, articles, guides, help, changelogs. Structure for comprehension, then make the reading experience worth staying in.

  • Experience: the visitor is inside the work itself. Portfolios, galleries, showcases. Let the artifact lead from the first viewport; the interface recedes.

Choose the mode from the requested surface, not the product, and persist it only in that surface brief. A tool's landing page is still Persuade; a fashion house's documentation is still Read; a docs index is Read, not Persuade. See new-work.md for new surfaces and operate.md for deeper Operate/Read guidance.

Commands

CommandCategoryDescriptionReference
craft [feature]BuildDeprecated alias for an ordinary new-work requestreference/craft.md
shape [feature]BuildPlan UX/UI before writing codereference/shape.md
initBuildCapture durable product context in PRODUCT.mdreference/init.md
documentBuildGenerate DESIGN.md from existing project codereference/document.md
extract [target]BuildPull reusable tokens and components into design systemreference/extract.md
critique [target]EvaluateUX design review with heuristic scoringreference/critique.md
audit [target]EvaluateTechnical quality checks (a11y, perf, responsive)reference/audit.md · native: reference/audit.native.md
polish [target]RefineFinal quality pass before shippingreference/polish.md
bolder [target]RefineAmplify safe or bland designsreference/bolder.md
quieter [target]RefineTone down aggressive or overstimulating designsreference/quieter.md
distill [target]RefineStrip to essence, remove complexityreference/distill.md
harden [target]RefineProduction-ready: errors, i18n, edge casesreference/harden.md
onboard [target]RefineDesign first-run flows, empty states, activationreference/onboard.md
animate [target]EnhanceAdd purposeful animations and motionreference/animate.md
colorize [target]EnhanceAdd strategic color to monochromatic UIsreference/colorize.md
typeset [target]EnhanceImprove typography hierarchy and fontsreference/typeset.md
layout [target]EnhanceFix spacing, rhythm, and visual hierarchyreference/layout.md
delight [target]EnhanceAdd personality and memorable touchesreference/delight.md
overdrive [target]EnhancePush past conventional limitsreference/overdrive.md
clarify [target]FixImprove UX copy, labels, and error messagesreference/clarify.md
adapt [target]FixAdapt for different devices and screen sizesreference/adapt.md · native: reference/adapt.native.md
optimize [target]FixDiagnose and fix UI performancereference/optimize.md
liveIterateVisual variant mode: pick elements in the browser, iterate on alternativesreference/live.md
generate [n] [action] [element]IterateVariants, versions, or alternatives of a named element to choose from in the live browser; no manual pickingreference/generate.md

Routing:

  • No argument: read routing.md and present its context-aware menu; never auto-run a command.

  • Explicit or clearly implied request to run a command: load its reference (native variant on native platforms) and follow it. Ask once if two commands fit.

  • Workflow or command-selection question: read Workflow questions.

  • Otherwise: treat the request as general design work. Missing PRODUCT.md routes a new surface or replacement world through init, then new-work; a narrow refinement of existing code proceeds on the incumbent implementation as impeccable context directs, offering init afterward rather than blocking on it.

  • teach aliases init. craft is a deprecated alias for ordinary new-work and adds nothing. shape owns task discovery, then enters new-work only for visual-world and surface-concept decisions.

After init writes PRODUCT.md, resume without rerunning impeccable context; init loads the native platform reference itself when the platform it recorded is ios, android, or adaptive.

Pin / Unpin: "${CLAUDE_SKILL_DIR}/scripts/impeccable" pin <pin|unpin> <command> creates or removes a standalone /<command> shortcut. Report the script's result concisely; relay stderr verbatim on error.

Hooks: /impeccable hooks <on|off|status|ignore-rule|ignore-file|ignore-value|reset> manages the design detector hook for this project (auto-runs the detector after UI file edits and surfaces findings). Load reference/hooks.md when the user invokes it with any argument.

Doctor: /impeccable doctor reports and repairs drift between this project's Impeccable artifacts (PRODUCT.md, DESIGN.md and its sidecar, config, surface briefs, the hook) and what this version reads. Load reference/doctor.md when the user invokes it, or when they ask what is out of date, stale, or needs refreshing. A CONTEXT_STALE directive in Setup's output is the cheap subset of the same report; act on it there per its own instructions rather than running doctor unasked.

Never repair drift as a side effect of a design task. A CONTEXT_STALE finding is reported, not acted on, unless the user asks. The one exception is a finding marked auto, which the next write to that file performs anyway.

Files

reference/visualize.md

Visualize: Direction Comps & Asset Production

Load this from new-work.md on a comp-led build, when image generation is available (a harness-native tool or the API fallback impeccable context reports). A code-led contract skips this file by design, not by drift; do not load it then. PRODUCT.md is a precondition; DESIGN.md is one only on an established world, since a new or replacement world writes it at the finish. The MODE RULES block concept-seed printed for this surface (COMPS) governs these comps together with this file and wins where they conflict; with no roll this session, read the mode's file named in new-work.md. New-work has already resolved the visual world; this file must not reopen it. A surface-scope structure round that already put three visualized cards before the user (new-work.md, established world) has discharged this round: the locked card's comp is the approved comp, so record the approval and continue at After approval; generate nothing new.

A probe tests composition, narrative, hierarchy, density, focal moment, signature use, and image requirements. It is not a second identity workshop. Keep the world's palette, typography direction, material language, component character, imagery stance, and motion grammar fixed: DESIGN.md's on an established world, the chosen direction's on a new one.

Generate three compositional options

The comp round runs inside the build's phase state: impeccable build-phase start --direction <seed reference> has already run (with --decision-comp <path> when the chosen card has a decision comp) and its comps phase is open before the first comp is generated; a comp rendered before that sits outside the state, and a session resumed from that point has no phases to follow. impeccable generate-image refuses to write under .impeccable/mocks/ until start has run; a harness-native image tool is bound by the same order.

Render three distinct high-fidelity north-star comps of the requested surface, saved under .impeccable/mocks/ so they survive the session. When the chosen card has a decision comp, it is option one: it stays at its path under .impeccable/mocks/decision/, where the gate counts it through --decision-comp, and is never regenerated; render the other two. Comp at the surface's own viewport: portrait at device size for a native app or mobile-first surface, desktop landscape otherwise; a phone screen comped landscape misstates the composition before anything is built against it. Comps are the build thread's own work, never delegated: the thread that writes the prompts holds the direction's full context and has seen every comp when the build starts. Open every image by its workspace-relative path; sandboxed viewers reject absolute paths, and everything under the project root has a relative one. Base the comps on real content and the surface concepts already developed with the user. On an established world, anchor every comp on the real identity: capture a screenshot of a representative existing page and pass it as a reference image (the harness image tool's input image, or impeccable generate-image --ref); the prompt leads with the new surface's structure while the reference carries palette, type, and component character, because DESIGN.md words alone drift where a pixel reference does not. Name what the reference contributes and what it must not: chrome, palette, type, and component character carry over; the reference page's own content does not, and a banner, hero, or card lifted verbatim is the reference leaking, not fidelity. Three is the number: one comp invites rubber-stamping; the spread between three surfaces the composition worth building. The chosen card's decision comp is the first of the three: it already renders this direction at full fidelity under this discipline, so generate two more that vary what the first held fixed, from the direction in words rather than with the first comp as an input image (a reference image anchors the layout, and three comps collapse into one composition). How comps two and three vary from the first is the mode's call, in its COMPS rules. A variant that simplifies the first into a tidier version of itself adds no choice to the round. Send all three to the approval point together. Only a round arriving with no decision comp (a degraded roll, an identity-mode page, a direction pinned without the decision round) renders all three here.

  • A comp prompt is short, 150 to 300 words, and carries only what the image model cannot know. The model draws what the prompt names and stops deciding whatever the prompt pins down, so a prompt that specifies everything gets back a template. Open with the surface: the kind of screen it is (a desktop web app, a documentation page, a landing page, a native app screen at its device viewport) for the product, by name, rendered edge to edge with crisp readable text and no browser window, device, or desk around it. Then the product and the visitor's job in plain words, with the real content that answers it: names, numbers with units, the offer or the state, any claim at its honest certainty, and the next action by name. Then what leads this comp, its product concept (summary-led, timeline-led, offer-led, reference-led), and the parts the screen holds in reading order, a phrase each. Then the frame in one line: the product's mark and name, its navigation, its utility controls, and the far edge, so the comp is a finished screen, never a fragment; a page with no navigation says so instead of inventing one. Leave sizes, positions, colours, and component styling out, except a colour, typeface, or brand element the user pinned: that is content, so state it. Self-check every render: if it could hang as a poster, or reads as a photograph with some text on it, it is not a comp; regenerate.

  • The look comes from the world, and from a picture wherever one exists. An established world has the screenshot reference above: it carries the look, so the prompt adds one sentence on what the reference contributes and nothing more about style. A catalog world has card images: attach its board and hero as reference images (the NEXT line names them; impeccable generate-image --ref <board> --ref <hero>, or the harness image tool's input images) and write one sentence, that the references are style inspiration adapted into a real working product, their layout and content not to be copied. Describing the style as well overrides the picture. A direction with no card images carries its look in two to four sentences of concrete visual law: the ground and main colours with what each does, the type voices, and the one signature that makes it recognisable. No path lists colours past the main few or describes components one by one.

  • The subject must be in it. Before accepting a render, point at the subject: a render that depicts the world and nothing of the subject fails however faithful its atmosphere, and the deletion usually rides in on an exclusion list. Regenerate with the subject's content named.

  • Judge a comp as the shipped screen: the visitor's job must be readable from the image alone. Name the surface's mode from the render with no caption; a render whose mode cannot be read back is art direction without a surface. Regenerate with the visitor's job as the prompt's spine.

  • Commitment is depth, not performance spread across regions. The world enters through one dominant move plus the material, type, and spacing that support it; the remaining regions hold still in that material and keep their content at real reading size. A second element competing with the lead at the same scale is the comp shouting: regenerate keeping the strongest move and quieting the rest. Busy is louder, not bolder.

  • When the user shortlisted multiple concepts, spread the three across them.

  • When one direction is committed, vary the structural uncertainty an image can resolve: what leads the screen, topology, sequence, density, hierarchy, focal composition, or interaction framing.

  • Show enough beyond the opening moment to prove the concept can govern the whole surface.

  • Do not generate a palette artifact, ask new atmosphere questions, introduce a different type voice, or invent a new motif. If the committed world cannot support the concept, return to the concept shortlist rather than changing the world.

Each comp is a direction test, not a screenshot specification. Core UI text, responsive behavior, accessibility, semantics, and interaction states remain implementation responsibilities.

One approval point

Show the three together on the decision page (impeccable serve-question, one option per comp with the comp as its hero), or in the harness only when it renders images inline; a text-only surface does not count as display. Ask what should carry forward, what feels false to the world, and whether the selected concept should be approved, combined, revised, or rejected. Then stop and wait. A structured simulated user counts as attended and receives the same question.

Do not begin code until the user approves a direction or explicitly delegates the choice. If they delegate, choose using the task brief, PRODUCT.md, and DESIGN.md (the chosen direction on a new world), and state the evidence. Approval refines the task concept; it does not modify DESIGN.md.

This approval point has no substitute and no skip condition. When the structured question tool errors, fall back to the decision page; only after both fail may you treat the choice as delegated, and a delegated pick is recorded exactly as an approval is and disclosed in your first reply, not your last. The finish reviewer treats comp-round comps with no recorded approval as a material finding; decision comps under .impeccable/mocks/decision/ are the direction round's hand, not comp-round output, and imply no approval on their own.

After approval, record the choice where tools can find it: the approved comp's path goes in the surface brief, and its prompt sidecar (the image's full file name plus .json: a.png gets a.png.json) gains "approved": true (every comp generated through impeccable generate-image has one; create it if a native tool didn't). The sidecar travels with the mocks folder, so the approval survives sessions and machines that never see the brief, and it is what impeccable build-phase advance reads to close the comps phase. Summarize the composition and the parts of the comp that must not be literalized, return to new-work.md, record the direction contract from the approved concept, and build.

After approval: the comp becomes a spec

The approved comp is a north star for translation into semantic, responsive, accessible code, never a license to recompose: keeping the palette and mood while redrawing the topology is a second art direction. Do not rasterize core UI text or controls. Do not substitute a different visual driver after approval without asking.

What the comp shows is measured, not remembered. new-work.md section 6 runs the build as phases (impeccable build-phase): the spec phase turns the comp into region boxes with sampled palettes (impeccable comp-spec), and the medium of every region follows from what the pixels are, never from what feels buildable: a figure, a product object, machinery, any illustration with perspective, shading, or drawing skill in it, and any texture by name (woven cloth, paper grain, fabric, leather, brushed metal) is a plate / image / texture region and ships as a raster; text, controls, chrome, diagrams with countable elements, flat shape systems, and anything that must move, scale, or respond are semantic. Writing "CSS" for a sculpted panel's finish, or a many-vertex clip-path for a torn edge, is the quiet deletion of the approved design; the detector's organic-clip-path and buried-raster rules and the hero gate's region scores catch it. Dropping an image-native region is a scope decision the user makes at the approval point, never a silent flattening after it. Generated imagery is a material, not a claim: evidence rules bind assertions, specs, testimonials, and photographs presented as real, never render fidelity.

Plates and provenance

Every raster region's plate is produced in the plates phase, before any page code, by the shipped asset producer or in the current thread (use impeccable comp-spec --crop <id> and save impeccable comp-spec --plate-prompt <id> to a prompt file; pass the crop and prompt to the harness image tool, or use impeccable generate-image --ref <crop.png> --prompt-file <prompt.txt> --out <plate.png> --size <WxH> --quality high). For isolated cutouts, add --background transparent to both the plate-prompt and API generation commands; use native PNG alpha and preserve white paint and clear gaps. Use --background opaque for full-frame imagery. Create output directories first and inspect alpha on light and dark grounds. Generation context is part of the asset: after generating any image with any tool, run "<skill-base-dir>/scripts/impeccable" embed-prompt <image> --prompt "<prompt>" with the exact string the tool received (impeccable generate-image does this itself), so the intent lives inside the file; --read recovers it, --scan <dir> lists rasters still missing one. The embedded prompt plus the region's row in the spec is the raster's provenance, and every raster the artifact references carries it; a sourced, stock, or pre-existing raster embeds its origin instead. A raster created or replaced later, in a fix batch or a reviewer's rebuild, is produced the same way; a raster a fix abandons is deleted in the same batch.

Convert images with a converter impeccable context reported at boot (the IMAGE_TOOLS line); probe only when it reported none, at most once per session, never per image.

Return to new-work.md for the direction contract, the phased build, and the finishing pass.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs Node.js

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Paul Bakaus
Publisher
Paul Bakaus (Community)
Source
pbakaus/impeccable · plugin/skills/impeccable · commit 687bc38
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Paul Bakaus.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download impeccable.zip