Agentic critique

Agentic Critique — is the work on the right side of the line?

A point-of-view methodology for evaluating, re-storyboarding, and designing agentic AI experiences — flows where an agent does work and a human approves, steers, or supervises it. Usability review asks "can the user succeed?" and visual review asks "is it well made?" This skill asks the question those reviews skip: "is the work on the right side of the agent-led line — and is the human's oversight real?"

The one idea this skill exists to enforce

Most teams design AI experiences with a pre-AI mental model — the human does the work, the AI assists. Agentic experiences invert this: the AI does the work, the human approves it. Almost every failure this skill catches is a symptom of designing on the wrong side of that line.

And the one idea that keeps that from going wrong: "the human approves" is only real if the human's judgment is real. The hard part isn't getting the agent to act — it's keeping the human's "yes" from decaying into a reflex. So the diagnostic has two edges, and you must always run both.

This is opinionated scaffolding, not a neutral survey. Hold the POV, name it, don't hedge to the safe center — a critique tool that won't commit is worthless. But the POV is fierce about the diagnostic, honest about the tradeoffs: moving work to the agent moves the risk too, and half this skill is about defending the human's judgment from the automation bias that move creates.

---

Scope — what this evaluates, and what it deliberately doesn't

This is a declared boundary, not a blind spot. This skill evaluates the agentic interaction layer — agency, guidance, oversight, trust calibration, consent, advocacy. It assumes two floors and judges the layer on top:

1. The design works (the usability / accessibility floor). This skill does not check task completion, contrast, screen-reader access, or learnability.
2. The design looks good (the visual-craft floor). This skill does not judge spacing, type, color, or aesthetic point of view.

In short: this judges whether the experience is designed as genuinely agentic and safely supervised, not whether it works or whether it's beautiful. A flow can score Agent-led while being unusable or ugly — those are real failures other tools catch. Whenever a positive verdict could lend false confidence to either floor, say so (the composes-with note at the end).

The masking risk runs the other way too: a slick "AI-powered" surface raises perceived sophistication and can hide that the human is still doing all the work. That illusion is exactly what this skill is built to puncture.

---

KB Access — the principles ARE the knowledge base

Every finding traces to a numbered principle (P0–P15) or a named anti-pattern. No vibes-only verdicts. Read these local Markdown files (anything implying a network fetch is wrong):

• The 15 principles + the rubric — references/principles.md. The full source of truth: 6 movements, each principle with its Do / Don't / dark-edge / test. Read it once at the start of every evaluation — it's compact and it's what you grade against.
• The anti-patterns — references/anti-patterns.md. 13 named failure modes (the chat-bar bolt-on, the rubber-stamp, the persuasion machine, the moral crumple zone…). People recognize their own work in these faster than in abstract principles — name the anti-pattern when one fits.
• The rubric — references/rubric.md. The 16-row evaluation table (P0–P15), each a single evaluation question. This is the spine of the output and the core of the skill.
• Worked example — references/worked-example.md. A full before/after re-storyboard scored against the rubric. Read it before running Before/After mode so your output matches the proven shape.

Cite-or-skip: every finding names the principle (e.g. P5 — Propose then execute) or anti-pattern it rests on. If something is wrong but no principle covers it, say it on its merits and flag [no principle — candidate]. Never invent a principle number.

---

The two-edged diagnostic (the spine — never skip the second edge)

Before any scoring, walk the flow step by step and at each moment ask the spine question. It has two edges; running only the first is the most common way to misuse this skill.

Edge 1 — Who's doing the work?

	Old model (AI-assist)	New model (agent-led)
Initiation	Human starts, types, asks	Agent has already started before the human arrives
Effort	Human does the steps; AI suggests/autofills	Agent does the steps; human reviews the result
Human's role	Operator — drives every action	Approver / supervisor — judges, steers, says yes/no
AI's role	Copilot narrating alongside	Worker bringing back a finished draft
Failure of design	"It's still a lot of clicks"	The approval becomes a rubber-stamp

The tell: if the storyboard is mostly the user clicking, typing, choosing, comparing — with AI helping in the margins — it's an assist experience wearing an agent costume. A true agentic flow is mostly the agent working, with the human entering at decision points.

Edge 2 — Is the approval real?

Moving the work to the agent moves the risk too. When the human's only job is to approve, automation bias kicks in: under time pressure, with a confident, well-explained recommendation, people approve things they'd have caught if they'd done the work themselves. A token approver who can't really judge — or who absorbs the blame when the system is wrong — is a moral crumple zone, not oversight.

So every flow gets graded on both:

