Impeccable Editorial Poster Design System

The problem it solves

Design-system documents often stop at aesthetic language: “modern, premium, brand-aligned,” while engineers still do not know how to implement a button, card, or form with consistent spacing, states, focus behavior, overflow handling, and empty states. @user_fccf428b/impeccable addresses this by turning the Impeccable editorial-poster style into executable design rules that can be used during component development and code review.

How the skill works

The skill follows a structured guideline-authoring workflow: it first restates the design intent, then defines design tokens, then moves to component-level rules, and finally produces testable acceptance criteria. The core capabilities include:

• Foundational rules: it anchors the system to a 12/14/16/20/24/32 type scale, a 4/8/12/16/24/32 spacing rhythm, and explicit color tokens such as primary=#CC8800, secondary=#C55221, and text=#111827.
• Component rules: it expects explicit anatomy, variants, and interaction states, including default, hover, focus-visible, active, disabled, loading, and error, with behavior defined for keyboard, pointer, and touch.
• Accessibility boundaries: it treats WCAG 2.2 AA as a baseline, emphasizing visible focus states, keyboard-first interaction, and anti-patterns such as low-contrast text and ambiguous labels.
• Output structure: it consistently generates context and goals, tokens and foundations, component rules, accessibility requirements, content tone standards, anti-patterns, and a QA checklist.

It works best as a design-system drafting tool. When given a specific component, interaction goal, existing tokens, and edge cases, it can produce implementation-focused guidance rather than a generic brand description. This is useful for teams that need consistent frontend implementation, clearer component-state documentation, or a way to reconcile inconsistent UI patterns.

Scope and caveats

The skill does not replace design review or automatically refactor existing component code. Its output quality depends on how concrete the input is: a request like “build a marketing homepage” will produce higher-level guidance, while a request describing a component, interaction states, tokens, and failure cases will produce much more actionable rules. It also prioritizes system consistency over isolated aesthetic novelty, and when aesthetics conflict with accessibility, the guidance favors testable accessibility and clarity.