The method, written down so it runs the same way every time
Nine skills that carry a product engagement from a raw brief to a developer handoff. Each one is a procedure, a rubric and an output format, versioned like code rather than retyped. They encode twenty-three years and five design systems built from scratch, so the output is the same shape whoever runs it.
Years
23
Systems built
5
FIBER components
54
Edison products
40+
Edison, GE Healthcare
Red Dot
2020
A model will give you fourteen findings in nine seconds. Checking all fourteen costs more than writing five yourself. The bottleneck was never generation. It was trust.
Invented percentages, findings with no evidence, and a cheerful tone over all of it. The output reads finished, so the error is expensive to catch and embarrassing to pass to a client.
Every skill carries rules about what it must not do: never invent a number, never report a count you didn’t count, always name what you couldn’t determine. The refusals do more work than the procedures.
Same shape every time, with the gaps declared. The reader checks whether the recommendation is right, not which three numbers were fabricated.
One product, one question: “audit this checkout flow”. Left is an unguided ask. Right is heuristic-audit.
Fourteen findings, no severity, no evidence, no cost. Three statistics with no source. Nothing says which to fix first, and nothing admits what wasn’t tested.
Every line has to be verified.
Only the judgment needs checking.
Copy skills/ into a Claude project. Each subdirectory is one skill. Only the description line of each SKILL.md sits in context at rest. The procedure and its bundled files load only when a task matches, so the whole library costs almost nothing until one is needed.
skills/ ├── README.md ├── DEMO.md ├── PROJECT-INSTRUCTIONS.md ├── examples/ 7 finished artifacts ├── brief-intake/ │ ├── SKILL.md │ ├── templates/project-brief.md │ └── reference/question-bank.md ├── heuristic-audit/ ├── ds-inventory/ ├── research-synthesis/ ├── flow-map/ ├── copy-standards/ ├── a11y-spec/ ├── handoff-spec/ └── critique/
Every skill is the same six parts in the same order. Predictable structure is why a second designer can pick one up and get comparable output.
--- name: heuristic-audit description: Evaluate a live product against usability heuristics and WCAG 2.2, producing severity-rated findings with a cost... --- # Heuristic audit ## When to use ## Procedure ## Severity scale ## Rules ## Bundled files
Frontmatter
The only part in context at rest, roughly forty words per skill. Nine skills cost less to carry than one paragraph of a brief.
When to use
Named trigger conditions, so it fires on the right task and stays quiet on the wrong one.
Procedure
Numbered and ordered. The order is the opinion: inventory before diffing, structure before fidelity.
Rubric
The scale that makes two audits comparable. Without it, “major” means whatever the model felt that morning.
Rules
The refusals. The part revised most often, and the part that makes the output safe to show a client.
Bundled files
Templates and reference tables loaded on demand, versioned like code, not retyped each engagement.
The question is coverage and consistency, so start with artifacts: the code, the library, every screen that ships. A counting exercise before it is a taste one: what exists, what’s duplicated, what has drifted, what has no owner.
The question is whether the thing does the right job, so start with people: who uses it, what they’re trying to finish, where they give up. Artifacts come second. A perfectly consistent product can still be the wrong product.
brief-intake runs before either.
Turn raw client material into one structured project file: problem, metric, users, constraints, ranked assumptions, open questions.
Procedure
Bundled
Evaluate a live product against usability heuristics and WCAG 2.2. Severity-rated findings, each with a cost, sequenced into a fix list.
Procedure
Bundled
Inventory a design system from what actually ships, diff the tokens in real use against what the system declares, and report drift with a cost attached.
Procedure
Bundled
Turn transcripts, tickets or analytics into at most ten insights, each with a participant count, one verbatim quote, and a sentence starting “so we should”.
Procedure
Bundled
Annotated flow diagrams plus a complete state matrix: empty, loading, partial, error, permission-denied, offline. Every state skipped is a decision an engineer makes alone.
Procedure
Bundled
Errors, empty states, labels and confirmations in the product’s own voice, tested at the longest string in the database. Lorem in an error state is an unfinished design.
Procedure
Bundled
Per-screen focus order, roles, accessible names, contrast pairs with measured ratios and target sizes, plus a criterion-by-criterion WCAG 2.2 AA record.
Procedure
Bundled
The developer package: token export, component state matrix, behavior written as rules, accessibility spec, real strings, and the design-QA checklist you’ll run on staging.
Procedure
Bundled
Argue against the work before the team or the client sees it. If the output is encouraging, it has failed.
Seven fronts
Bundled
A blank template proves nothing. These are the same nine skills run end to end on one project, so the output shape is visible before anyone runs a prompt.
Read this first
“Meridian” is a composite, assembled from the shape of real work with every client specific removed and every number invented for illustration. Nothing here is confidential and nothing here is a real measurement. Say that out loud in a demo: being visibly careful with a former client’s data is worth more than the example itself.
Reading order for a demo: 01 → 02 → 07. Intake shows the discipline, the drift report shows the analysis, the critique shows the self-skepticism.
The point isn’t to show that a model can write. Everyone knows that. It’s to show that the output has a fixed shape, that the shape came from a rubric someone wrote deliberately, and that the skill refuses to make things up. Full script in DEMO.md.
Show the README, then one SKILL.md. Point at the frontmatter versus the body. Only the description line is in context at rest, about forty words a skill.
Run brief-intake on this.
Point at UNRESOLVED in the metric row. “It didn’t invent a number. That’s the most important thing on this screen.” Then the assumption register, sorted by cost, each with an owner. Then exactly three questions back, not thirty.
Run ds-inventory against these screens.
Run heuristic-audit on the checkout flow. Two critical paths.
Point at the Cost column. A finding without a cost is trivia, and nobody funds trivia. If time is short, open the finished drift report instead of running it.
Run critique on that audit. Attack it on all seven fronts.
“It argues against the work before anyone else has to. If the output is encouraging, the skill has failed. That’s written into it.”
These are what make the library trustworthy in front of a client. A skill that breaks one of them produces output that has to be checked line by line, which defeats the point of having it.
01
Never invent a number
Every quantity traces to a named source, or it gets cut.
02
Say what you couldn’t determine
An honest gap beats a confident guess, every time.
03
Attach a cost to every finding
Findings without a cost are trivia, and nobody funds trivia.
04
Recommend, don’t enumerate
One recommendation, its trade, and the alternative you rejected.
05
Output is a file, not a reply
Written artifacts are the only part of a call that survives it.
A practice that can’t say where its tools stop isn’t a practice. These four stay with the designer, every time, on every project.
The problem statement
If it wasn’t argued with a human, it isn’t agreed.
Talking to users
A synthesis skill is worthless without transcripts someone earned.
The final visual call
Models average toward the mean. Hand-finished is the whole difference.
Anything stated as fact
Every number in a deliverable traces to a source, or it gets cut.
A skill library is a design system with prose instead of components, and it rots the same way if nobody owns intake, release and deprecation.
Nothing goes into a rubric because it sounds right. Every line traces to a specific engagement where its absence cost something. That’s the admission price.
Currently v1.0. When a rubric changes, prior outputs record which version produced them. Otherwise two audits stop being comparable and the whole point is lost.
Same discipline as an unused component. A library nobody trims becomes a library nobody reads, and an unread rule is worse than no rule.
It doesn’t decide what the loop is for. What stays with the designer: the problem statement, talking to users, the final visual call, and anything stated as fact.