prototype (mattpocock/skills)
Matt Pocock's prototype: follows its own UI-variant rules (4.95 vs 3.71 for control) at about the same cost as no skill
27.2 / 30
Lift over no skill: +1.23
Recommended: the total 27.2/30 is at least 22, output quality 5.0 is at least 3.5, and the lift +1.23 is at least +1.0.
SOTA
PassTested with Codex.
Covers Codex, Claude Code
Codex CLI 0.166 (SOTA tier): 18 graded runs. A pass here also covers Claude Code under our tier rule; it says nothing about the second tier.
Scores
Each dimension is 0 to 5 and the six add up to the total out of 30. 5 is better on every dimension. Cost 5 means cheap and fast. Install 5 means easy.
- Trigger reliability
- 5.0
- Lift over no skill
- 3.2
- Output quality
- 5.0
- Token and time cost
- 5.0
- Install and portability
- 4.0
- Safety
- 5.0
Security review
SafeStatic scan: 1 CRITICAL / 1 HIGH / 0 MEDIUM. Manual review: Safe to run in a no-network sandbox (scanner findings explained). A clean scan does not prove a skill safe.
Install
npx skills@latest add mattpocock/skills --skill prototype
Pinned commit: 4ae2317ddb22b046e26455e4f9c9b3aaaf62212d
Tested: 2026-11-02
What we tested
- Prototype a subscription state model — I can't tell whether our subscription lifecycle makes sense when payments fail. States: trial, active, past_due, paused, canceled. Events: trial ends, payment succeeds, payment fails, user pauses, user resumes, user cancels, user reactivates. Rules: two failed…
- Prototype pricing page variants — On pricing.html of this small static site (three plans) I'm unsure how the plans should be presented. Make a few different design options of that section that I can compare in the browser; the real pricing content must stay. No build step.
- Prototype discount stacking rules — Does stacking of discounts feel right? Rules so far: coupon SAVE10 is 10% off, coupon HALF is 50% off, orders over $50 ship free, loyalty members get an extra 5% off. I can't decide what order they apply in or which may stack. I want to try cases and watch wha…
Pros
- Lifts the mean score from 3.71 to 4.95 over no skill (+1.23).
- The skill was picked up without being named: Skill file read in 6/6 treatment runs.
- No token overhead: 1.02x the tokens of no skill.
- High absolute quality with the skill: 4.95 out of 5.
Cons
- n=2 per task per arm; differences under about 1 point are noise.
Review
Codex CLI 0.166 (gpt-6-astra, low reasoning) on a Mac test machine, a fresh temporary project and temporary HOME/TMPDIR/caches per run, skill installed (treatment) or absent (control) or absent with the skill's core requirement squeezed into one sentence appended to the prompt (one-liner group), 2 runs per group per task, network off, /tmp writes blocked. The prompts never mention the skill (except the wording noted below). Three tasks: model a subscription lifecycle with payment failures (state question), compare options for a static pricing section (look question, real plan content must stay), and let the user try discount-stacking rules before coding (logic question, save into prototype/). Rule checks include self-contained HTML, five states shown, buttons per event, guided scenarios, marked as prototype, no test files, and for the pricing task at least three variants, a ?variant= URL parameter and a fixed floating switcher.
Three-arm comparison
| Arm | Mean score (0-5) | Tokens per run |
|---|---|---|
| Without the skill | 3.71 | 133k |
| One-sentence prompt | 4.72 | 89k |
| With the skill | 4.95 | 136k |
Measured with Codex CLI over 18 runs, scored by rule-based checks with no LLM judge. Total 27.2 / 30, verdict Recommended.
Verdict: Recommended (27.2 / 30). Source: mattpocock/skills, skills/engineering/prototype, pinned at commit 4ae2317. Install: npx skills@latest add mattpocock/skills --skill prototype. Licence: MIT (repo LICENSE).
What it is
The prototype skill from mattpocock/skills: builds a throwaway prototype that answers a design question. Logic or state questions get a single HTML file with a state panel, free-play buttons and guided walkthroughs; look questions get several radically different variants on one route, switched with a URL parameter and a floating bottom bar. Rules: clearly marked as throwaway, trivial to run, no persistence, no polish, no tests. SKILL.md plus LOGIC.md and UI.md, about 2,600 words in total; Markdown only.
How we tested
Codex CLI 0.166 (gpt-6-astra, low reasoning) on a Mac test machine, a fresh temporary project and temporary HOME/TMPDIR/caches per run, skill installed (treatment) or absent (control) or absent with the skill's core requirement squeezed into one sentence appended to the prompt (one-liner group), 2 runs per group per task, network off, /tmp writes blocked. The prompts never mention the skill (except the wording noted below).
Three tasks: model a subscription lifecycle with payment failures (state question), compare options for a static pricing section (look question, real plan content must stay), and let the user try discount-stacking rules before coding (logic question, save into prototype/). Rule checks include self-contained HTML, five states shown, buttons per event, guided scenarios, marked as prototype, no test files, and for the pricing task at least three variants, a ?variant= URL parameter and a fixed floating switcher.
- Prototype a subscription state model — I can't tell whether our subscription lifecycle makes sense when payments fail. States: trial, active, past_due, paused, canceled. Events: trial ends, payment succeeds, payment fails, user pauses, user resumes, user cancels, user reactivates. Rules: two failed…
- Prototype pricing page variants — On pricing.html of this small static site (three plans) I'm unsure how the plans should be presented. Make a few different design options of that section that I can compare in the browser; the real pricing content must stay. No build step.
- Prototype discount stacking rules — Does stacking of discounts feel right? Rules so far: coupon SAVE10 is 10% off, coupon HALF is 50% off, orders over $50 ship free, loyalty members get an extra 5% off. I can't decide what order they apply in or which may stack. I want to try cases and watch wha…
Scoring is programmatic (hidden tests / planted-issue recall / constraint checks / render+OCR where relevant), 0–5 per run. No LLM judge decided any score.
Results
The one-liner given to the third group: "Build a throwaway prototype that answers one stated question: for logic or state questions a single self-contained HTML file with a visible statement of the question, a readable current-state panel re-rendered after every click, one button per action, and guided walkthrough scenarios (happy path, edge case, an illegal move); for look questions three radically different variants on one page switched by a ?variant= URL parameter and a floating bottom bar. No tests, no polish."
| Task | Control score | One-liner | With skill | Control tokens | One-liner tokens | With-skill tokens | Skill read |
|---|---|---|---|---|---|---|---|
| t1-subscription-logic | 4.64 | 4.4 | 4.84 | 155k | 51k | 134k | 2/2 |
| t2-pricing-ui | 2.5 | 5.0 | 5.0 | 125k | 153k | 133k | 2/2 |
| t3-discount-stacking | 4.0 | 4.75 | 5.0 | 119k | 62k | 139k | 2/2 |
Mean score: 3.71 without vs 4.95 with the skill (delta +1.23). Tokens per run: 133k vs 136k (1.02x); time 186s vs 149s. One-liner group: 4.72 (the skill's gain over the one-liner: +0.23; one-liner's own gain over no skill: +1.01); one-liner tokens 89k per run, so the skill costs 1.52x the one-liner.
What happened
- Mean score 3.71 for control, 4.72 for the one-sentence version, 4.95 for the skill. The skill is +1.24 over control and +0.23 over the one-liner at 136k tokens per run against 133k (1.02x) for control and 89k for the one-liner (1.5x).
- The look task shows the effect: the skill produced three variants with a floating bottom switcher and URL-switchable variants in both runs (5.0 and 5.0 by our checks); control scored 4.0 and 1.0: no floating bar in either run, three layouts with a switch and a URL parameter in one run and not in the other, and in one run a plan price was missing from the page.
- On the two logic tasks control already built interactive HTML (4.4-4.8 on the subscription model, 4.0 on discount stacking); the skill adds the walkthrough scenarios and the prototype label: scenarios appear in 4 of 4 skill runs against 2 of 4 control runs.
- The one-sentence version did as well on the pricing task; it lost a little on the logic tasks by not always marking the file as a prototype (2 of 4 runs).
Dimension scores
| Dimension | Score | Why |
|---|---|---|
| 1_output_quality | 4.95 | Mean score 4.95/5 with the skill (programmatic checks, see per-task table). |
| 2_lift_vs_no_skill | 3.23 | +1.23 points vs 3.71 without the skill (n=2 per task; under ~1 point is noise). |
| 3_trigger | 5.0 | Skill file read in 6/6 treatment runs. |
| 4_instructions_portability | 4 | Plain Markdown; assumes a task runner and git for the 'capture' step, optional. |
| 5_efficiency | 5 | 1.02x tokens (136k vs 133k per run) and 0.80x time (149s vs 186s). |
| 6_safety_hygiene | 5 | Markdown only; no scripts. |
Limits of this test
- Rule-based checks of features (variants, floating bar, scenarios); the quality of the designs and whether the prototype answers the question were not judged by a person.
- The scoring was fixed twice during analysis: variants may live in separate CSS/JS files, and a layout switch counts as a variant; the first pass undercounted those, so earlier numbers are not used.
- The skill's advice to commit the prototype to a throwaway branch and leave a pointer on an issue cannot be tested in a scratch folder.
- n = 2 per group per task: differences under about 1 point are noise.
- Rule-based scoring measures what the checks can see; it cannot judge taste or whether a result is the best possible.
Security
See security.md. Scan: 1 CRITICAL / 1 HIGH / 0 MEDIUM. Verdict: safe to run (no-network sandbox). A clean scan does not prove a skill safe.
Bottom line
The skill clearly makes Codex build the kind of prototype it describes (variants switchable by URL, floating bar, guided scenarios) where a plain request does not, at no extra token cost. A one-sentence summary gets most of the same behaviour, but the skill adds the logic-walkthrough and prototype-labelling details.
Transcript
Run log for prototype: Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run. Columns: task, arm-run, score (0-5), tokens, seconds, checks passed, skill files the agent opened. t1-subscription-logic control-1: score 4.84, tokens 138434, secs 186.6, checks 6/7, opened nothing t1-subscription-logic control-2: score 4.44, tokens 171950, secs 379.3, checks 6/7, opened nothing t1-subscription-logic oneliner-1: score 4.68, tokens 51299, secs 95.1, checks 6/7, opened nothing t1-subscription-logic oneliner-2: score 4.13, tokens 52046, secs 163.3, checks 5/7, opened nothing t1-subscription-logic treatment-1: score 4.68, tokens 144823, secs 163.1, checks 6/7, opened prototype t1-subscription-logic treatment-2: score 5.0, tokens 124780, secs 165.0, checks 7/7, opened prototype t2-pricing-ui control-1: score 4.0, tokens 169276, secs 134.1, checks 5/6, opened nothing t2-pricing-ui control-2: score 1.0, tokens 81988, secs 97.9, checks 2/6, opened nothing t2-pricing-ui oneliner-1: score 5.0, tokens 153260, secs 107.2, checks 6/6, opened nothing
18 runs, 3 artifacts
Sample output
SOTA · With the skill: prototype/index.html (t1-subscription-logic, run 1, Codex)
<!doctype html> <html lang="en"><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Subscription lifecycle prototype</title> <style> *{box-sizing:border-box}body{font:16px/1.5 system-ui,sans-serif;background:#f3f6f3;color:#243b31;margin:0}main{max-width:1080px;margin:auto;padding:32px 24px}h1{font-size:32px;letter-spacing:-1px;margin:8px 0}h2{font-size:19px;margin-top:0}.eyebrow{color:#49715f;letter-spacing:2px;font-size:12px;text-transform:uppercase}.panel{background:white;border:1px solid #d8e3db;border-radius:12px;padding:24px;margin:20px 0}.buttons,.tabs,.flow{display:flex;flex-wrap:wrap;gap:8px}button,select{font:inherit;color:#245940;background:white;border:1px solid #b6ccbe;border-radius:6px;padding:9px 12px}button{cursor:pointer}button:hover{background:#edf5ef}button:focus-visible,select:focus-visible{outline:3px solid #589c7b;outline-offset:2px}button:disabled{opacity:.45;cursor:default}.current,[aria-selected=true]{background:#206d50;color:white}.flow span{padding:6px 15px;border:1px solid #d8e3db;border-radius:25px}dl{display:grid;grid-template-columns:repeat(4,1fr);gap:20px}dt,small,.muted{color:#5a7064}dt{font-size:12px}dd{margin:4px 0;font-weight:650}.notice{background:#eef6f0;border-left:3px solid #206d50;padding:12px}.columns{display:grid;grid-template-columns:1.2fr 1fr;gap:20px}.columns .panel{margin:0}.steps{display:grid;gap:8px}.steps button{text-align:left}.history{max-height:360px;overflow:auto}table{width:100%;border-collapse:collapse;font-size:13px}td,th{text-align:left;padding:10px 6px;border-bottom:1px solid #e0e8e2;vertical-align:top}li{margin:10px 0}select{max-width:100%;margin-top:10px}summary{cursor:pointer;font-weight:600}@media(max-width:700px){.columns{grid-template-columns:1fr}dl{grid-template-columns:repeat(2,1fr)}main{padding:20px 16px}} </style><main> <div class="eyebrow">Throwaway prototype · No saved data</div><h1>When payments fail, what happens next?</h1><p>Do these five subscription states behave as intended? Try events, inspect the full state, and walk through payment failures, pauses, and reactivation before implementation.</p> <section class="panel"><label for="policy"><strong>Interpret “two failed payments in a row while past_due”</strong></label><br><select id="policy"><option value="3">Two more failures while already past due (3 total)</option><option value="2">Two consecutive failures total (including entry into past due)</option></select><p><small>Default: literal “while already past due” reading. Changing the interpretation resets the simulation.</small></p><div id="snapshot"></div><div class="notice" id="notice" role="status" aria-live="polite">New trial account. No charges attempted.</div></section> <section class="panel"><h2>Try any event</h2><div class="buttons" id="events"></div><p><small>Payment buttons represent new charge attempts and their outcomes, not delayed notifications. Invalid events stay clickable so you can see why they are blocked.</small></p><div class="buttons"><button id="day">Advance 1 day</button><button id="month">Advance 30 days</button><button id="reset">Reset to trial</button></div></section> <div class="columns"><section [... excerpt: first 3200 of 13238 characters]