Paul BakausandClaude Opus 4.7
2341fe3637
Adds a coarse-controls ("Tune") popover that slides out from behind the
contextual bar via clip-path, showing 2-4 per-variant knobs (range / steps /
toggle) driven by a `data-impeccable-params` manifest. Range/toggle drive
CSS custom properties on the variant wrapper; steps toggle a data
attribute. Values reset per variant; on accept, current values are passed
through live-poll to live-accept as an `impeccable-param-values` comment
for the carbonize cleanup step to bake in.
Other live-UI work in this change:
- Theme-aware palette (barPaletteForTheme) now drives the contextual bar,
action picker, and tune popover. Dark sand on light pages, paper on
dark. Detection has a localStorage dev override for QA.
- Action picker chips get inline SVG icons (wand / bars / funnel / sparkle /
type ramp / circles / grid / devices / curve / star / bolt) stacked
above the label; selection state recolors via currentColor.
- Accept button switched to saturated site magenta with paper text.
- Cycle dots reworked: solid accent for active, neutral for arrived,
hairline ring for pending. No more magenta-on-gray noise.
- Tune chip sits in the cycling row with a count pill badge; open state
uses accentSoft bg + accent text (no ad-hoc white border).
- Popover uses the bar's palette with a deeper surface (surfaceDeep),
lives behind the bar via z-index so a 6px overlap reads as tucked under
it, and animates with clip-path inset() for reliable slide behavior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.3 KiB
tagline
| tagline |
|---|
| Think before you build. Produce a design brief through discovery, not guesswork. |
/impeccable, /impeccable craft, or any implementation flow.A shape brief is a compass, not a spec. It captures intent, not UI. Implementation skills read it before writing a line of code.
When to use it
/impeccable shape is where a feature starts. Before anyone writes code, before anyone argues about the hero treatment, before anyone picks a font. Use it to force a discovery conversation about purpose, users, content, and constraints, then capture the answers as a design brief the implementation skills can lean on.
Reach for it whenever a feature is about to start, a ticket is vague, or you catch yourself writing JSX to figure out what the product should be.
How it works
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. The model jumps to "here is a card grid" without asking "what is the user trying to accomplish". /impeccable shape inverts that order.
The skill runs a structured discovery interview in conversation. It will not write code during this phase. The questions cover:
- Purpose and context: what the feature is for, who uses it, what state of mind they are in
- Content and data: what is displayed, realistic ranges, edge cases, what is dynamic
- Design goals: the single most important thing, the intended feeling, reference examples
- Constraints: technical, content, accessibility, localization
You answer naturally. The skill asks follow-ups, not a form. At the end it produces a design brief: a structured artifact you can hand to /impeccable or any other implementation skill.
Note: if you want the full flow (discovery interview, then straight into building), use /impeccable craft instead. It runs /impeccable shape internally, then continues into implementation with visual iteration. /impeccable shape standalone is for when you want just the brief, so you can take it to whatever implementation approach you prefer.
Try it
/impeccable shape a daily digest email preferences page
Expect a 5 to 10 question conversation. The skill asks things like "who is the person opening this, and are they already committed or still curious" and "what happens when the user has unsubscribed from everything, do we hide the feature or show something". You answer, and a brief materializes.
From there you can hand the brief to /impeccable, /impeccable polish, or any other skill. Or just use it as a reference while you build by hand.
Pitfalls
- Skipping it because it feels slow. The interview is maybe 5 minutes. The rewrites you avoid are measured in hours.
- Treating the brief as a spec. It is a compass, not a checklist. It captures intent, not UI.
- Answering with "standard" or "normal". Specificity is the whole point. If a user is "rushed, on mobile, between meetings", say so. That changes everything downstream.