Files
pbakaus_impeccable/skill/reference/colorize.md
T
e587004ee4 Refactor: cleaner top-level directory structure (#138)
* refactor(content): merge content/site/ into site/content/

Phase 1 step 1 of the directory restructure. The dual content tree was
called out in CLAUDE.md as cleanup; both trees were already in sync
except for anti-patterns-catalog.js, which moves to site/data/.

- Delete content/site/skills/ and content/site/tutorials/ (duplicates of
  site/content/, which is what Astro's content collection actually reads).
- Move content/site/anti-patterns-catalog.js -> site/data/.
- Update scripts/lib/sub-pages-data.js and scripts/build.js to read from
  site/content/ and site/data/.
- Drop content/site/ from validateProse target list (site/content was
  already there).
- Rewrite the "Two content trees" section in CLAUDE.md as a single-tree
  pointer; update stale dev-server text mentioning the deleted
  server/index.js.

Tests: 186/186 pass. Skills build: clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(skill): rename source/skills/impeccable/ -> skill/

Phase 1 step 2 of the directory restructure. The path was redundantly
nested ("source/" wrapper plus "skills/impeccable/" — singular content
hidden behind the plural). Collapses to flat skill/SKILL.md +
skill/reference/ + skill/scripts/.

- Move source/skills/impeccable/ -> skill/.
- Rewrite scripts/lib/utils.js readSourceFiles(): drop the multi-skill
  iteration (CLAUDE.md commits to a single user-invocable skill); read
  skill/SKILL.md directly.
- Update scripts/build.js, scripts/generate-og-image.js, and the
  sub-pages data layer to point at skill/.
- Update tests/lib/utils.test.js: drop the "multi-skill" and "dir-name
  fallback" cases, update single-skill paths to skill/.
- Update tests/build.test.js similarly: drop "multiple skills"
  integration test, update paths.
- Update non-glob path joins in tests/framework-fixtures.test.mjs,
  tests/live-e2e/session.mjs, tests/live-e2e/agents/llm-agent.mjs,
  tools/live-loop.mjs.
- Update prose/text references in CLAUDE.md, AGENTS.md, DEVELOP.md,
  README.md, scripts/lib/sub-pages-data.js, bin/commands/skills.mjs,
  site/data/anti-patterns-catalog.js, site/pages/docs/[...slug].astro,
  docs/adr-live-variant-mode.md, docs/plans/.

Eval framework note: the separate impeccable-evals repo reads
../impeccable/source/skills/impeccable/ and needs a coordinated
rename to ../impeccable/skill/.

Tests: 186/186 pass. Skills build: clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor: rename docs/ -> notes/

Phase 1 step 3 of the directory restructure. The internal docs/ dir
(ADRs and plans) clashed with the site's /docs route. Renaming it
"notes/" makes the difference unambiguous: notes/ is project-internal
process, /docs is the user-facing route under site/pages/docs/.

No code references the dir; the rename is a clean git mv.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(site): move public/ under site/public/

Phase 2 step 4 of the directory restructure. Public assets and the
Astro publicDir now live alongside the rest of the site, so site/
is fully self-contained for static content.

- git mv public site/public.
- astro.config.mjs: add publicDir: './site/public'. Astro defaults to
  ./public at the project root, so the override is required.
- scripts/build.js: write generated _data, _headers, _redirects,
  _routes.json, and js/detect-antipatterns-browser.js into
  site/public/. Also delete the dead _REMOVED() Bun static-site
  builder (replaced by Astro at #130; the placeholder no longer earns
  its keep).
- scripts/build.js validateProse: replace the stale public/index.html
  reference (deleted at the Astro migration) with site/pages/index.astro
  in the count-validation file list, restoring homepage drift detection.
- scripts/generate-og-image.js: write OG image into site/public/.
- scripts/screenshot-antipatterns.js: read examples from + write
  screenshots to site/public/antipattern-{examples,images}/.
- scripts/lib/sub-pages-data.js: load command demos from
  site/public/js/demos/commands.
- .gitignore: rename the public/* generator-output entries to
  site/public/*.
- CLAUDE.md: refresh CSS/data-file paths (still pointing at the old
  pre-Astro public/css/ + public/js/ tree), point the changelog and
  command-add checklists at site/pages/index.astro and
  site/scripts/data.js + site/scripts/components/framework-viz.js.

Cloudflare Pages note: functions/ stays at the repo root because
CF Pages auto-discovers it there with no configuration knob to
relocate. Moving it under site/ would either break deployment or
require a build-time copy step that adds more complexity than the
cleanup is worth.

Tests: 186/186 pass. Skills + site build clean. _headers,
_redirects, _routes.json, _data/ all land in build/ correctly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(cli): consolidate bin/ + src/ + lib/ under cli/

Phase 2 step 5 of the directory restructure. The CLI surface was split
across three top-level dirs whose names were easy to mistake for each
other (especially src/ vs source/ pre-step-2). Consolidates under cli/.

- git mv bin -> cli/bin (CLI entry + skills sub-command)
- git mv src -> cli/engine (detect-antipatterns engine + browser variant)
- git mv lib -> cli/lib (download-providers helper)

Update package.json:
- bin.impeccable: cli/bin/cli.js
- main + exports: cli/engine/detect-antipatterns.mjs and the
  ./browser variant
- files: ["cli/", "LICENSE"]

Update internal references:
- cli/bin/cli.js: dynamic import points at ../engine/, package.json
  read goes one level deeper (../../package.json).
- functions/api/download/[type]/[provider]/[id].js + bundle/[provider].js:
  cli/lib/download-providers.js path.
- scripts/build.js, scripts/build-browser-detector.js,
  scripts/build-extension.js: cli/engine path constants.
- scripts/lib/sub-pages-data.js, scripts/lib/utils.js, skill/scripts/
  live-server.mjs: comment refs.
- tests/detect-antipatterns{,-browser,-fixtures}.test.{js,mjs},
  tests/windows-path-fix.test.js: import + read paths.
- AGENTS.md, CLAUDE.md: doc paths.

Verified:
- npx node cli/bin/cli.js --version, --help, detect --help all work.
- bun run build, bun run build:browser, bun run build:extension all
  clean. Browser detector lands at cli/engine/detect-antipatterns-browser.js;
  extension/detector/detect.js still emits to the same location.
- bun run test: 186/186 pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: update browser-detector paths missed in cli/ rename

Bugbot caught two runtime path leaks where the comment got renamed
to cli/engine/ but the actual code still used the old src/ segment.

- skill/scripts/live-server.mjs: detectPaths array now joins cli, engine,
  detect-antipatterns-browser.js for both the repo-relative lookup
  (4 dirs up from .claude/skills/impeccable/scripts/ to repo root) and
  the npm node_modules fallback. Without this fix, the detection
  overlay would silently not load during live-server sessions.

- scripts/build.js: the post-build copy of the browser detector into
  site/public/js/ was reading from src/. The if (fs.existsSync(...))
  guard meant the copy was silently skipping, so antipattern-examples
  pages would 404 on /js/detect-antipatterns-browser.js once the site
  was deployed.

Tests: 186/186 pass. Build clean. site/public/js/detect-antipatterns-browser.js
re-emits as expected.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: cleanup-deprecated import path missed an extra .. in cli/ rename

Bugbot caught three call sites in cli/bin/commands/skills.mjs that
import '../../skill/scripts/cleanup-deprecated.mjs'. Pre-rename, that
was correct from bin/commands/ (one parent to bin/, one to repo root).
After moving the file from bin/commands/ to cli/bin/commands/, the
path is one directory deeper, so it needs three .. segments to reach
the repo root. Without the fix, every cleanup invocation throws on
import and gets swallowed by the surrounding try/catch — silent skip.

cli/bin/cli.js's package.json read already uses '../../package.json'
(the same depth pattern), confirming three levels is correct.

Verified: dynamic import resolves and exports the expected functions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: sweep stale path/file references missed in the restructure

Same root cause as the two bugbot finds: some references in moved or
related files weren't tracked because they didn't match a simple
sed pattern. Caught the rest by walking each moved dir's depth and
each Astro-migration deletion.

Stale path references (post-Astro migration, missed earlier):
- CLAUDE.md: legacy URL redirects "live in server/index.js" -> point
  at the actual sources (scripts/build.js generateCFConfig +
  site/public/_redirects).
- AGENTS.md: counts.js path (public/ -> site/public/), changelog file
  (public/index.html -> site/pages/index.astro), screenshots note
  (public/ -> site/), source-of-truth dirs (source/, src/ -> skill/,
  cli/).
- tests/detect-antipatterns-browser.test.mjs: comment about routes
  "in server/index.js".
- skill/reference/live.md: workflow.css example for "this repo" was
  pre-Astro (public/css/) -> site/styles/. (User-project Vite/Next
  example unchanged.)

Stale path that pointed at moved files:
- tests/skills-cli.test.js: CLI path was '..', 'bin', 'cli.js'; now
  '..', 'cli', 'bin', 'cli.js'. Test isn't wired into bun run test
  but it would have failed if invoked.

Dead files (orphaned by Astro migration, never cleaned up):
- tests/server/download-validation.test.js: imported from
  ../../server/lib/{validation,api-handlers}.js which were deleted in
  b8f09c8. Test was a silent failure waiting to happen.
- scripts/lib/render-markdown.js: 156-line module with zero consumers
  (the only caller, scripts/lib/render-page.js, was deleted in the
  Astro cleanup).
- scripts/build.js: dead commented-out generateSubPages import.

Tests: 186/186 pass. Build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(build): remove invalid Corepack packageManager spec

Cloudflare Pages rejects the build with `Unsupported package manager
specification (bun@1.3.11)`. The packageManager field follows
Corepack's syntax which only validates npm/pnpm/yarn — `bun@X.Y.Z`
parses as a malformed Corepack directive even though Bun itself
treats it as a hint.

Pre-existing on main since d874af0 (CF Pages deploy on main also
failing); just surfaces here because the PR triggers a fresh deploy.

CF Pages auto-detects Bun anyway (the build log confirms:
"Detected the following tools from environment: bun@1.3.11,
pnpm@10.11.1, nodejs@22.16.0"). Removing the field unblocks the
deploy without changing local dev behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Paul Bakaus <paulbakaus@pauls-mbp-3.lan>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-04 16:38:03 -07:00

7.8 KiB

Additional context needed: existing brand colors.

Replace timid grayscale or single-accent designs with a strategic palette: pick a color strategy, choose a hue family that fits the brand, then apply color with intent. More color ≠ better. Strategic color beats rainbow vomit.


Register

Brand: palette IS voice. Pick a color strategy first per SKILL.md (Restrained / Committed / Full palette / Drenched) and follow its dosage. Committed, Full palette, and Drenched deliberately exceed the ≤10% rule; that rule is Restrained only. Unexpected combinations are allowed; a dominant color can own the page when the chosen strategy calls for it.

Product: semantic-first and almost always Restrained. Accent color is reserved for primary action, current selection, and state indicators. Not decoration. Every color has a consistent meaning across every screen.


Assess Color Opportunity

Analyze the current state and identify opportunities:

  1. Understand current state:

    • Color absence: Pure grayscale? Limited neutrals? One timid accent?
    • Missed opportunities: Where could color add meaning, hierarchy, or delight?
    • Context: What's appropriate for this domain and audience?
    • Brand: Are there existing brand colors we should use?
  2. Identify where color adds value:

    • Semantic meaning: Success (green), error (red), warning (yellow/orange), info (blue)
    • Hierarchy: Drawing attention to important elements
    • Categorization: Different sections, types, or states
    • Emotional tone: Warmth, energy, trust, creativity
    • Wayfinding: Helping users navigate and understand structure
    • Delight: Moments of visual interest and personality

If any of these are unclear from the codebase, {{ask_instruction}}

CRITICAL: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.

Plan Color Strategy

Create a purposeful color introduction plan:

  • Color palette: What colors match the brand/context? (Choose 2-4 colors max beyond neutrals)
  • Dominant color: Which color owns 60% of colored elements?
  • Accent colors: Which colors provide contrast and highlights? (30% and 10%)
  • Application strategy: Where does each color appear and why?

IMPORTANT: Color should enhance hierarchy and meaning, not create chaos. Less is more when it matters more.

Introduce Color Strategically

Add color systematically across these dimensions:

Semantic Color

  • State indicators:

    • Success: Green tones (emerald, forest, mint)
    • Error: Red/pink tones (rose, crimson, coral)
    • Warning: Orange/amber tones
    • Info: Blue tones (sky, ocean, indigo)
    • Neutral: Gray/slate for inactive states
  • Status badges: Colored backgrounds or borders for states (active, pending, completed, etc.)

  • Progress indicators: Colored bars, rings, or charts showing completion or health

Accent Color Application

  • Primary actions: Color the most important buttons/CTAs
  • Links: Add color to clickable text (maintain accessibility)
  • Icons: Colorize key icons for recognition and personality
  • Headers/titles: Add color to section headers or key labels
  • Hover states: Introduce color on interaction

Background & Surfaces

  • Tinted backgrounds: Replace pure gray (#f5f5f5) with warm neutrals (oklch(97% 0.01 60)) or cool tints (oklch(97% 0.01 250))
  • Colored sections: Use subtle background colors to separate areas
  • Gradient backgrounds: Add depth with subtle, intentional gradients (not generic purple-blue)
  • Cards & surfaces: Tint cards or surfaces slightly for warmth

Use OKLCH for color: It's perceptually uniform, meaning equal steps in lightness look equal. Great for generating harmonious scales.

Data Visualization

  • Charts & graphs: Use color to encode categories or values
  • Heatmaps: Color intensity shows density or importance
  • Comparison: Color coding for different datasets or timeframes

Borders & Accents

  • Hairline borders: 1px colored borders on full perimeter (not side-stripes; see the absolute ban on border-left/right > 1px)
  • Underlines: Color underlines for emphasis or active states
  • Dividers: Subtle colored dividers instead of gray lines
  • Focus rings: Colored focus indicators matching brand
  • Surface tints: A 4-8% background wash of the accent color instead of a stripe

NEVER: border-left or border-right greater than 1px as a colored accent stripe. This is one of the three absolute bans in the parent skill. If you want to mark a card as "active" or "warning", use a full hairline border, a background tint, a leading glyph, or a numbered prefix. Not a side stripe.

Typography Color

  • Colored headings: Use brand colors for section headings (maintain contrast)
  • Highlight text: Color for emphasis or categories
  • Labels & tags: Small colored labels for metadata or categories

Decorative Elements

  • Illustrations: Add colored illustrations or icons
  • Shapes: Geometric shapes in brand colors as background elements
  • Gradients: Colorful gradient overlays or mesh backgrounds
  • Blobs/organic shapes: Soft colored shapes for visual interest

Balance & Refinement

Ensure color addition improves rather than overwhelms:

Maintain Hierarchy

  • Dominant color (60%): Primary brand color or most used accent
  • Secondary color (30%): Supporting color for variety
  • Accent color (10%): High contrast for key moments
  • Neutrals (remaining): Gray/black/white for structure

Accessibility

  • Contrast ratios: Ensure WCAG compliance (4.5:1 for text, 3:1 for UI components)
  • Don't rely on color alone: Use icons, labels, or patterns alongside color
  • Test for color blindness: Verify red/green combinations work for all users

Cohesion

  • Consistent palette: Use colors from defined palette, not arbitrary choices
  • Systematic application: Same color meanings throughout (green always = success)
  • Temperature consistency: Warm palette stays warm, cool stays cool

NEVER:

  • Use every color in the rainbow (choose 2-4 colors beyond neutrals)
  • Apply color randomly without semantic meaning
  • Put gray text on colored backgrounds. It looks washed out; use a darker shade of the background color or transparency instead
  • Use pure gray for neutrals. Add subtle color tint (warm or cool) for depth
  • Use pure black (#000) or pure white (#fff) for large areas
  • Violate WCAG contrast requirements
  • Use color as the only indicator (accessibility issue)
  • Make everything colorful (defeats the purpose)
  • Default to purple-blue gradients (AI slop aesthetic)

Verify Color Addition

Test that colorization improves the experience:

  • Better hierarchy: Does color guide attention appropriately?
  • Clearer meaning: Does color help users understand states/categories?
  • More engaging: Does the interface feel warmer and more inviting?
  • Still accessible: Do all color combinations meet WCAG standards?
  • Not overwhelming: Is color balanced and purposeful?

When the palette earns its place, hand off to {{command_prefix}}impeccable polish for the final pass.

Live-mode signature params

When invoked from live mode, each variant MUST declare a color-amount param so the user can dial between a restrained accent and a drenched surface without regeneration. Author the variant's CSS against var(--p-color-amount, 0.5), typically as the alpha multiplier on backgrounds, or as a scaling factor on the chroma axis in an OKLCH expression. 0 = neutral/monochrome, 1 = full saturation / dominant coverage.

{"id":"color-amount","kind":"range","min":0,"max":1,"step":0.05,"default":0.5,"label":"Color amount"}

Layer 1-2 variant-specific params on top: palette selection (steps with named options), temperature warmth, or tint vs. true color. See reference/live.md for the full params contract.