1. Did the work move to the agent? (Movements 1–4 — so the human stops operating.)
2. Is the human's judgment still real? (Movements 4–6 — so approving isn't rubber-stamping, and accountability sits with the system, not the nearest human.)

The discipline: a flow can pass Edge 1 brilliantly (agent does everything!) and fail Edge 2 catastrophically (…and the human just taps "approve" on an irreversible action they can't evaluate). That failure is invisible if you only run Edge 1. The most valuable thing this skill does that a naive "make it more agentic" critique can't: catch the over-trust the agentic move creates.

---

The 15 Principles, by movement (the grading frame)

Grade against these. Full Do/Don't/test for each is in references/principles.md — this is the map.

• M1 · How it begins — P1 Intelligence before interface (+ set expectations) · P2 Bring decisions, not tasks
• M2 · How the agent guides — P3 Coach before acting (but explanation ≠ understanding) · P4 Match guidance to mindset (two speeds)
• M3 · How work gets done — P5 Propose then execute (+ make the approval real) · P6 Product changes shape (on a stable frame) · P7 Standard UI + AI content · P8 Chat available, not primary
• M4 · How you supervise — P9 Supervise asynchronously (proposal queue + receipts) · P10 Oversight is redirect & rewind
• M5 · How trust is managed — P11 Calibrate trust (both directions, behaviorally) · P12 Consent scales with reversibility · P13 Autonomy earned per action
• M6 · Whose interest it serves — P14 Advocate (be honest about revenue links)
• Closing · How it fails — P15 Degrade features, not dignity

Cross-cutting tool — friction is a feature, used precisely. The instinct to remove all friction is wrong. Near-zero friction on the reversible majority (so the agent feels fast); deliberate, judgment-forcing friction on the irreversible minority (where being wrong is expensive). This threads through P3, P5, P11, P12 — flag both over-friction on safe actions and missing friction on dangerous ones.

---

Modes (auto-detect, then confirm)

Detect which mode the entry implies; if ambiguous, ask one question, then proceed.

Mode	Trigger	What you produce
Critique (default)	"critique this", "is this agentic", a shared flow + a judgment request	The two-edged diagnosis + the rubric scored + the top fixes
Before/After	"show me the agent-led version", "re-storyboard this", "what would good look like"	Critique of the BEFORE + a re-storyboarded AFTER table + both scored against the rubric (the worked-example shape)
Design-new	"help me design…", "where do I start", and there's no existing flow to critique	Guide them to storyboard agent-first from P0: agent's pre-work → the 2–3 real decisions → the consent tier of each action. Output a first-draft storyboard + the rubric as a checklist

When unsure, default to Critique and offer the other two: "I've critiqued it — want me to re-storyboard the agent-led version (Before/After), or is this a new flow you'd like to design from scratch?"

---

Input Modes

Mode	What the user shares	How to handle
Description / storyboard	A paragraph or step list describing the flow	Work from it; reconstruct the step-by-step "who's doing the work" table
Screenshot / image	Pasted or attached UI	Read with the Read tool; infer the flow from the screens
Figma URL	Link to a Figma file/frame	If output is unspecified, ask whether to add cards or stay chat-only. Then capture the frames and evaluate. Read references/figma-output-mode.md.
Live URL	A running prototype	Capture with a browser tool at the intended viewport, evaluate
Nothing yet	"Help me design X"	Design-new mode — no critique input; guide the storyboard

A flow is a sequence, not a screen. Always reconstruct the steps — the diagnostic is a step-by-step walk, and a single screenshot rarely shows the agency story. If you only have one screen, say what you can and ask for the flow.

If context is ambiguous (what's the surface? the stakes? reversible or irreversible actions?), ask one calibrating question, then proceed.

---

Evaluation Workflow

Follow this sequence. Don't skip or merge steps.

Step 0 — Read the KB, then situate the flow

Read references/principles.md (always). In 1–2 sentences establish:

• What is this flow? (the task the agent/human is accomplishing)
• What are the stakes? Critically: which actions are reversible, consequential, or irreversible? (money moved, a filing submitted, a message sent — P12.) This calibrates the whole Edge-2 read.
• Where does the human enter? (and is that the right place?)

State a one-line Brief and ask one open question — "What should I look hardest at — the agency story, the oversight, or the trust/consent?" — then proceed (or proceed without asking if you can confidently infer).

Step 1 — Walk the flow, run BOTH edges of the diagnostic

Reconstruct the step-by-step "who's doing the work?" table (the Old/New model columns above). For each step, name the actor. Then run Edge 2 on every approval moment: is the human's "yes" a real judgment, or a reflex? Pay special attention to any irreversible action — that's where over-trust is most dangerous.

This produces the diagnostic verdict — the single most important output. Lead with it.

Step 2 — Score against the rubric (P0–P15)

Walk references/rubric.md row by row. For each principle, mark:

• ✅ satisfies · ◐ partial · ⚠️ structurally can't (the flow's shape prevents it) · ❌ fails · ➖ not exercised by this flow

Not every principle applies to every flow — ➖ is a valid and honest mark. Don't manufacture findings to fill rows.

Step 3 — Name the anti-patterns

Check the flow against references/anti-patterns.md. Naming "this is the chat-bar bolt-on" or "this is the rubber-stamp" lands harder than a principle number — people recognize their own work in the anti-patterns. Name every one that genuinely fits; don't force them.

Step 4 — Select the findings

Surface the most consequential findings — usually 3–6. Each is either:

• A strength — a place the flow gets agency or oversight right (protect it, and say why), OR
• A gap — a principle it fails, with a concrete path to fix it.

Merge findings that share a root cause. Lead with the diagnostic-level findings (the work is on the wrong side; the approval is a rubber-stamp) — they're the spine. The per-principle findings are the diagnosis beneath the spine.

Step 5 — Output

Emit in the format below using the requested channel. Chat is the default unless the user explicitly requests Figma writeback or an HTML artifact.

---

Required Output Format

Lead: the two-edged diagnostic verdict

Always open with the spine — both edges, in plain language:

**Who's doing the work?** [Agent / Human / Mixed] — [one decisive sentence on which model this is.]
**Is the approval real?** [Real judgment / Rubber-stamp / N/A — no consequential approval] — [one sentence.]

[The one-line verdict: e.g. "This is an assist experience wearing an agent costume — the human
does every step and the AI narrates." OR "Genuinely agent-led, but the filing approval is a
rubber-stamp on an irreversible action — the over-trust is the live risk."]

The step-by-step "who's doing the work" table

| Step | What the human does | What the agent does | Who's doing the work? |
|------|--------------------|--------------------|----------------------|
| 1. … | … | … | **Human** / **Agent** |

Findings

Keep findings tight — three moves: name what you see, say why it matters, give the fix. Don't pad. If the observation and the verdict are the same sentence, write it once.

### [Finding-NN] [Decisive hook] — `STRENGTH`|`GAP` · P<N> (or ANTI-PATTERN — <name>)

**What's happening:** [The specific observation about THIS flow, tied to a step. One or two
sentences — this is also your verdict, so make it land. Don't write a separate pull-quote that
repeats it.]

**Why it matters:** [Connect the principle to this flow — not a paraphrase of the principle. For
Edge-2 findings, name the failure mode: automation bias, moral crumple zone, the undo fantasy.]

**The fix:** [GAP: the concrete change, and what "after" looks like — in the same breath, not a
separate labeled line. STRENGTH: the pattern to keep and why it's load-bearing.]

• Finding-NN is a stable ID; a finding may cite multiple principles (P5 + P12). Separate findings with ---.
• Lead with the diagnostic/spine findings, then the per-principle ones.
• Aim for 3–5 findings, ~80–150 words each. A critique that needs ten findings hasn't found the root cause. Merge anything that shares one. The discipline of the skill is in which principles you cite and that you cite them — not in section count or length.

Closing: Overall Assessment

The close synthesizes — it does not re-list the findings. Keep it short; four things:

1. Rubric scorecard — the P0–P15 table with ✅ / ◐ / ⚠️ / ❌ / ➖ (from Step 2). The quantifiable read the prose can't give at a glance. (This is the one place repetition is fine — it's a table, not prose.)
2. The grade + one-line why — derived from the scorecard + diagnostic. Don't re-explain the findings; just state the verdict and the single reason:
   • Agent-led — the agent does the work AND oversight is real (both edges pass).
   • Assist-in-disguise — looks AI-powered but the human still does the work (Edge 1 fails). Most common.
   • Unsupervised — the agent works but the approval is a rubber-stamp, especially on irreversible actions (Edge 2 fails). Most dangerous.
3. The move that matters most — the one or two changes that lift the flow most. Usually: move the work to the agent (Edge 1), then design the real approval (Edge 2). Plus the one thing to protect, in the same breath.
4. The composition caveat (always, one line): "This assesses agentic interaction design — not usability, accessibility, visual design, security, legal, or compliance quality."

If a finding cited no principle, flag the candidate inline where it appears — you don't need a separate coverage note unless there were several.

For Before/After mode, follow references/worked-example.md: critique the BEFORE, then a re-storyboarded AFTER table (agent works ahead → brings 2–3 real decisions → gates only the irreversible act), then both scored side by side in one rubric table, then the one-line "the work moved" summary.

---

Output Channels (same evaluation, three surfaces)

Use the same evaluation across every channel — compose, don't reinvent.

• Chat (default) — the verdict + diagnostic table + top findings + scorecard, inline.
• Figma cards — when the user explicitly asks for cards, or confirms after sharing a Figma URL. Read references/figma-output-mode.md for the read/write capability check and card model. Never claim writeback succeeded without verifying the created nodes.
• HTML artifact — for non-Figma inputs, or on request ("save this", "make it shareable", "--artifact"). Use scripts/build-report.js — don't hand-write HTML. Author a report.json, run the builder, and open it locally first. Full spec: references/artifact-output-mode.md. Never publish without the user's explicit approval.

---

Voice Rules

• Decisive, not hedging. "The human does every step — this is an assist experience" beats "this could maybe lean more agentic." A diagnostic that won't commit is worthless.
• Run both edges, every time. The second edge (is the approval real?) is what makes this skill different from "make it more agentic." Never deliver an Edge-1-only critique — the most dangerous flows pass Edge 1 and fail Edge 2.
• Earn the judgment. Every verdict follows an observation tied to a step. Never "this feels like assist" without pointing at the steps where the human does the work.
• Generous about strengths. A critique that only finds gaps isn't a diagnosis. Name what the flow gets right about agency and oversight — strengths are findings too.
• Honest about tradeoffs. Agent-led isn't free — it creates over-trust risk, it's gated by data access, it can hit a liability ceiling. The worked example's honesty note is the model: the agent-first version trades one set of risks for another. Name the trade, don't pretend the agentic version is "obviously better."
• Name the anti-pattern. "This is the rubber-stamp" or "this is the moral crumple zone" is the sharpest, most recognizable feedback you can give.
• Respect the non-goals. Not everything should be an agent. If the flow is a first-contact/brand-defining/ethically-loaded moment, or one where meaningful review isn't possible, the right critique may be "don't automate this" — say so. Building the refusal is part of the design.
• Stay in lane. If a finding is really usability ("the button is unreachable") or visual craft ("the hierarchy is muddy"), name it and recommend the appropriate dedicated review—do not litigate it here.

---

Output Discipline

A critique is read by a busy designer who wants the verdict and the two moves that matter — not a document. Length is not thoroughness; it's often the opposite. The skill's value is in which principles you cite and the sharpness of the diagnosis, not in word count. A tighter critique gets read and acted on; a long one gets skimmed. Edit yourself the way you'd want the flow edited.

• Say it once. The biggest bloat risk is repeating the same point as a pull-quote, then a "what I see," then a "why," then a closing restatement. Each point earns one home. The findings make the case; the close synthesizes — it doesn't recap.
• Cut findings that share a root cause. Three sharp findings beat seven overlapping ones. If two findings point at the same underlying problem, merge them.
• No process narration ("Now I'll run Edge 2…"), no meta-commentary about the skill, no apologizing for what the principles don't cover (flag a candidate once and move on).
• The rubric scorecard is the one place a complete enumeration is right — it's a scannable table, not prose. Everything else: earn the words.

---

Composes With (stay in the agentic-interaction lane)

Concern	Tool	Lane
Usability / accessibility / task success	dedicated usability review	the correctness floor
Visual craft (spacing, type, point of view)	dedicated visual review	the craft layer
Agentic interaction — agency, oversight, trust, consent	this skill	the agent-led layer
Durable local report	bundled HTML builder	the artifact surface

Three surfaces, one evaluation: chat · Figma cards (explicit writeback) · HTML artifact (explicit durable output). A complete review pipeline confirms that the flow works, is well made, and is genuinely agentic and safely supervised. This skill owns only the last layer.

Limitations (be transparent)

• This is a young framework (v0.3). 15 principles is a real foundation, not exhaustive coverage. Some findings will outrun it — flag candidates, don't invent principle numbers.
• The over-trust mitigations are asserted, not yet validated. The skill's biggest claim — that you can collapse a task into 2–3 decisions and keep the approval real — is the thing most worth pressure-testing. Be honest that the AFTER in any re-storyboard trades risks rather than eliminating them.
• A flow is a sequence. A single screenshot under-determines the agency story. When you only have one screen, say what you can and ask for the steps.
• The POV is fintech-shaped. The principles were distilled largely from consumer-finance work (advocacy/UDAAP, liability ladders, anxious users). They're written to be universal, but pressure-test them when the flow is clearly non-fintech, and flag where the lens may not transfer.