Paul BakausandClaude Opus 4.6
b0f44f83c6
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>
3.7 KiB
Craft Flow
Build a feature with impeccable UX and UI quality through a structured process: shape the design, load the right references, then build and iterate visually until the result is delightful.
Step 1: Shape the Design
Run {{command_prefix}}impeccable shape, passing along whatever feature description the user provided.
Wait for the design brief to be fully confirmed before proceeding. The brief is your blueprint, and every implementation decision should trace back to it.
If the user has already run {{command_prefix}}impeccable shape and has a confirmed design brief, skip this step and use the existing brief.
Step 2: Load References
Based on the design brief's "Recommended References" section, consult the relevant impeccable reference files. At minimum, always consult:
- spatial-design.md for layout and spacing
- typography.md for type hierarchy
Then add references based on the brief's needs:
- Complex interactions or forms? Consult interaction-design.md
- Animation or transitions? Consult motion-design.md
- Color-heavy or themed? Consult color-and-contrast.md
- Responsive requirements? Consult responsive-design.md
- Heavy on copy, labels, or errors? Consult ux-writing.md
Step 3: Build
Implement the feature following the design brief. Work in this order:
- Structure first: HTML/semantic structure for the primary state. No styling yet.
- Layout and spacing: Establish the spatial rhythm and visual hierarchy.
- Typography and color: Apply the type scale and color system.
- Interactive states: Hover, focus, active, disabled.
- Edge case states: Empty, loading, error, overflow, first-run.
- Motion: Purposeful transitions and animations (if appropriate).
- Responsive: Adapt for different viewports. Don't just shrink; redesign for the context.
During Build
- Test with real (or realistic) data at every step, not placeholder text
- Check each state as you build it, not all at the end
- If you discover a design question, stop and ask rather than guessing
- Every visual choice should trace back to something in the design brief
Step 4: Visual Iteration
This step is critical. Do not stop after the first implementation pass.
Open the result in a browser window. If browser automation tools are available, use them to navigate to the page and visually inspect the result. If not, ask the user to open it and provide feedback.
Iterate through these checks visually:
- Does it match the brief? Compare the live result against every section of the design brief. Fix discrepancies.
- Does it pass the AI slop test? If someone saw this and said "AI made this," would they believe it immediately? If yes, it needs more design intention.
- Check against impeccable's DON'T guidelines. Fix any anti-pattern violations.
- Check every state. Navigate through empty, error, loading, and edge case states. Each one should feel intentional, not like an afterthought.
- Check responsive. Resize the viewport. Does it adapt well or just shrink?
- Check the details. Spacing consistency, type hierarchy clarity, color contrast, interactive feedback, motion timing.
After each round of fixes, visually verify again. Repeat until you would be proud to show this to the user. The bar is not "it works"; the bar is "this delights."
Step 5: Present
Present the result to the user:
- Show the feature in its primary state
- Walk through the key states (empty, error, responsive)
- Explain design decisions that connect back to the design brief
- Ask: "What's working? What isn't?"
Iterate based on feedback. Good design is rarely right on the first pass.