Impeccable by pbakaus

Use Impeccable by pbakaus to design, critique, and refine frontend interfaces through one Skill and its commands. Review hierarchy, typography, responsive behavior, and edge cases, preserve the project’s intended identity, and inspect rendered results as you improve the surface for its actual users.

Audit a form before redesigning it

Choose whether the interface needs an audit, refinement within an approved direction, or stronger edge states. The prepared request keeps that distinction explicit, with product context and representative screen checks guiding changes rather than an open-ended redesign.

Describe the form, user task, keyboard behavior, and empty or error states.

Copy the request into a new Floatboat conversation and provide the required material.

Download Floatboat

Your request for Floatboat

Preview and copy the request. It is not sent automatically from this page.

Reference: Impeccable
https://github.com/pbakaus/impeccable/blob/main/.agents/skills/impeccable/SKILL.md

Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding.

My task:
Use Impeccable to audit this checkout form. Preserve the existing visual identity, focus on hierarchy, keyboard use, validation, and empty or error states, and report findings before editing.

Expected deliverable:
A focused interface audit with prioritized changes, before any edits are made.

About Impeccable

Impeccable is a design Skill and supporting tool workflow published by pbakaus. Its single Skill routes interface tasks to commands such as audit, critique, polish, and harden, rather than treating each command as a separate capability package. The current distribution includes a launcher and a self-contained engine, with provider-specific installation and optional native hooks. It reads project context to distinguish refinement from redesign and adjusts the approach to the type of surface. Use it with a concrete interface, a user task, and the identity or behavior that must remain. Installation details differ by host, and rendered verification remains part of the design work.

Use Cases for Impeccable Skill

Interface audits, final polish, and edge-state repairs should not reopen the same design decisions. Explore how Impeccable distinguishes finding problems from refining an approved direction and checking forms, loading behavior, or absent data.

Audit an existing interface

An interface audit needs a known screen, the user's task, and current screenshots or code. Focus the critique on hierarchy, interaction, accessibility, and responsive states that affect that task. Prioritize findings by severity and the states they occur in so implementation can address concrete problems instead of general taste.

Polish a nearly finished page

A nearly finished page can be polished without changing its approved visual direction. Refine typography, alignment, spacing, and consistency against the implementation that already works, checking accepted interactions as you go. The result should improve reading rhythm and coherence without reopening settled product or behavior decisions.

Harden form and edge states

Forms and asynchronous screens need clear guidance when input is invalid, a request is loading, or data is absent. Review those states against the form rules and representative examples, then complete the missing feedback. Check that the user can understand what happened and what to do next beyond the ordinary success path.

Establish product context before designing

A new design task needs durable information about the audience, product, and constraints before visual refinement starts. Use the documented initialization flow where appropriate and review the context it records, separating product facts from a temporary visual preference. Later audit or implementation work can then refer to an agreed brief instead of reconstructing the purpose from an isolated screenshot.

How to Use Impeccable

Impeccable work starts with the host setup and product context, including initialization where required. Define whether the task preserves an approved direction or redesigns it, then check rendered results at representative sizes rather than treating every critique as authorization to rebuild.

  1. Install and initialize the project

    Use the provider-specific installer and reload the host. In a new project, run /impeccable init inside the agent to establish PRODUCT.md; for an existing project, review that context and follow any hook-trust prompts.

  2. Scope the interface task

    Provide the route or source file and explain what must remain. Choose the relevant command and distinguish refinement from redesign.

  3. Review rendered changes

    Inspect the updated interface at the sizes it supports. Verify interaction and content, then refine the issues that the rendered result reveals.

Explore More Agent Skills

Read another Skill guide and check its original source before using it.

Impeccable FAQ

Are audit and polish separate Skills?
In the current distribution, commands route through the single impeccable Skill. Standalone shortcuts can be pinned, but that does not make each command an independent package.
Does a plain SKILL.md copy install the complete setup?
No. The current workflow includes references, a launcher, an engine, and provider-specific packaging. Use the documented installer or complete distribution for your host rather than copying only the entry file.
Why does installation mention hooks?
Some providers receive native hooks in addition to the Skill. Their trust and activation rules differ by host; follow the upstream verification instructions and review any requested project hook approval.
Does Impeccable require Node at runtime?
The README describes a self-contained engine launched by a small script. Node is used by the npx installer path; the manual and Git setup paths have different requirements. The engine may be downloaded on first use.
Will a refinement request replace my whole design?
The source distinguishes refinement from redesign. State which identity, content, behavior, and scope must stay; a refinement should work within those constraints rather than silently choosing a new visual world.
Can I use it when the app cannot run locally?
The source allows inspecting existing visual evidence and project context, but freshness and correspondence matter. Mark what cannot be rendered or verified instead of presenting a source-only review as a tested interface.