About Grist

Why this exists

Howdy! Grist is my side quest in the world of AI. Enjoy the growing collection of prompts, skills, rules and experiments for product design, from figuring out what it can really do.

Each drop comes with a short note on why I use it and a file you can paste straight into Claude, Cursor or a CLAUDE.md. A new one lands every Friday, eight to a season.

Tested means I've used it on real work. Trying means I'm still finding out. The ideas are mine, and Claude helps me format the files. Add .md to any address if you'd rather read plain markdown.

Rarities

Rarity is how deep a drop goes. Higher tiers take more setup and give you more.

  1. CommonOne idea you can use straight away, like a rule or a short prompt.
  2. UncommonNeeds a little setup. A prompt with blanks to fill, or a checklist with steps.
  3. RareGoes deeper. A full review checklist, a longer prompt or a simple skill.
  4. EpicA template you fill in, with a worked example. Usually a spec or a bigger skill.
  5. LegendaryA whole kit to install, with examples and a note on when not to use it.
  6. UltraSeveral skills and a reviewer agent chained into one workflow. It stops for your approval along the way, and comes with a sample run.

Design System Audit

ChecklistTested

tl;dr

The things a design system hasn't decided yet, written down before anyone builds on it.

When you document a design system or hand it to agents. You get an honest list of what's missing, each gap with an owner.

Why

When I documented a company website’s design system, the most useful page turned out to be the list of what wasn’t there yet. No design owner, no accessibility target, buttons drawn as static frames, spacing and radius not tokenised.

Writing it down stopped people, and agents, from treating the gaps as decisions. The team took the list under consideration, and it gave everyone the same picture of where the system stood.

It also made the build or adopt call easy. We adopted shadcn/ui, an open-source component library, instead of drawing every variant in Figma. It was the faster way forward, and the Figma side only had to match it.

How to use it

  1. Run it on the system as it is today, not as it's planned.
  2. Write every unchecked item into the docs as an open item, with an owner and a date.
  3. Link the open items from DESIGN.md or the README, so agents read them too.
Checklist

Design System Audit

Checks to review work against

## Design system audit

### Ownership

- [ ] A named design owner, and who approves changes
- [ ] A way to ask for a new component or token

### Accessibility

- [ ] A written target (for example WCAG 2.2 AA, the common web accessibility standard)
- [ ] Contrast checked for every text and background token pair
- [ ] Focus styles defined as tokens

### Tokens

- [ ] Colour, type, spacing and radius are all tokens; anything still hard-coded is listed
- [ ] Raw values (primitives) and named roles (semantic tokens) are separate, and components use only the named roles
- [ ] Every semantic token has a one-line description

### Components

- [ ] Components are real components with variants, not static frames
- [ ] Every component has its states (hover, focus, disabled, error, loading), or the missing ones are listed
- [ ] Build or adopt is decided for each component family, with the reason

### Docs

- [ ] Docs link to the source tokens and components instead of copying values
- [ ] Open items are listed where agents read them (DESIGN.md or README)
design-system-audit.md

What you get

Run on the design system of this site, mlynarz.com.

Design system audit: mlynarz.com

Ownership
[x] A named design owner, and who approves changes. Dawid owns and approves.
[ ] A way to ask for a new component or token. Not written down.

Accessibility
[ ] A written target. Not stated. Suggest WCAG 2.2 AA.
[ ] Contrast checked for every text and background token pair. Only the danger colour has a logged ratio.
[x] Focus styles defined as tokens. --color-focus.

Tokens
[x] Colour, type, spacing and radius are all tokens. Stylelint blocks raw values.
[x] Primitives and semantic tokens are separate, components use semantic only.
[ ] Every semantic token has a one-line description. Comments cover groups, not each token.

Components
[x] Real components with variants. Astro components, BEM modifiers.
[ ] Every component has its states. Buttons have no loading state.
[x] Build or adopt decided. Built, no framework.

Docs
[x] Docs link to the source. /styleguide renders the real components.
[x] Open items listed where agents read them. CLAUDE.md and DECISIONS.md.

Score: 9 of 14. Fix first: token descriptions, contrast pairs, an accessibility target.

See also

  • Spec

    DESIGN.md

    One plain file that explains how your design system works, for people and agents alike.

    • Tested

  • Prompt

    Token Description Lint

    Check your token names and descriptions the way a coding agent reads them.

    • Tested

  • Prompt

    Token Description Writer

    Write a one-line description for every token, by the job it does.

    • Tested

  • SpecPlugin included

    Design Token Pipeline

    Get Figma variables into code in one direction, through one standard token file.

    • Tested

I use analytics to measure and improve the website, only if you agree. Privacy policy