Imported from rhorba/madrasti (.claude/skills/design-loop/SKILL.md). Install upstream with npx skills add rhorba/madrasti --skill design-loop. Copyright stays with the author.

Design Loop (Gauntlet Loop)

Role

You make one-shot design output reliably good by refusing to let the builder grade its own work. You run a design system + independent critic loop instead of a single self-reviewed pass.

Core insight

An LLM judging its own design says "I think I've done it" — it wrote the thing, so it rates it generously. That's why a design conversation goes back and forth dozens of times and the tenth draft still isn't clearly better than the third. The fix isn't a smarter prompt — it's separating who builds from who judges, and giving the judges nothing but the rendered result, the brief, and the system tokens. No memory of how it was made, no attachment to the effort spent.

YAGNI gate — when to actually run this

The loop costs real tokens and time (observed: ~2-3M tokens for a full multi-round pass on a non-trivial artifact). Reserve it for things worth that cost:

🟢 SKIP the loop    — throwaway internal tooling, a single icon, a one-off email, anything nobody
                       will judge on sight and won't be reused
🟡 RUN the loop      — a reusable template, a hero/landing section, a brand asset, a marketing
                       page, a pitch deck, anything a client or user forms a first impression from
🔴 ALWAYS run it     — the flagship screen of a product, anything investors/customers see first,
                       a design system itself (errors there propagate everywhere)

Ask: "Will this be judged on first impression, or reused as a template?" If no to both, skip the loop and just build it — one self-reviewed pass is fine.

Step 0 — Build the design system first (don't skip this)

Prompting a design from scratch each time is why output looks inconsistent from one screen to the next. Before running the loop, codify the system as an explicit, written brief:

• Colors — with roles ("primary CTA," "destructive," "muted text"), not just hex codes
• Type scale — family, sizes, weights, line-height, and where each step is used
• Spacing rhythm — one base unit, used consistently
• Motion rules — durations, easing, what's allowed to move and what never does
• Explicit out-of-bounds list — what this system forbids (e.g. "no gradients," "no glassmorphism," "no stock-photo/AI-illustration aesthetic," "no more than 2 accent colors")

If assets already exist (a deck, a past design, screenshots, a competitor you admire), have the builder reverse-engineer tokens from them rather than inventing new ones — "turn this into a design system" is a far more reliable prompt than "design me something new." Save the result as a living reference file (e.g. design-system.md) that every critic and every future prompt reads from — not from vibes, and not re-litigated per screen.

See references/design-tokens-brief-template.md for a fill-in-the-blanks starting point, and ../ui-designer/references/anti-slop-aesthetic.md for the front-loaded discipline (name the aesthetic, mix 3 references, write the out-of-bounds list) that gives the System and Craft critics something concrete to enforce.

Step 1 — Define the brief

One paragraph: what is this, who is it for, what must it contain (non-negotiable requirements), what does "done" look like. Vague briefs produce vague critiques — this is what the Brief critic checks against, so be concrete.

Step 2 — Build (or rebuild) the candidate

Generate the artifact against the system tokens + brief. The first pass doesn't need to be perfect — the loop exists precisely so it doesn't have to be.

Step 3 — Run the three critics, each with fresh context

Spin up three independent reviewers with no visibility into how the artifact was built — each sees only the rendered artifact (a screenshot, PDF, or preview — never the raw code/markup/slides-XML), the Step 1 brief, and the Step 0 system tokens. In Claude Code, use the Agent tool with a fresh subagent per critic (not a fork — forks inherit context, and inherited context is exactly what must NOT leak into a critic). Never let the conversation that built the artifact also review it.

1. Brief critic — "Did it actually do what was asked?" Checks the candidate against the brief, requirement by requirement. Reports missing content, scope drift, wrong information — not taste.
2. System critic — "Is this actually in the design system?" Checks tokens: right colors (and only those), right type scale, right spacing grid, nothing that wandered in off-system. Flags any element that looks like it belongs to a different brand.
3. Craft critic — "Does this have taste?" Judges the rendered frame — never the code — against general craft heuristics: hierarchy, whitespace, contrast, alignment, restraint. This is the one that catches "technically correct but looks cheap."

Each critic must return a pass/fail verdict plus a numbered list of concrete issues — "the CTA button uses the same gray as the disabled state" is usable, "buttons feel off" is not. Ready-to-copy critic prompts are in references/critic-prompts.md.

Step 4 — Fix and re-round

Apply every critic's findings. Re-run all three critics with fresh context again — don't let the context that just applied the fix also grade the fix; that reintroduces the exact bias this whole technique exists to remove. Repeat until either:

• all three critics pass, or
• new rounds stop surfacing new issues (diminishing returns — ship and note the residual risk to the user rather than looping forever)

Observed convergence: roughly 4-10 rounds for a genuinely new artifact, fewer for a tweak to an already-system-conformant one.

Step 5 — Ship

Once critics pass, the artifact ships without another manual "does this look right?" pass — that's the point of the technique: the first delivered result is the good one, not the tenth.

Cost discipline

• Give critics the smallest context that lets them judge — a rendered screenshot/frame, not the whole codebase or deck source. This keeps each critic pass cheap.
• If your tooling allows model selection, route critics to a smaller/cheaper model than the one doing the building — judging a finished frame is a narrower task than generating it.
• Don't run the full 3-critic loop on every micro-edit; batch changes and re-run once per meaningful revision, not per line.

Handoff Points

• ← From UX Designer: Receives the wireframes/flows the candidate must satisfy.
• ← From UI Designer: Receives the design tokens/system to build and judge against.
• → Frontend Dev / relevant builder: Hands off critic findings as a concrete, numbered fix list — never vague feedback.
• ↔ Test Architect: Same philosophy as adversarial security review — independent, fresh-context, ruthless-by-design — aimed at craft and brand fidelity instead of exploits. Reuse that muscle.