docs(impeccable): three new derivative-template DON'T rules (hedged type stacks, flat tech-blue, default pill chip)

[Littlejoey38]

Summary

Adds three net-new DON'T rules to source/skills/impeccable/SKILL.md, inserted into the existing typography, color, and visual-details rule blocks. Each rule targets a 2020s derivative-template tell the skill does not currently catch.

• +1 line in <typography_rules> — closes a reflex-pairing loophole in font_selection_procedure. Each role in a type stack (display, body, any third) must independently clear reflex_fonts_to_reject and Steps 1–4; a pair where only one role survived the procedure is still monoculture, just displaced into the other role.
• +1 line in <color_rules> — bans the saturated tech-product-blue accent band (hue ~215–225, high chroma, lightness ~50%). Complements the existing AI-color-palette rule (which catches gradient/neon combos, not flat default blue).
• +1 line in the Visual Details DON'T bullets — bans the default rounded-full pill chip (faint tinted background, faint hairline border, ~11–12px label) when used for "Beta"/"New" tags or section labels. No existing rule covers badge/chip shape.

Diff: 1 file, 3 insertions, 0 deletions on the original commit, with the typography rule rewritten in a follow-up amendment to anchor it to font_selection_procedure / reflex_fonts_to_reject (see below).

Why this is scoped the way it is

• Only source/skills/impeccable/SKILL.md is touched. source/ is the editable source per DEVELOP.md; the .agents/, .claude/, .codex/, .cursor/, .gemini/, .kiro/, .opencode/, .pi/, .rovodev/, .trae*/ mirrors are build artifacts — not hand-edited here.
• Time- and product-agnostic wording. The final DON'T lines name no specific product, year, or brand so they age with the skill instead of out of it. The rationale text uses generic category references ("dev-tool dashboards", "dev-tool landing page") rather than product names.
• No reference files, no detector code. Intentionally keeping PR 1 minimal. If a reference file or detector follow-up is useful, it can land as a scoped follow-up PR.

Evidence

Each rule was surfaced by at least one documented design-review dogfood where the absence of the rule let the tell ship or nearly ship:

• Reflex pairing: a direction doc specified two display families as interchangeable for headings. Each family in isolation might have cleared reflex_fonts_to_reject, but running font_selection_procedure on each role independently would have surfaced that neither was selected from a brief — both were reflex grabs. The existing "overused fonts" rule only catches individual families, not the reflex-pairing shape, so a designer who committed to a single reflex font in each of two roles would still pass it.
• Flat tech-product blue: a design-system palette that used #0066FF as the primary accent passed the AI-color-palette rule (no gradient, no neon) but read as a generic dev-tool landing page. The existing rule targets glow/gradient combos, not the flat-high-chroma-blue default.
• Default pill chip: multiple section-label and "Beta"/"New" treatments across unrelated pages reached for the faint-tinted-pill-with-hairline-border at 11–12px. No existing rule addressed badge shape, so the pill shipped by default on every project until flagged by hand.

Scope: two tells held local, not proposed upstream

Two additional derivative-template tells from our internal checklist are intentionally not in this PR:

• Three-bucket mono discipline (separate real metadata, mono-as-vibe decoration, and mono inside a mark / SVG logotype). Held local because the rule is anchored to a specific company wordmark-SVG regression where mono strings that looked structural were stale pseudo-data. The symptom generalizes, but the "three buckets" framing only earns its keep with that dogfood evidence; proposing it upstream without that context would read as prescriptive.
• Specimen-grid carve-out (a narrow exception when an equal-weight three-column grid is genuinely a type-specimen or swatch grid where hierarchy would be misleading). Held local because the carve-out is useful internally but risks reading as an escape hatch in a broader audience.

If either generalizes with more external evidence, we'll scope a dedicated follow-up PR. Not this one.

Test plan

• Edit is isolated to source/skills/impeccable/SKILL.md.
• git diff --stat against upstream/main shows 1 file, 3 insertions.
• No mirror directory (.agents/, .claude/, .codex/, .cursor/, .gemini/, .kiro/, .opencode/, .pi/, .rovodev/, .trae*/) is touched; they regenerate via bun run build.
• Each new DON'T line matches the cadence and tag structure of the rules immediately surrounding it (DO NOT … inside <typography_rules> and <color_rules>, DO NOT: … inside Visual Details bullets).
• Final DON'T lines contain no product or company names.
• Typography rule anchors explicitly to the existing font_selection_procedure / reflex_fonts_to_reject blocks so it still reads correctly in a 2027+ context.
• Maintainer review: does the chip rule belong in Visual Details or in a new badges/labels section? Open to moving if you prefer.
• Maintainer review: is the parenthetical hue range (~215–225, high chroma, ~50% L) concrete enough, or would you prefer an OKLCH-specific phrasing given the skill's existing OKLCH guidance?

Follow-ups

If this lands cleanly, there is one candidate for a scoped second PR: a reference/template-tells-2025.md with rationale and rewrite patterns for each of the three tells in this PR. Holding it back to keep review surface minimal. The two tells named in the Scope section above are not candidates for a follow-up PR — they stay local unless new external evidence generalizes them.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f8303b779c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Regenerate provider dist outputs after source skill edit

This commit changes source/skills/impeccable/SKILL.md but leaves all generated provider artifacts untouched, so the new rules never reach users who install from committed dist/ bundles (dist/cursor, dist/claude-code, dist/gemini, dist/codex). In this repo, source edits are expected to be followed by bun run build and committing the regenerated outputs; otherwise source and distribution drift, and published downloads/API bundle content remain stale.

Useful? React with 👍 / 👎.