Layout Skill Bench — three skills and a baseline, one brief

One local model — Qwen3.8 Flash Next (MLX) — built the same deliverable three times, once per design skill: five landing-page iterations for a note-taking “second brain” app, with an easy switcher between them. Every run received the same byte-identical verbatim brief and ran on the same model in the same harness (opencode). The one thing that changed between runs was the design skill loaded. Every figure on this page comes from bench/layout-skill-bench/results/arms.json, the single source; a value that was not collected would render as a gap (—), never zero. This is a controlled comparison of three different skills, not one skill against a baseline and not one configuration run twice.

“I want you to design the landing page for a note-taking application as essentially a second brain. You should design five iterations and each of them should be accessible within the slash one, slash two, slash three like pages directory. And then you should add a little button that lets me switch between them easily.” The verbatim brief — SHA eaebe847…, 318 characters, byte-identical across the three skill runs (confirmed against the opencode session database). The vanilla baseline adds a two-line no-skills preface and one trailing space.

What the comparison holds and what it varies read this before the grid

Held identical across the three skill runs

  • The brief — the exact 318-character text above, SHA eaebe847…, byte-identical in every run.
  • The model — Qwen3.8 Flash Next, MLX, on the local rig, at zero API cost.
  • The harness — opencode, one session per run.
  • The task — five landing-page iterations plus a switcher; every run shipped exactly 5 pages.

Varied — one design skill per run

    Why this is three skills, not two — and where the baseline stands

    taste-skill and taste2 ship a byte-identical skills-lock.json (both pin brandkit, design-taste-frontend and high-end-visual-design from Leonxlnx/taste-skill). A lock file records which skills were available, not which one fired. Reading each session's actual transcript shows different skills ran: taste-skill invoked design-taste-frontend (an 87,308-character skill message) and taste2 invoked high-end-visual-design (a 10,476-character one). brandkit appears in neither session. So the two arms are not a repeat run of one configuration.

    design-skill has no lock file at all — it is not part of the Leonxlnx/taste-skill package. Its transcript shows it loaded frontend-design from the user's global skill directory, so it is not a no-skill baseline either. Each of the three ran a real, different design skill. The baseline arrived later as a fourth run, vanilla, whose prompt opens “do not use any skills” — but it ran qwen/qwen3.8-flash through openrouter at variant high, not the local Flash Next at xhigh, so it answers “what do the pages look like without a skill” and not “what did the skill cost”.

    The four runs, five pages each session metrics above each strip; every cell opens that run’s real page on the published site

    Session metrics, side by side every figure from arms.json — click a header to re-rank

    All metrics, all four runs

    Recovered from the opencode session database (none of the runs shipped a stats file), collected into bench/layout-skill-bench/results/arms.json. There is no “best” highlight: more tokens or more wall time is not “better” — it mostly reflects how much the loaded skill asked the model to do.

    Run (skill) Wall (min) Output tok Uncached in tok Cache-read tok Tool calls Messages Pages

    Bases, from the arms.json notes: Wall is first message to last recorded token event. Messages counts user + assistant turns — taste2’s 19 is the only count that includes a mid-run auto-compaction event and a “continue” nudge, alongside the same two substantive turns the other runs have; design-skill’s single user turn combined the skill document and the brief into one message, while the other two received them as two separate turns. All four ship 5 pages, matching the brief.

    Two dimensions, drawn cost, not quality — read the captions

    Wall time per run

    Minutes, first message to last recorded token event.

    taste2’s 38.0 min ran the longest of the four; its session is also the only one carrying a mid-run auto-compaction event. Wall time here tracks how much each skill asked the model to do, not the quality of what shipped.

    Output tokens per run

    Tokens the model generated. Cache-read input (hundreds of thousands per run) dwarfs output and lives in the scoreboard, not here.

    taste2 generated the most output (89,922), roughly double design-skill’s 37,742 — again a reflection of skill verbosity and run length, not a score.

    Limits, stated plainly