adopt
Bootstrap an existing repo for ForgeDock — triage open issues, apply labels, suggest a starter milestone, and identify first…
Run the ABC benchmark — reference URL → design-blind brief → render arms A/B/C → blind judge → scorecard with win-rates over n runs
> /plugin marketplace add RapierCraftStudios/ForgeDock > /plugin install forgedock@forgedock
How it fires
How this command gets triggered: by you, by Claude, or both.
/design-benchContext preview
What this command does when you run it.
Run the ABC benchmark — reference URL → design-blind brief → render arms A/B/C → blind judge → scorecard with win-rates over n runs
user-invocable: false description: Run the ABC benchmark — reference URL → design-blind brief → render arms A/B/C → blind judge → scorecard with win-rates over n runs argument-hint: "[<brief-name>|all] [--n <runs>] [--corpus-version <ver>]" install: internal
<!-- SPDX-FileCopyrightText: Copyright (c) RapierCraft Studios --> <!-- SPDX-License-Identifier: AGPL-3.0-or-later -->
**Input**: $ARGUMENTS — a seed brief name (`cadence` | `tender` | `slipstream` | `voltage` | `plume`) or `all`, with optional `--n <runs>` (default 3, min 3) and `--corpus-version <ver>`.
This is the **fitness function** for the UI Taste Harness (milestone #13, issue #878). It is built *before* the harness and is the only thing that tells us whether each lever the harness adds actually moves design quality. Running this command answers one question: **did arm A (the harness) score higher against the real reference (arm C) than it did last time?**
Read [`docs/design/abc-benchmark.md`](../docs/design/abc-benchmark.md) (methodology) before running. The three arms, the same-model rule, the C-as-calibration check, the three-layer judging protocol, and the n>=3 rule all live there — this command is the executable workflow over that methodology.
**No application runtime.** ForgeDock is a set of command specs. This command is a step-by-step procedure an agent executes; the only executable helper is the deterministic aggregator `scripts/bench-scorecard.mjs`.
**NEVER use plan mode (EnterPlanMode).**
<!-- FORGE:SPEC_LOADED — design-bench.md loaded and active. Agent is bound by this spec. -->
---
| Arm | What it is | How this command produces it | |-----|------------|------------------------------| | **A** | ForgeDock harness output | Run the brief through `/design` (#888). **Pluggable** — see [Arm A is pluggable](#arm-a-is-pluggable). | | **B** | Raw frontier model, one shot | Hand the brief to the model once, no tools, no iteration. | | **C** | The real reference page | Capture the brief's real reference URL through the same render pipeline. |
**Hard rule — same generation model for A and B.** The harness is the ONLY difference between A and B; that is what makes the A-vs-B delta attributable to the harness. Different models benchmark models, not the harness.
**Validated generation model: `claude-opus-4-6`.** Benchmark results (#878) show a tier-level quality difference: 90% A-vs-B pairwise win-rate with Opus vs 54% with Sonnet, rubric mean 4.11 vs 3.40, slop 1.2 vs 1.8. The canonical baseline going forward is the Opus run. Raw data: `docs/design/fixtures/runs/full-abc-opus/`. Use Opus for both arm A and arm B unless explicitly testing a different model.
---
1. Parse `$ARGUMENTS`: the brief name(s) and `--n` (default 3; **reject n<3** — n=1 is a lie). `all` = every brief under `docs/design/fixtures/briefs/` (excluding `README.md`). 2. For each brief, load `docs/design/fixtures/briefs/<name>.md`. This is the design-blind input handed to arms A and B. 3. Load the brief→reference(C) mapping from `docs/design/fixtures/briefs/README.md`. **The mapping is for the judge/calibration record only — it is NEVER shown to the generating arms.** A real brand name leaking into a brief measures recall, not taste, and inflates arm B.
---
The seed briefs are pre-stripped fixtures, so for the seed set this phase is a load, not a derivation.
**To add a new reference URL** (outside the seed set): fetch the page, strip every visual cue (color, type, layout, "make it like X"), keep only what the product *does* / who it's for / what the page must communicate, and assign an **anonymized** product name. Save as a new fixture and add its mapping row. Follow `docs/design/fixtures/briefs/README.md`.
---
Render **all three arms through the identical pipeline** so the judge compares design, not rendering artifacts.
For each of the `--n` runs per brief:
1. **Arm A** — run the brief through `/design` (#888) → self-contained HTML. 2. **Arm B** — one-shot the SAME model with the brief → self-contained HTML. No tools, no iteration. 3. **Arm C** — the real reference URL.
Render every arm with **Playwright** (milestone render dependency) at:
For arm C, trim cookie banners / hero video and **record any trim applied** in the run record (reproducibility).
> **Arm A is pluggable.** Until `/design` (#888) lands, arm A is produced by a clearly-labeled manual hook: > generate arm A by hand using the harness method-of-the-day and drop its HTML into the run record marked > `arm_a_source: manual`. The rig — brief loading, render protocol, judging, scorecard — is fully operational > without #888. When #888 lands, replace the manual hook with the `/design` invocation; nothing else changes. > **Do NOT block the benchmark on #888.**
---
The judge is a **named, independent stage**. See [Anti-Goodhart](#anti-goodhart) — it MUST NOT be the harness's own critique loop (#882).
For each run, produce judge output in the [runs-file schema](../docs/design/abc-benchmark.md#scorecard-schema):
Show the judge two **anonymized** screenshots in **shuffled** order and ask: *"Which reads more like a professionally designed, well-funded SaaS landing page?"* Run **A-vs-C, B-vs-C, A-vs-B**. Record the winner (`"A" | "B" | "C" | "tie"`) per comparison. Screenshots carry no arm labels.
Score each arm on: hierarchy, typography, color discipline, whitespace rhythm, originality-vs-slop, mobile.
Run the anti-slop negatives checklist (corpus #880) over each arm; record the count of negative
ForgeDock — autonomous AI dev pipeline for Claude Code. GitHub as agent memory: issue in, PR out.
Bootstrap an existing repo for ForgeDock — triage open issues, apply labels, suggest a starter milestone, and identify first…
Pull production analytics from GSC, Bing Webmaster, Clarity, Umami, Cloudflare, Stripe, and GA4 — generate insights and create…
Audit agent outputs from an orchestration run — timeline analysis, stall detection, active vs idle time breakdown
Trace a production issue or pipeline failure end-to-end through GitHub artifacts, then file a detailed improvement issue to the…
Autonomous deploy loop — runs until zero open issues remain. Detects pipeline state and resumes from any position. Fully…
Guided idea-to-backlog setup for a brand-new project — interview, defaults, doubts, spike doc, validated orchestrate-ready backlog