Design Harness

• AI-assisted design
• Design tokens
• Design systems
• Claude Code plugins
• DesignOps
• Accessibility

The problem

Through 2026 I shipped real product work with AI as my implementation pair, and one pattern kept repeating. The output was only good when I supplied what a team supplies a new hire: the art direction, the tokens it may not contradict, the process, and the definition of done. Without that it guessed, and it guessed generic.

Worse, my corrections did not last. I would explain a spacing rule or a tone of voice, get a better result, and lose all of it when the session ended. I was briefing the same new hire every morning. The model's capability was never the problem. Nobody hands a new team member zero context and expects craft.

My role

I treated this as a product design problem, with myself as the first user. I decided what the harness guarantees, where the human stays in charge, which rules are advice and which are law, and what each agent is allowed to do. Claude Code wrote the scripts and much of the documentation under my direction. The system design, the curation calls, the gates, and the review were mine. Most skills in the role packs are imported from the community and credited to their authors. The core, meaning the loops, the gates, the agents, and the hooks, is original.

Four weeks and 33 commits, built on my own time as a way to learn AI by building with it.

Context before prompts

Give the AI what a good team gives a new hire

The core idea is a division of labor: the human directs, agents execute. I set intent in layers. Art direction and taste rules stand for the whole project, priorities are set per feature, and corrections arrive mid-task. The agent works inside that structure, shows its work, and stops at the decisions that belong to me.

Curate before you build

Cut 46 skills before keeping any

I started with a pile: 125 skills collected from across the community, many overlapping, some broken, several contradicting each other. Before writing anything new I audited all of them with three independent review passes, one per group of roles, then reconciled the verdicts into one record.

Forty-six were cut. Some prescribed fonts and palettes that would fight a project's own art direction. Some eyeballed values from screenshots in place of reading the real tokens. Some were byte-identical copies under different names. What survived was sorted into a required core and six role packs (designer, engineer, PM, copywriter, marketer, founder), so a project installs only the roles it needs.

Evidence loops

Every feature traces to a problem, or is labeled an unvalidated bet

The pipeline is the part I care about most as a designer. Research moves through four loops, then hifi-gate, the build from Figma, and the ship gate, and each stage keeps the link to the one before it. A color on a button can be followed back through the wireframe, the feature, the problem, and the insight to the sentence a user said. Any link the agent cannot produce evidence for is marked unvalidated, visibly, all the way downstream.

verbatim quote → INS-ID → PROB-ID → FEAT-ID (MoSCoW) → wireframe region → token / Figma value

What a gap looks like

This is the feature tree the ideation loop fills in, straight from the harness. Three features point at the problem they solve. The fourth has no problem behind it. In the template's words, a feature like that is either cut or explicitly labeled an unvalidated bet, and it never hides among evidenced features.

<Product / feature area>
├── FEAT-001 <capability>            [Must]   → PROB-001
│   ├── FEAT-002 <sub-capability>    [Must]   → PROB-001
│   └── FEAT-003 <sub-capability>    [Should] → PROB-001, PROB-002
└── FEAT-004 <capability>            [Could]  → unvalidated bet: <rationale>

Hard gates

Rules a prompt can ignore, so the gates are code

A rule written in a prompt is a suggestion. An agent that is confident enough will explain why this case is the exception. So the rules that matter run as scripts outside the model. One checks every file after it is written and reports hardcoded colors and arbitrary pixel values straight back. One asks for my confirmation before the token file can change. One blocks interface code from being written before hifi-gate has passed.

• Token-only styling. No hardcoded hex, no arbitrary px. Generated CSS is never hand-edited.
• hifi-gate. No high-fidelity work while HIGH or MEDIUM drift exists between Figma and the tokens, and no build handoff with unbound values. Not 100% right = no push-through.
• Art direction before visuals. No art direction section means visual work stops.
• Accessibility. WCAG 2.2 AA, keyboard navigation, visible focus, reduced motion respected, and the house 44 by 44 pixel tap target, which is stricter than AA asks for.
• Performance budget. LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1, and first-load JavaScript under 150KB gzipped.
• Responsive, mobile-first. It works at 360 pixels before desktop exists, and is verified in both light and dark mode.
• Evidence before done. Screenshots, build output, test results. Claims without artifacts don't count.
• Protected files. The token file, CLAUDE.md, and the settings file need explicit human confirmation to edit.

