Case study · Method design
Designing with agents
I design the workflows AI agents follow (sizing, briefs, review gates, scored design QA, evidence) so agent-built work still meets a senior designer’s bar.
Designer and author of the workflows · Sep–Oct 2026 · Process design, QA rubrics, motion rules
The shape every run takes
01
Intake
Tickets, a truth sheet, a brief per role
02
Size
S0 Solo to S3 Batch, from written signals
03
Build
One implementer per feature, in its own worktree
04
QA panel
Six agents, each section scored 0–100 on its own
05
CTO gate
A judge that spot-checks the panel
06
Owner merges
A report, then I decide
03 → 05 loops until every section passes · max 4 rounds
At S0–S1 the boxes collapse; the discipline doesn’t. When the cap is hit, I get the scoreboard, because the spec is usually what’s wrong.
At a glance
Role
Designer and author of the workflows: rules, gates, rubrics, checklists. Written with Claude, me directing, testing on real projects and rewriting after every failure.
Timeline
2 Sep → 5 Oct 2026, from feature-factory to feature-factory-team. product-demo-motion v1.0.0 on 25 Sep, v2.0.0 on 26 Sep.
Stack
Claude Code skills (Markdown method, references, evals), dependency-free Node scripts, git worktrees, Jira and Figma via MCP, headless Chromium, ffmpeg.
Team
Me, plus the agents the skills dispatch (Haiku, Sonnet, Opus, Fable).
Status
In daily use on my projects and at work. product-demo-motion is MIT-licensed and packaged for release.
Faster, and more dangerous
AI coding agents made me much faster, and also more dangerous. Left alone, an agent ships the happy path, says “done” with confidence, adds “one small prop” to a component used on fourteen pages, and writes a test that passes without the change.
I’m a product designer, not an engineer. What I can do is define the process, the quality bar, the review moments and what counts as evidence. So I stopped prompting agents and started designing the system they work inside, as two skills I wrote.
Skill 01
feature-factory-team
Turns “build these tickets” into reviewed, tested branches I merge myself. Its panel includes the Design QA method I use at work.
Skill 02
product-demo-motion
Teaches agents to build self-playing landing-page demos that drive the real UI instead of a screen recording.
PRD snapshot
What “done” had to mean
Goal
Agent-built work a senior designer and a senior engineer would both sign, at a cost that fits the job.
Users
Me as owner; teammates sharing a repo; the agents, who read every rule literally.
Non-goals
A general autonomous agent; replacing design judgement with scores.
Constraints
Model prices differ 10× between tiers; agents forget everything between sessions; skills must work in any repo unedited.
Success criteria · as merge checks
3 required + 1 gate
Nothing lands unreviewed, untested, or on another session’s branch.
Required
Every quality claim has evidence: a Figma value, a screenshot, a repro.
Required
A typo costs minutes; a risky batch gets real scrutiny.
Required
Merge
Agents never push or merge. The owner decides.
Challenges
Five incidents, five rules
Every rule in these skills started as something that broke. I write the incident next to the rule, so the next agent doesn’t “simplify” it away. Each one below is pinned to the stage of the run where it happened.
Incident 01 of 05
Sizing: the same rigor for a typo and an auth refactor is wrong both ways
What happened
Small fixes were getting a manager, three agents and a frontier-model review; big ones sometimes got too little. The wrong model on mechanical work wastes money; the wrong model on a review gate ships bugs.
What I designed
Not a fixed pipeline, and not “let the agent decide”: four tiers, S0 Solo to S3 Batch, chosen from written signals. The rule is staff the question, not the title. Greps go to cheap models; judgement on risky diffs goes to the expensive one.
diff --stat
Size
Shared money helper
1 line
S2
forty callers
Rename
40 files
S1
wide, mechanical
S0 Solo
S1
S2
S3 Batch
Staff the question, not the title. Size comes from signals, not file count: shared surfaces, risky domain, spec clarity, reversibility, the owner’s words.
Outcome
A one-line change to a shared money helper sizes up to S2 because it has forty callers; a 40-file rename stays S1. Three evals with 25 expectations pin the behaviour.
Incident 02 of 05
Taste doesn’t survive a hand-off unless it’s written as rules with reasons
What happened
On product-demo-motion, parallel agents undid each other’s design calls: one added a hover lift, the next removed it as noise. A springy cursor made the product look like a toy. Agents start from zero every session.
What I designed
Every default carries a value, a reason and a rule ID. Reviewers cite the rule ID, so review becomes a checklist, not opinion.
rules · excerpt
value · reason
1
hover
Never pauses a demo.
2
// Readers rest the pointer on it.
3
progress
Holds at 97% until the result is on screen.
4
// So 100% never sits next to an empty screen.
5
cursor
clamp(240 + 0.9·d, 360, 760) ms, eased. No springs.
6
// A springy cursor made the product look like a toy.
Reviewers cite the rule, so review is a checklist, not opinion
The 97% hold · two frames
Waiting for the result
97%
Hold
100%
Landed
The bar never says done before the screen does.
Video: the fictional feature tour, one cursor, the 97% hold
A fictional feature tour built under the rules: one cursor, and a bar that holds at 97% until the result is on screen.
Cursor glide with a spring
Cursor glide, eased and clamped
The same move, sprung and eased. The spring is why the rule exists.
Outcome
22 core rules, 31 named anti-patterns, a 20-question quality bar. v2.0.0 shipped a day after v1, because I encoded my review decisions as rules instead of re-explaining them.
Filmstrip: frames of the feature tour from scripts/frames.mjs
Frame by frame, the way reviewers check motion: every frame has to hold up on its own.
Incident 03 of 05
Verification: agents are usually right, and sometimes confidently wrong
What happened
A manager agent described work its implementers hadn’t finished yet. A QA agent measured a backgrounded browser tab and reported a catastrophe that wasn’t real.
What I designed
Scores that are hard to inflate. Each section is scored 0–100 on its own, never blended. Every deduction needs evidence. What an agent couldn’t exercise is “not verified”, never 100. Re-scorers see earlier findings but not the earlier score, so they don’t anchor.
qa-panel · round 2 of 4
$ score --each-section --never-blend
> earlier findings in · earlier score hidden
Spec QA
0–100 · own section
Strict PM
0–100 · own section
Design QA vs Figma
0–100 · own section
Confused first-time user
0–100 · own section
Adversarial tester
0–100 · own section
Regression
0–100 · own section
CTO judge
spot-checks the panel
> pass 80–90 · never lowered to exit the loop
> cap 4 rounds → scoreboard to the owner
Design QA · body text · desktop
node 12:345
Property
font-size
Figma 16 px
Build 14 px
D
Design QA agent
14 px, Figma says 16 px, node 12:345. Screenshot attached.
Deduction stands · evidence: Figma value, build value, screenshot
R
Reviewer
Feels off.
No evidence, no deduction
“Not verified” is the most valuable score a QA agent can give.
QA scoreboard for a fictional feature: six sections, each scored on its own, plus one Design-QA row
A scoreboard for a fictional feature. No section borrows points from another.
Outcome
Six panel agents, pass marks of 80–90, a 4-round cap, and a judge that spot-checks the panel. Pass marks never drop to escape the loop; at the cap I get the scoreboard, since the spec is usually what’s wrong.
Incident 04 of 05
Truth: a demo makes claims, just like copy
What happened
In one audit, the brief said the feature “reads pages from screenshots.” The code showed it reads page text and takes no screenshots. A French demo was showing English labels.
Demo brief · truth sheet pass
The code wins
“Reads pages from screenshots.”
→
Reads page text. Takes no screenshots.
Source: UI code
English labels in the French demo.
→
Fix the translation in the product, never in the demo.
Source: translations
What I designed
Audits come before animation: a truth sheet from the UI code, translations and API. Missing translations get fixed in the product, never patched in the demo. In design QA, anything the PRD doesn’t cover becomes a decision question, not a bug.
Outcome
The screenshot claim cost one corrected sentence instead of a false animation on a public page.
Incident 05 of 05
Coordination: several agents, one repo, one owner
What happened
A “read-only” agent ran a sweep in the main checkout. A later cleanup reverted every modified file and destroyed another session’s uncommitted work.
What I designed
Every mutating agent gets its own worktree and branch. Sessions announce before touching anything shared; a peer never stands in for the owner’s approval.
For motion work: at most three agents, light checks per edit, the full gate once. Full rebuilds after every edit had been costing me days.
git log --graph · one feature batch
Owner merges
main
worktree 1
worktree 2
worktree 3
Three implementers, three worktrees, one merge point. The owner is the only one who merges.
Redacted project profile from the smart display repo: commands, base branch, forbidden operations, reporting language
The profile the skill writes on first run, redacted.
Outcome
On first run the skill writes a project profile: commands, base branch, forbidden operations, reporting language. Three of my repos have one.
Design decisions & system
The system, in four parts
Shape
Coordinator → one implementer per feature in its own worktree → scored QA panel → CTO gate → report → the owner merges.
Briefs as components
A template per role, carrying house rules from real bugs: “mutate every new test before it counts.”
Design QA lens
Property by property against Figma, every state, desktop and mobile: property, Figma value, build value, screenshot.
Evidence
Annotated screenshots, full-res GIFs, tickets with acceptance criteria. Nothing is posted until I approve. Reports come the way the owner wants them; mine are short, in Persian, in screens.
Annotated screenshot sample on a demo app: callouts with property, expected and actual values
An annotated screenshot on a demo app. Nothing is posted until I approve.
By the numbers
Counted from the files, not estimated
Read from the files themselves: sizes from wc -c, counts from ls and find, dates from file stamps, the changelog and the QA folders.
CHANGELOG · 2 Sep → 8 Oct 2026
Release · QA run
## September
2 Sep
feature-factory
7 references
24 Sep
Design-QA run 1
25 Sep
product-demo-motion v1.0.0
26 Sep
product-demo-motion v2.0.0
A day after v1: review decisions encoded as rules
## October
3 Oct
Design-QA run 2
5 Oct
feature-factory-team
References 7 → 8: adds the scored QA panel
6 Oct
Design-QA run 3
8 Oct
Design-QA run 4
A retest: 16 acceptance criteria checked with screenshots
Sources: file dates, CHANGELOG.md, QA folder dates
feature-factory-team
wc -c · SKILL.md · evals.json
---
size:
82 KB
SKILL.md 27.8 KB
tiers:
4
S0 Solo → S3 Batch
qa_panel:
6 + 1
agents + CTO gate
pass_marks:
80–90
never lowered
round_cap:
4
then the scoreboard
references:
7 → 8
added the QA panel
evals:
25
expectations · 3 prompts
---
product-demo-motion/
SKILL.md · CHANGELOG.md · find
SKILL.md
22
core rules
references/
17
files
anti-patterns.md
31
named anti-patterns
assets/demo-kit/
31
modules
scripts/
10
verification scripts
examples/
4
examples
Plus a 20-question quality bar. v1 → v2 in 1 day.
6 + global
repos with the skill
3
repos with a project profile
The smart-display repo
420 commits
Co-Authored-By: Claude
313 of 420
Pull requests · one tick each
51 · 50 merged
Gray tick: merged. Outlined: the one that wasn’t.
Next to measure: escaped bugs per tier, QA rounds to pass, and cost per feature.
What I learned
The method is the design surface
A rule without a reason gets misapplied; a rule with a reason generalises.
Most rules are scar tissue
Writing the incident next to the rule stops the next agent “simplifying” it away.
Next
Run the evals on every skill change, and release the design-QA method as a generic skill.