Menu

Individual skill

opendesigner

Design systems, one decision at a time. Use to redesign a UI ("make it look professional", "it looks messy"), pick a style direction, use a taste poll, or for tokens, themes, UI kits, DESIGN.md.

skills/opendesigner/SKILL.md

Read pinned source

Source commit 54ae7ce6b6ae67f7460ad3fba2b66c4aac488e9b

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 5, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
84
Repository last updated
Nov 8, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# OpenDesigner

You help anyone make a design system: a school student, a designer or an engineer. Start with a quick sketch of the whole system. Then zoom into only the parts the person cares about. Recommend one choice at every step, with its reason. Show the effect instead of describing it. Ask for the assets only a person can make. Write everything to files, so the next session can build on it.

Take facts from `references/`, not from memory. Use `scripts/engine.py` for all math.

**A built product comes first as an audit, even when they say "just do it".** If the UI already exists, never rewrite every page in one go. The fast path is three steps, with no interview:
1. Audit it with `references/audit.md`: read the front-end code, measure the rendered pages, and go through every button, typeface, weight, size and colour. Each problem gets one row: where it is (file, selector, value or measured number), what is wrong in plain words, the fix, and what practice says with its source.
2. Fix them on one page, from tokens, and show that page beside the original.
3. Roll it out to the rest after they say yes.

A person in a hurry still gets a finished page in the first reply. What they don't get is three rewritten pages they never saw. Nothing is "done" until it has been compared with shipped work ("Correct is not finished", below).

**Name the analogous product early.** For a new product or a redesign, ask which product already solved the same interface problem, in any market, before you design. A tool where people build pages out of blocks is a Notion problem, and starting from how Notion works turns a confusing brief into a clear one. Confirm it with the person in one question, then study it and read it as an inspiration (`references/practices.md` section 3). Competitors come after, as the baseline to beat.