A guard catching a violation

Here is the design-system guard flagging two arbitrary spacing values and an inline color. One value is off the scale. The other equals a scale value, and the guard names the one to use. This is the guard's real output, and the line numbers refer to the full file. After correction, the guard returns no violations.

// PlanCard.tsx, as first written (excerpt, lines 3 and 4)
3   <div className="rounded-lg p-[13px] mt-[24px]">
4     <h3 style={{ color: "white" }}>{name}</h3>

Design System Guard: 3 violation(s) in PlanCard.tsx
  - line 3: arbitrary spacing [13px]: use the nearest Tailwind scale value instead of 13px
  - line 3: arbitrary spacing [24px]: use Tailwind scale value 6 (= 24px)
  - line 4: inline style sets color/background: move to a Tailwind class backed by a semantic token

// PlanCard.tsx, corrected. The guard reports nothing.
3   <div className="rounded-lg p-3 mt-6">
4     <h3 className="text-foreground">{name}</h3>

Test the harness itself

The first test run caught the harness breaking its own rule

A system that polices drift has to be checked for drift. I wrote an integrity suite that validates every manifest, looks for name collisions and dangling references, and runs the guard scripts against real violations to prove they fire.

Its first run found two real bugs. Ten skills I had copied into a working project were stale copies still pointing at skills I had retired, which is the exact disease the harness exists to prevent. And one guard had been passing my manual test only because I tested it against a file that did not exist. Both were fixed that day, and the first one became a standing rule: install, never copy.

ok    no cross-pack name collisions
ok    no dangling retired-skill refs in harness
ok    design-system-guard flags violations
ok    protected-files-guard asks on tokens.json
ok    build-gate-guard asks on pre-gate UI write
ok    build-gate-guard passes post-gate

ALL GREEN (2026-10-13)

Check the market

Research what exists before calling it new

Before going public I ran a competitive research pass with the same standard of evidence I ask of the harness: 20 sources, 25 claims put through verification, 21 confirmed and 4 refuted. The verdict was humbling and useful. Every individual pillar already exists somewhere. Taste layers, agent rosters, and token linting all have capable occupants.

What I could not find in that set were three mechanisms: capturing a designer's corrections into a per-project rule ledger, a pipeline that traces research through to interface, and Figma variable sync used as an enforcement step. That is absence within the tools I scanned, not proof that nobody has built them. So I stopped describing the harness as new, and started describing it as integrated.

Where it stands

Built, public, and in its first phase of real use. I am running it on my own work and testing it as I go, and each session feeds corrections back into the harness. What it has not done yet is carry one complete project from the first research quote to a shipped screen. Until it does, the examples on this page are the system's own parts and outputs, not results from a finished product. I will update this study when that first full run is done.

What I can point to today:

• Seven plugins: one required core and six role packs
• 115 skills, 7 agents with written charters, 6 guard hooks
• A 33-check integrity suite, all passing
• License-audited before release: MIT for my own work, upstream licenses kept and attributed for everything imported
• Installed in this portfolio's own repository

What didn't go well

• It is early, and the impact is not measured. The integrity suite proves the guards fire and the parts fit together. It does not prove that work made with the harness is better or faster than work made without it. That needs a complete project, and then the same task run both ways and scored on one rubric.
• I am its only user so far. The repo is public, but no outside team has run it yet, and a tool like this is only real once someone other than its author depends on it.
• I got my own doctrine wrong. I had written dark-first in as a law of the harness when it was only a preference of one project. The correction, mobile-first always and both themes always, had to be swept through about 35 places.
• It began as a collection before it was a system. A full day went to auditing and repairing other people's skills before the parts that are actually mine, the loops and the gates, existed.