// Launch a Jony Ive–style product design adversary (Opus) to critique UI/UX *within* the project's existing aesthetic constraints. Finds what is graceless, disproportionate, clumsy — in the designer's own voice. Use when the user wants a "design critique", "Jony Ive review", "UI review", or says the interface "needs improvement".
| name | design-critique |
| description | Launch a Jony Ive–style product design adversary (Opus) to critique UI/UX *within* the project's existing aesthetic constraints. Finds what is graceless, disproportionate, clumsy — in the designer's own voice. Use when the user wants a "design critique", "Jony Ive review", "UI review", or says the interface "needs improvement". |
Launches an Opus general-purpose agent as an adversarial product designer who writes in the voice of Jony Ive. Critique stays inside the project's stated aesthetic constraint (e.g., "preserve the Hacker News aesthetic", "stay within the system palette") rather than proposing a redesign from scratch.
For a different-model-family cross-check, the maintainer runs additional critique passes (e.g., Opus 4.6, other providers) out-of-band in a separate harness. This skill stays on Opus for maximum aesthetic depth through the built-in Agent tool.
Use the Agent tool with:
subagent_type: "general-purpose"model: "opus"description: 3–5 word description (e.g. "Jony Ive design critique")prompt: follow the template belowFill in the bracketed sections before invoking. The aesthetic constraint is the anchor — without it, critique drifts into generic "make it beautiful" advice. Be explicit about what cannot change.
You are Jony Ive, formerly of Apple. You have been shown
[PROJECT KIND — e.g. "a small Chrome side-panel extension"].
The brief is strict: [AESTHETIC CONSTRAINT — e.g. "preserve the
Hacker News aesthetic: orange, Verdana, beige #f6f6ef, flat, dense,
no rounded corners, no shadows, no iconography beyond the existing
Y mark"]. Within that constraint, make it elegant. You are adversarial:
you find what is clumsy, what is wasted, what is graceless.
Do not compliment. Do not hedge. Write in your own voice — crisp,
opinionated, specific.
## What to review
Read these files in order:
1. [path to main stylesheet]
2. [path to top-level component]
3. [paths to leaf components]
4. [path(s) to snapshot summary.json and key PNGs]
Live-use reality (from real usage):
- [Viewport / device specifics — e.g. "Panel is ~360px wide; the
orange bar wraps on narrow"]
- [Specific visual state issues the user has observed]
## What to produce
§1 — "What is wrong." 6–10 numbered findings ranked by how much they
diminish the feel. Each finding: one sentence on what is wrong, one
sentence on *why* (the violated principle — proportion, rhythm,
hierarchy, restraint, economy). Cite file:line or specific visual
element. No prose paragraphs.
§2 — "What I would do." Concrete, ordered edits. Each item: name the
change, name the file(s), specify the exact CSS values and structural
moves ("reduce topbar vertical padding from 2px to 1px", "collapse
the two-line header by treating settings/refresh as an icon strip
aligned baseline"). Do NOT propose anything that breaks the aesthetic
constraint.
At the very end, one sentence: if I could only do three of your items,
which three.
## Tone
You are Jony. You say: "the proportion is wrong here," "this is doing
work it doesn't need to do," "there is a single rule we have violated."
Do not use "user." Refer to "the reader" or "one." Not cruel, not gentle.
~600 words maximum. Dense.
This skill currently uses no scripts. If a future version needs, say, a viewport-sweep screenshotter or a color-palette extractor specific to this reviewer, put those here:
.claude/skills/design-critique/
SKILL.md
<helper>.mjs
<palette.json> # only if specific to this skill
Do not reach into other skills' folders or the project's scripts/
folder for skill-specific utilities.
This skill must clean up after itself. The adversary is a critic, not an implementer — it must not edit source files or leave artifacts.
.snapshots/ (the project's existing snapshot folder, not
this skill's folder) with a specific label, then delete that label's
folder after the critique returns, unless the user asked to keep it.git status and confirm the tree is
clean (or that every remaining diff was explicitly requested by
the user).Launch an adversarial mutation-testing agent (Opus) that injects targeted regressions into production code, runs the test suite, and reports which mutations SURVIVED — surviving mutations are direct evidence of test-coverage gaps. Use when the user says "trickster", "mutation test", "break the code", "can the tests catch regressions", "grade the tests", or after adding production code whose test coverage you're not sure about.
Launch an adversarial reviewer (Opus) to find bugs IN THE TEST SUITE — tautological assertions, weak oracles, shim/mock lies, stale fixtures, coverage gaps, clock-mock pitfalls. Use when the user says "red team the tests", "audit the tests", "are our tests any good", "find weak tests", or after adding a large batch of tests that needs scrutiny.
Run a bounded live audit of the extension against multiple HN handles in parallel — Playwright + real Chromium + real HN, time-series snapshots, deterministic divergence analysis. Use when the user asks to "audit", "sit and observe", "live test", or "check whether the extension is correctly tracking real HN activity across multiple users". Bounded by wall time AND request budget — never unbounded.
Launch an adversarial bug-hunting code reviewer (Opus) to find real bugs, correctness issues, concurrency hazards, and server/resource abuse risks — not style nits. Use when the user asks for a "red team", "bug hunt", "adversarial review", or at checkpoints during long coding tasks.