Biggest change in a while. Users previously had 18 standalone skill
entries cluttering their /menu; now they have one entry (/impeccable)
that routes to 20 specialized commands via argument dispatch. The pin
mechanism (/impeccable pin audit) restores standalone shortcuts on
demand for commands users hit all the time.
## Architecture
- Single /impeccable skill with command router section in SKILL.md
- 20 commands served via reference files under source/skills/impeccable/reference/
- /impeccable pin <command> creates a lightweight redirect shim so users
who prefer /audit, /polish, etc. can still have them
- Context gathering (teach) auto-runs on first use
- command-metadata.json is the single source of truth for command
descriptions, argument hints, and relationships
## Site rewrite
- Docs URL: /skills renamed to /docs (with /skills permanent redirects)
- Homepage hero frames Impeccable as "one skill with 20 commands"
- "Get Started" split into 50/50 install + how-to-use with editorial
numbered steps, /impeccable shown as the home command with three modes
- New /docs overview: home command hero card + dense category rows
matching the old cheatsheet density, with leads-to/pairs-with/
combines-with relationship metadata served from a shared source
- Cheatsheet merged into /docs, /cheatsheet redirects
- Magazine spread and mobile cards show /impeccable as a stacked
namespace label above the command name at full display size
- Periodic table updated with craft/teach/extract as first-class cells
- Skill detail pages generate from reference files, with an editorial
wrapper per command for tagline + body
- Tutorials and anti-patterns pages updated to use /impeccable <cmd>
## Build system
- Dead code removed (scripts/lib/transformers/shared.js)
- Build log wording fixed ("1 skill" not "1 skills (1 user-invocable)")
- generateApiData fallback branch removed (throws loudly if metadata
missing instead of silently degrading)
- Commands API includes editorial tagline alongside the long description;
UI surfaces prefer tagline for human display, description for auto-
trigger keyword matching
## Gitignore
- Added .claude/scheduled_tasks.lock, .claude/settings.local.json to
ignore list (local Claude Code state that should not be tracked).
- Harness skill directories (.claude/skills/, .agents/skills/, etc.)
remain tracked by design: npx skills reads them from this repo at
install time and they enable clean submodule use.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.7 KiB
tagline
| tagline |
|---|
| Think before you build. Produce a design brief through discovery, not guesswork. |
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.