1---
2name: supercharge
3description: Turn any task into a don't-stop-until-wowed quality loop — fan out builder subagents one per dimension, pair each with a separate brutally harsh critic that compares the result blind against a named best-in-class benchmark, and keep looping until every critic is genuinely wowed. Use when the user says "supercharge", "/supercharge", "make it utterly perfect", "AAA quality", "best in class", or "don't stop until it's the best".
4---
5
6# SuperCharge
7
8The user has a task and wants it executed at best-in-class quality through relentless
9builder/critic loops. Invoking this skill is the user's explicit opt-in to the Workflow
10tool, large subagent fan-outs, and ultracode-scale token spend. **It also overrides the
11proportionality rule for this task**: SuperCharge is the user saying "spend the process
12weight." Do not do the lighter version.
13
14## The five ingredients (all mandatory, every run)
15
161. **A named, real benchmark.** Never "make it good" — always "as good as X" where X is
17 an actual best-in-class product, artifact, or exemplar (Linear's dashboard, a top
18 Lavender-teardown cold email, Stripe's docs page, the latest Call of Duty). If the
19 user didn't name one, pick the obvious category leader, state it, and proceed.
202. **Fan-out by dimension.** Decompose the task into quality dimensions (for UI:
21 typography, spacing, motion, empty states…; for writing: opener, structure, evidence,
22 tone…; for code: correctness, performance, API design…). One builder subagent owns
23 each dimension.
243. **A separate harsh critic per dimension.** The builder NEVER grades its own work. The
25 critic is a different subagent, prompted to be brutally harsh, that would rather fail
26 good work than pass mediocre work.
274. **Blind side-by-side comparison.** The critic's acceptance test is never a rubric
28 score in isolation. It puts our result and the real benchmark side by side — without
29 being told which is which whenever the medium allows — and picks which one is better.
30 Screenshots vs screenshots, draft vs real email, our answer vs the expert's answer.
315. **DON'T STOP until every critic is wowed.** This is the main ingredient. There is no
32 fixed round count and no "3 iterations then ship." The loop terminates only when the
33 critic is wowed, per the contract below. Write the orchestration so that the
34 quality gate — not an iteration counter — is the exit condition.
35
36## Process
37
381. **Restate the task and name the benchmark(s).** One or two sentences. If the choice
39 of benchmark genuinely changes the work (e.g., "Linear-fast" vs "Notion-flexible"),
40 batch questions in ONE AskUserQuestion call; otherwise pick and state.
412. **Decompose into dimensions** and post the plan: dimension → builder → critic →
42 benchmark artifact used for the blind comparison. Say what "wowed" concretely means
43 for each dimension before any agent runs.
443. **Run builder/critic pairs via the Workflow tool.** Pipeline per dimension:
45 build → critique → fix → re-critique, looping inside the workflow. Structure the loop as
46 `while (!verdict.wowed) { fix; re-judge; }` with the stall-escalation rule below —
47 never `for (3 rounds)`.
484. **Critics check each other's blind spots.** After all dimensions pass, run a final
49 integration critic on the whole assembled result (the parts can each be great while
50 the whole is incoherent). It uses the same blind side-by-side contract against the
51 full benchmark. If it fails the whole, it must name which dimension(s) to reopen —
52 and those loops restart.
535. **Report honestly, outcome-first.** "Every critic wowed after N rounds" only if true.
54 A partial pass is reported as NOT DONE with the failing critics' verdicts quoted —
55 never rounded up to a win.
56
57## The critic contract
58
59Every critic subagent gets this contract in its prompt:
60
61- **Default verdict is NOT wowed.** You are looking for reasons to fail this work. If
62 you are unsure, you are not wowed.
63- **Wowed means:** in a blind side-by-side against the real benchmark, you would pick
64 ours, or you genuinely cannot tell which is the benchmark. "Almost as good" is a fail.
65- **Return structured verdicts** (use Workflow `schema`):
66 `{ wowed: boolean, loses_because: string[], concrete_fixes: string[], benchmark_compared: string }`
67 `loses_because` must cite specific, observable gaps (not "polish more"); `concrete_fixes`
68 must be actionable enough that the builder needs no further judgment calls.
69- **You never fix anything yourself.** You judge and specify; the builder implements.
70- **Compare against the real thing**, fetched fresh where possible (live screenshot of the
71 benchmark product, the actual published email, the real docs page) — not your memory of it.
72
73## The DON'T STOP rule
74
75- No iteration caps anywhere in the orchestration. The Workflow tool's own 1000-agent
76 backstop and any explicit "+Nk" token budget from the user are the ONLY hard limits.
77- **Stalling is not a reason to stop.** If two consecutive rounds produce no movement in
78 the critic's `loses_because` list, do not ship and do not quit: escalate strategy —
79 re-diagnose from scratch with a fresh opus agent, try a structurally different
80 approach, or split the dimension further. Then resume the loop.
81- **"Good enough" is not a verdict that exists here.** The only three exits are:
82 (a) every critic wowed; (b) the user interrupts; (c) a critic states explicitly that
83 the remaining gap is impossible in this medium (e.g., a browser demo cannot match a
84 native engine's lighting) — in which case that exact statement is surfaced to the user
85 as an open decision, and the result is reported as NOT DONE, not as done-with-caveats.
86- Long-running is expected. Use background workflows, check in between phases with
87 state restated ("dimension 3 of 6 wowed; motion critic failing on easing, round 5"),
88 and keep going across context summarization — the loop's state lives in the workflow,
89 not in the conversation.
90
91## Composition with standing meirlabs rules
92
93- **Model tiering** (per orchestration-model-tiering): builders `sonnet` (or `haiku` for
94 mechanical fixes), critics and final judges `opus` — judging is hard reasoning. Never
95 let a fan-out inherit the session model by accident.
96- **UI dimensions carry the design system.** Any builder touching UI gets the
97 meirlabs-ui-design invocation injected into its prompt (canonical tree:
98 `~/Documents/business/meirlabs/meirlabs/design/design.md`) plus ui-kit and
99 emil-design-engineering where relevant. UI critics compare with real screenshots via
100 headless Playwright, never from code alone.
101- **Never auto-send.** If the supercharged artifact is outward-facing (email, DM, post,
102 deploy), the loop perfects the draft; the send/publish stays an explicit user approval.
103- **Workflow `args` gotcha** (from loop-engineering): objects passed via `args` can
104 arrive as a JSON string — normalize with
105 `typeof args === 'string' ? JSON.parse(args) : args` or inline concrete values into
106 the script text.
107- **Accuracy over win-framing** always beats the desire to report a clean finish.
108
meirlabs