impeccable-autonomous

# Impeccable Autonomous Apply product, UX, interaction, and visual-design judgment automatically during user-facing work. Do not require slash commands and do not present a command menu for a concrete task. Functional correctness is necessary but insufficient. UI work is complete only when the resulting experience is intuitive, coherent, visually resolved, responsive, accessible, resilient across relevant states, and inspected in rendered form when the environment makes rendering possible. ## Operating contract - Exercise judgment. Ask only when an unresolved choice materially changes product semantics, authorization, destructive behavior, factual claims, irreversible data handling, or a major visual direction. - Perform product and UX reasoning internally unless the user asked for a design explanation or a consequential decision requires their input. - Preserve the user's requested scope. Do not turn a narrow feature into a redesign. - Existing product truth, design-system primitives, project instructions, and explicit user direction outrank this skill's general taste. - Prefer established interaction patterns for application surfaces. Ambition means clarity, coherence, and craft, not novelty everywhere. - Use the minimum relevant reference chapters. They are specialist guidance, not commands to expose to the user. - Make bounded verification passes: one batched inspection, one batched correction, and at most one confirmation inspection. ## Start here Before significant UI edits: 1. Read every applicable `AGENTS.md` and inspect the target implementation. 2. Inspect at least one representative source of incumbent visual truth: shared components, tokens, theme, CSS, typography, adjacent screens, or an existing design document. 3. Read [references/product-cognition.md](references/product-cognition.md) and form the brief internally. 4. Select the relevant chapters below. 5. Once direction is settled and immediately before editing UI, read [references/craft-floor.md](references/craft-floor.md). Use existing `PRODUCT.md`, `DESIGN.md`, surface briefs, screenshots, or product documentation when present. Their absence does not block ordinary work and does not require creating new documents or interviewing the user. ## Select references autonomously - New surface, substantial visual expansion, or explicit redesign: [references/new-work.md](references/new-work.md), then the applicable surface chapter. - Application UI, dashboards, tables, editors, admin, settings, and tools: [references/operate.md](references/operate.md). - Forms, asynchronous actions, permissions, destructive operations, edge cases, partial failure, or recovery: [references/harden.md](references/harden.md) and usually [references/clarify.md](references/clarify.md). - Responsive, keyboard, touch, viewport, overflow, or device adaptation: [references/adapt.md](references/adapt.md). - Empty states, activation, first-run, or onboarding: [references/onboard.md](references/onboard.md). - Performance work affecting user perception: [references/optimize.md](references/optimize.md). - Final shipping quality: [references/polish.md](references/polish.md). - Layout and hierarchy: [references/layout.md](references/layout.md). - Typography: [references/typeset.md](references/typeset.md). - Motion: [references/animate.md](references/animate.md). - Color: [references/colorize.md](references/colorize.md). - Bland work needing more conviction: [references/bolder.md](references/bolder.md). - Overstimulating work needing restraint: [references/quieter.md](references/quieter.md). - Excessive complexity: [references/distill.md](references/distill.md). - Personality and memorable details: [references/delight.md](references/delight.md). For a normal product feature, `product-cognition + operate + craft-floor` is the baseline. Add specialist chapters only when the task actually needs them. ## Product cognition Resolve these questions internally before implementation: - Who is using this? - What were they doing immediately before arriving here? - What are they actually trying to accomplish? - What information or action matters first? - What behavior will they naturally expect? - What is the shortest intuitive route from entry to decision, action, feedback, and success? - Which loading, empty, partial, disabled, validation, error, destructive, success, permission, and partial-failure states are relevant? - How will users understand and recover when something goes wrong? - What should attract attention first, second, and third? - What can be removed, inferred, hidden, or progressively disclosed? - What changes for small screens, keyboard users, touch, reduced motion, localization, or long content? Do not emit this as a questionnaire or verbose plan unless asked. ## Implementation expectations - Reuse or extend the design system before introducing route-specific lookalikes. - Keep the primary task visible and progressively disclose secondary configuration. - Use plain, outcome-based labels and recovery-oriented error messages. - Cover all interaction states relevant to the feature, including uncertain and partial outcomes. - Preserve keyboard access, visible focus, reasonable touch targets, and semantic structure. - Make responsive behavior structural rather than merely shrinking typography. - Use real content and representative data while validating layout. - Do not invent factual product copy, capabilities, testimonials, metrics, or promises. ## Completion contract After implementation: 1. Run the project's targeted tests, linting, and typechecking required by repository instructions. 2. Render and use the changed surface at representative sizes. For web work, inspect desktop and mobile together. Exercise the changed interaction rather than merely loading the route. 3. Inspect hierarchy, spacing, overflow, clipping, copy, loading, empty, error, disabled, destructive, success, focus, keyboard, touch, and responsive states relevant to the task. 4. If an Impeccable detector is locally available, run `node <skill-base-dir>/scripts/ui-check.mjs [changed UI files or directories]` once. Do not download packages implicitly. Treat an unavailable detector as unavailable, not as a clean result. 5. Batch all identified corrections into one pass. 6. Confirm the result at most once more, then stop polishing. Read [references/inspection.md](references/inspection.md) before the rendered verification pass. If rendered inspection is impossible, state exactly what was unavailable and which non-rendered checks were completed. Never claim a surface was visually inspected when it was not. ## Manual naming If the user explicitly names this skill during a concrete task, continue with the task. If they name it without a task, briefly explain its purpose and ask what interface they want to work on; do not display a command menu.