impeccable-design
Paperboard's design authority skill. It does not run a CLI — it loads doctrine
into the agent's context so that every authored or modified .DESIGN.md file
respects the same anti-slop rules. Methodology is imported from
pbakaus/impeccable; aesthetic tokens
remain paperboard's own.
When to invoke
- The user asks you to create, edit, or audit a
.DESIGN.md file
(a design tier, a starter, or the default paperboard.DESIGN.md).
- The user asks for a new design tier, a new starter pack entry, or a redesign
of an existing tier.
- You are reviewing a PR that touches anything under
core/designs/.
- A
.DESIGN.md lint fails and you need to reason about why a token or rule is
banned.
Do not invoke for plain HTML/CSS work that does not touch a .DESIGN.md
contract, or for documentation prose unrelated to design tokens.
Doctrine sources
Read these files, in order, before authoring or modifying a .DESIGN.md:
core/designs/DESIGN-AUTHORITY.md — the binding rules. The single source
of truth for what is allowed in any paperboard .DESIGN.md.core/designs/impeccable-context/typography.md — type scale, weights,
tracking, mono-vs-serif decisions.core/designs/impeccable-context/color-and-contrast.md — palette
discipline, accent budget, tinted neutrals, contrast floor.core/designs/impeccable-context/spatial-design.md — spacing scale,
border discipline, depth from negative space (not shadows).core/designs/impeccable-context/motion-design.md — easing curves
(cubic-bezier(0.16, 1, 0.3, 1) only; no bounce), durations,
prefers-reduced-motion.core/designs/impeccable-context/interaction-design.md — affordance,
state, focus, hit-target rules.core/designs/impeccable-context/responsive-design.md — breakpoint
philosophy, fluid type, container query intent.core/designs/impeccable-context/ux-writing.md — voice, hedging bans,
expert-decisive tone.
Provenance: vendored verbatim under Apache 2.0 from pbakaus/impeccable at
commit 4af581e23f17d112d8f9d6b7a5b7ff37823494e1. See
core/designs/impeccable-context/UPSTREAM.md and NOTICE.md.
Absolute bans (non-negotiable)
These are restated from DESIGN-AUTHORITY.md so the skill is self-contained.
Every .DESIGN.md Don't list must enforce all of them:
- Glassmorphism — no
backdrop-filter: blur, no frosted-translucent
surfaces, no glow-on-blur cards.
- Gradient text — no
-webkit-background-clip: text with a gradient fill.
- Side-stripe borders — no
border-left / border-right greater than 1px
used as a colored stripe on cards, list items, callouts, or alerts.
- Nested card-in-card — no card containers visually nested inside other
cards. Flatten the hierarchy; depth comes from negative space.
- Generic AI emoji decoration — no ✨ 🚀 ⚡ 🎯 🔥 💎 or comparable cliché
glyphs used decoratively. Status dots, mono
·, and typographic emphasis
are the only allowed ornaments.
- Identical-card feature grids — no
repeat(auto-fit, minmax(280px, 1fr))
endlessly tiling same-shaped icon-heading-text cards.
- Hero-metric SaaS layouts — no big-number-with-tiny-label-and-gradient
template.
- Bounce / elastic easing — animations decelerate via expo-out only.
- Pure
#000 / #fff — always tinted neutrals (paperboard ships
#08090A / #F7F8F8).
- Hedging prose — "maybe consider," "could be helpful," "might want to" are
banned. Design rules are decisive.
If a request asks for any of the above, refuse and explain which ban applies.
How to use this when authoring or modifying a .DESIGN.md file
- Read
core/designs/DESIGN-AUTHORITY.md in full before writing any token
or rule. Then read the relevant impeccable-context file for the dimension
you are touching (typography, color, spatial, motion, etc.).
- Audit the existing file (if any) against the bans above. List every
violation found. Do not silently fix — list, then fix.
- Write or edit tokens in paperboard's voice: cold, dark, technical,
expert-decisive. No hedging. Every Don't is a hard, enforceable ban.
- Add or update the audit comment at the very top of the file, in HTML
comment form:
<!-- YYYY-MM-DD: audited against impeccable doctrine; <N> violations corrected: <list> -->
or <!-- YYYY-MM-DD: audited against impeccable doctrine; no violations found -->.
- Verify by running
pytest -q and (when Node.js is available)
npm run lint:artifacts. Neither must regress.
Methodology vs. aesthetic — the load-bearing distinction
Paperboard adopts impeccable's methodology (how design rules are authored
and enforced), not its aesthetic (the warm Cormorant Garamond editorial
palette). Impeccable's own tokens — Cormorant Garamond, Warm Ash Cream,
Editorial Magenta — are not adopted by any paperboard tier.
Paperboard's canonical aesthetic remains cold, dark, technical:
#08090A near-black canvas; #F7F8F8 tinted off-white.- Geist Mono eyebrows in UPPERCASE with
0.12em tracking.
- Indigo / rose accents capped at ≤ 15% of visible surface area.
- 1px hairline borders; depth via tonal layering, not drop shadows.
- Numbered sections (
00, 01, 02) with tightened heading tracking
(-0.02em to -0.04em).
If you find yourself writing tokens that look "warm editorial," stop — you have
crossed from methodology into aesthetic import. Roll back.
1---2name: impeccable-design3description: Bind agent-authored `.DESIGN.md` files to paperboard's design doctrine. Loads the impeccable anti-slop methodology (vendored, Apache 2.0, pinned to commit `4af581e23f17d112d8f9d6b7a5b7ff37823494e1`) and the binding rules in `core/designs/DESIGN-AUTHORITY.md`. Read these BEFORE writing or editing any `.DESIGN.md` file.4---5
6# impeccable-design
7
8Paperboard's design authority skill. It does not run a CLI — it loads doctrine
9into the agent's context so that every authored or modified `.DESIGN.md` file
10respects the same anti-slop rules. Methodology is imported from
11[pbakaus/impeccable](https://github.com/pbakaus/impeccable); aesthetic tokens
12remain paperboard's own.
13
14## When to invoke
15
16- The user asks you to **create**, **edit**, or **audit** a `.DESIGN.md` file
17 (a design tier, a starter, or the default `paperboard.DESIGN.md`).
18- The user asks for a new design tier, a new starter pack entry, or a redesign
19 of an existing tier.
20- You are reviewing a PR that touches anything under `core/designs/`.
21- A `.DESIGN.md` lint fails and you need to reason about why a token or rule is
22 banned.
23
24Do **not** invoke for plain HTML/CSS work that does not touch a `.DESIGN.md`
25contract, or for documentation prose unrelated to design tokens.
26
27## Doctrine sources
28
29Read these files, in order, before authoring or modifying a `.DESIGN.md`:
30
311. **`core/designs/DESIGN-AUTHORITY.md`** — the binding rules. The single source
32 of truth for what is allowed in any paperboard `.DESIGN.md`.
332. **`core/designs/impeccable-context/typography.md`** — type scale, weights,
34 tracking, mono-vs-serif decisions.
353. **`core/designs/impeccable-context/color-and-contrast.md`** — palette
36 discipline, accent budget, tinted neutrals, contrast floor.
374. **`core/designs/impeccable-context/spatial-design.md`** — spacing scale,
38 border discipline, depth from negative space (not shadows).
395. **`core/designs/impeccable-context/motion-design.md`** — easing curves
40 (`cubic-bezier(0.16, 1, 0.3, 1)` only; no bounce), durations,
41 `prefers-reduced-motion`.
426. **`core/designs/impeccable-context/interaction-design.md`** — affordance,
43 state, focus, hit-target rules.
447. **`core/designs/impeccable-context/responsive-design.md`** — breakpoint
45 philosophy, fluid type, container query intent.
468. **`core/designs/impeccable-context/ux-writing.md`** — voice, hedging bans,
47 expert-decisive tone.
48
49Provenance: vendored verbatim under Apache 2.0 from `pbakaus/impeccable` at
50commit `4af581e23f17d112d8f9d6b7a5b7ff37823494e1`. See
51`core/designs/impeccable-context/UPSTREAM.md` and `NOTICE.md`.
52
53## Absolute bans (non-negotiable)
54
55These are restated from `DESIGN-AUTHORITY.md` so the skill is self-contained.
56Every `.DESIGN.md` Don't list must enforce all of them:
57
58- **Glassmorphism** — no `backdrop-filter: blur`, no frosted-translucent
59 surfaces, no glow-on-blur cards.
60- **Gradient text** — no `-webkit-background-clip: text` with a gradient fill.
61- **Side-stripe borders** — no `border-left` / `border-right` greater than 1px
62 used as a colored stripe on cards, list items, callouts, or alerts.
63- **Nested card-in-card** — no card containers visually nested inside other
64 cards. Flatten the hierarchy; depth comes from negative space.
65- **Generic AI emoji decoration** — no ✨ 🚀 ⚡ 🎯 🔥 💎 or comparable cliché
66 glyphs used decoratively. Status dots, mono `·`, and typographic emphasis
67 are the only allowed ornaments.
68- **Identical-card feature grids** — no `repeat(auto-fit, minmax(280px, 1fr))`
69 endlessly tiling same-shaped icon-heading-text cards.
70- **Hero-metric SaaS layouts** — no big-number-with-tiny-label-and-gradient
71 template.
72- **Bounce / elastic easing** — animations decelerate via expo-out only.
73- **Pure `#000` / `#fff`** — always tinted neutrals (paperboard ships
74 `#08090A` / `#F7F8F8`).
75- **Hedging prose** — "maybe consider," "could be helpful," "might want to" are
76 banned. Design rules are decisive.
77
78If a request asks for any of the above, refuse and explain which ban applies.
79
80## How to use this when authoring or modifying a `.DESIGN.md` file
81
821. **Read `core/designs/DESIGN-AUTHORITY.md` in full** before writing any token
83 or rule. Then read the relevant impeccable-context file for the dimension
84 you are touching (typography, color, spatial, motion, etc.).
852. **Audit the existing file (if any) against the bans** above. List every
86 violation found. Do not silently fix — list, then fix.
873. **Write or edit tokens** in paperboard's voice: cold, dark, technical,
88 expert-decisive. No hedging. Every Don't is a hard, enforceable ban.
894. **Add or update the audit comment** at the very top of the file, in HTML
90 comment form:
91 `<!-- YYYY-MM-DD: audited against impeccable doctrine; <N> violations corrected: <list> -->`
92 or `<!-- YYYY-MM-DD: audited against impeccable doctrine; no violations found -->`.
935. **Verify** by running `pytest -q` and (when Node.js is available)
94 `npm run lint:artifacts`. Neither must regress.
95
96## Methodology vs. aesthetic — the load-bearing distinction
97
98Paperboard adopts impeccable's **methodology** (how design rules are authored
99and enforced), **not** its **aesthetic** (the warm Cormorant Garamond editorial
100palette). Impeccable's own tokens — Cormorant Garamond, Warm Ash Cream,
101Editorial Magenta — are **not** adopted by any paperboard tier.
102
103Paperboard's canonical aesthetic remains cold, dark, technical:
104
105- `#08090A` near-black canvas; `#F7F8F8` tinted off-white.
106- Geist Mono eyebrows in UPPERCASE with `0.12em` tracking.
107- Indigo / rose accents capped at ≤ 15% of visible surface area.
108- 1px hairline borders; depth via tonal layering, not drop shadows.
109- Numbered sections (`00`, `01`, `02`) with tightened heading tracking
110 (`-0.02em` to `-0.04em`).
111
112If you find yourself writing tokens that look "warm editorial," stop — you have
113crossed from methodology into aesthetic import. Roll back.
aibot88