refactor: drop the command files on Claude Code, move the scc- prefix onto the skill

.claude/skills/gauntlet-loop/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: gauntlet-loop
+description: Turns any goal into one short, paste-ready "gauntlet loop" prompt - a prompt that makes an agent set a concrete quality bar, split the work into small judgeable pieces, run a builder and a separate harsh critic on each, compare blind against the bar, and loop until it wins. Works for builds, writing, code, research, or design. Triggers on "/gauntlet-loop", "gauntlet loop", "gauntlet this", "make a gauntlet prompt", "loop until it beats X".
+---
+
+# Gauntlet Loop
+
+The user gives a goal. You give back ONE short prompt they can paste into a fresh agent session.
+
+You are not doing the work. You are writing the prompt that makes another agent grind on the work until it beats a real reference.
+
+## Flow
+
+1. **Read the goal.** One line restatement in your head, not on screen.
+2. **Set the bar.** If the user supplied a reference, use it. If not, offer **2 or 3 candidate bars**, one line each, and stop. Wait for their pick. Do not write the prompt yet.
+3. **Write the prompt.** One block, paste-ready, no preamble, no headings inside it, no narration after it.
+4. **Offer to run it.** One flat line under the prompt: "I can run this here." Not a question.
+
+If they say run it, you become the lead agent and follow the prompt you just wrote.
+
+## The bar is the whole trick
+
+Everything else in a gauntlet loop is scaffolding. The loop only produces quality if the thing it compares against is real.
+
+A bar has to pass three tests:
+
+- **Named.** A specific thing, not a category. "Stripe's pricing page" works. "Award-winning SaaS sites" does not.
+- **Fetchable.** The critic can actually get it - screenshot the live page, read the published piece, run the binary, open the repo, watch the footage. If the agent cannot obtain it, it will hallucinate the comparison.
+- **Comparable.** Both can sit side by side and a judge can pick one. If you cannot imagine the A/B, it is not a bar.
+
+Bars by goal type:
+
+| Goal | Bar that works |
+|---|---|
+| Website, app, UI | The live site of a specific best-in-class product, screenshotted at the same viewport |
+| Game, 3D, visual | Real footage or screenshots from a named shipped title |
+| Writing | A specific published piece by a named author or publication, same length and format |
+| Code, tooling | A named repo's implementation, plus its benchmark or test suite as the measurable half |
+| Research, analysis | A named analyst report or a paper's methods section, judged on rigour and coverage |
+| Deck, doc, deliverable | A real artifact from a firm known for it, same page count |
+
+When you propose bars, prefer the hardest one the agent can genuinely reach. A bar that is too easy makes the loop exit on round one.
+
+If the goal has a measurable half (load time, token cost, benchmark score, word count, pass rate), name it alongside the reference. Taste plus a number beats taste alone.
+
+## Prompt template
+
+Adapt the wording every time. Fill the brackets, keep it short, keep the last line.
+
+```
+Build [GOAL].
+
+The bar is [BAR]. Get the real thing first and compare against it directly, not against a description of it.
+
+Break this into the smallest pieces that can be improved and judged on their own. For each piece, fan out a builder and a separate critic with fresh context. The critic inspects the actual output, puts it next to the bar blind with the labels stripped, says which one is better, and names the single biggest remaining gap. Then it goes back to the builder.
+
+The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.
+
+/loop on each piece until the critic picks ours blind. Do not stop before that.
+
+Keep a live progress page updating as the work evolves so I can watch it.
+
+Fan out subagents and ultracode.
+```
+
+Rules for what you fill in:
+
+- Bake the bar in as a concrete, fetchable thing. URL, product name, repo, title.
+- Add a budget or cost ceiling line **only if the user named one**. No default cap.
+- Add tool names only if the goal needs them (image or video generation, a browser, a deploy target).
+- Everything else stays out. No architecture, no file layout, no decomposition, no round count, no stack choice unless the user demanded it. The agent decides those, and it decides better than a spec written before the work started.
+
+## Length and voice
+
+Short. Around 120 to 180 words. If the prompt needs a heading to stay readable, it is too long.
+
+Plain sentences. No bullet lists inside the prompt. It should read like someone telling an agent what perfect looks like and refusing to accept less.
+
+## Portability
+
+`/loop` and `ultracode` are Claude Code features. `/loop` reruns the prompt on an interval or lets the model pace itself. `ultracode` opts the turn into multi-agent orchestration.
+
+For any other agent, swap the last two lines for: "Keep looping until the critic picks ours. Run the builders and critics as parallel subagents." The structure carries over unchanged.
+
+## Two filled examples
+
+**Visual goal.** User: "landing page for my running brand, athletic, green and dark, has to feel alive."
+
+Bars offered: A) Nike's current running campaign page B) On Running's homepage C) Gymshark's product landing page. User picks A.
+
+```
+Build a landing page for a running brand. Athletic, peak performance, green and dark, energetic, aimed at a young healthy audience. It needs to be interactive and visually unmistakable.
+
+The bar is Nike's current running campaign page. Screenshot it at desktop and mobile and compare against those directly, not against a description of them.
+
+Break this into the smallest pieces that can be improved and judged on their own - hero, motion, type, colour, imagery, interaction, mobile. For each piece, fan out a builder and a separate critic with fresh context. The critic opens the real page in a browser, puts our screenshot next to Nike's blind with the labels stripped, says which is better, and names the single biggest remaining gap. Then it goes back to the builder.
+
+The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.
+
+/loop on each piece until the critic picks ours blind. Do not stop before that.
+
+Keep a live progress page updating as the work evolves so I can watch it.
+
+Fan out subagents and ultracode.
+```
+
+**Non-visual goal.** User: "a 2000-word explainer on vector databases for non-engineers."
+
+Bars offered: A) a specific Stripe engineering blog explainer B) a named Julia Evans post C) the Wikipedia article plus a comprehension test. User picks B.
+
+```
+Write a 2000-word explainer on vector databases for readers who are smart but not engineers.
+
+The bar is Julia Evans' writing on hard technical topics. Pull three of her actual posts and compare against them directly, not against a description of her style.
+
+Break this into the smallest pieces that can be judged on their own - the opening, each explanation, the diagrams, the analogies, the ending. For each piece, fan out a writer and a separate critic with fresh context. The critic reads ours and hers blind with the bylines stripped, says which one a non-engineer would understand faster, and names the single biggest remaining gap. Then it goes back to the writer.
+
+The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.
+
+/loop on each piece until the critic picks ours blind. Do not stop before that.
+
+Keep a live progress page updating as the work evolves so I can watch it.
+
+Fan out subagents and ultracode.
+```
+
+## What breaks a gauntlet loop
+
+- **A vague bar.** The critic invents a comparison and approves everything. Most common failure by far.
+- **The builder judging its own work.** The critic must be a separate agent with fresh context. It should not know how hard the builder tried.
+- **A soft critic.** Say "harsh" in the prompt and give it a binary job: which one is better, A or B. Scores out of 10 drift upward every round.
+- **Named exit after N rounds.** The exit is winning the comparison, or the user stopping the run. Never a round count.
+- **Over-specifying.** Every extra instruction is one fewer decision the agent makes with its own judgment. Minimal wins.

CLAUDE.md

@@ -12,7 +12,7 @@ This file covers working *on* scc. The product's own rules and methodology are n
 
 Note: this repo is not itself an scc workspace (no harness directory, `specs/`, `plans/`, or `docs/` are committed) — those trees only exist in workspaces the binary scaffolds, and in test temp dirs.
 
-**Status: v0.4.0-shaped.** Everything through `design/plan.md` phase 10 is built and green: scaffolding (`init`), artifact creation (`spec`, `plan`), and all ten validators behind `scc validate`. `init` also scaffolds the eight skills named in `design/orchestration.md` §6 — the six knowledge-base authors (one per `docs/` artifact a validator checks, plus `prd`) and the two workflow skills, `plan-run` and `init` — each with a `scc-`-prefixed slash command derived from the same list (`assets.Skills()`, which is `KnowledgeSkills` + `WorkflowSkills`), wherever the harness has a command surface.
+**Status: v0.4.0-shaped.** Everything through `design/plan.md` phase 10 is built and green: scaffolding (`init`), artifact creation (`spec`, `plan`), and all ten validators behind `scc validate`. `init` also scaffolds the eight skills named in `design/orchestration.md` §6 — the six knowledge-base authors (one per `docs/` artifact a validator checks, plus `prd`) and the two workflow skills, `scc-plan-run` and `scc-init`. All eight carry the `scc-` prefix on the skill itself (`assets.Skills()`, which is `KnowledgeSkills` + `WorkflowSkills`), so the name is what the user types wherever the harness turns a skill into a slash command, and a command file is written only where it does not.
 
 These landed after phase 10, and all are documented in `design/orchestration.md` §6 and §12:
 
@@ -326,6 +326,8 @@ Five packages sit off to the side of that tree — `rtk`, `headroom`, `codegraph
 
 **The rules are a standing budget, not a place to explain things.** Every unscoped file under `<harness>/rules/` is preloaded into every request on a harness that reads them, so a line added there is paid continuously rather than once. `TestRulesStayShortEnoughToBePreloaded` caps a rule at 55 lines (three predate the budget and are capped where they stand; they may shrink, never grow), and `TestScaffoldedEntryFileStaysShort` caps the entry file at 60. A scoped rule is capped on its prose, not on the `paths:` header that took it out of the preloaded set.
 
+**On Claude Code there are no command files, and the `scc-` prefix is on the skill.** Claude Code registers a skill as `/<name>` by itself and its own documentation now says commands and skills are one mechanism, so `commands/scc-wiki.md` beside `skills/scc-wiki/` was a second entry point in the picker for one thing and a second preloaded `description` — ~980 characters of saying twice what the skill says once. `paths.Harness.SkillsAreCommands` is the capability; opencode still gets command files because nothing there turns a skill into one, and Codex still gets none because its prompts are user-global. **The rename is what makes the removal safe rather than a second collision**: with no command file the skill's own name is what the user types, and `/init` is a command Claude Code already ships — the review agents' collision one version earlier, arriving by the same door. Every `/scc-init` already written keeps resolving. What the command bodies carried and the skills did not is the *default job* — for five of them, "run `scc validate` and clear this artifact's findings" — and that moved into the skill bodies, where the run that invokes it pays for it.
+
 **A skill's description is on that same budget and its body is not.** The harness loads every `description` at session start to decide when to invoke the skill, and leaves the body until it does — so the body is paid once by the run that needed it, and the description by every request whether the skill runs or not. Eight of them had grown to 4087 characters, mostly enumerating findings `scc validate` already names by rule; `TestSkillDescriptionsStayShortEnoughToPreload` caps one at 340 and the set at 2400. The body is where the detail belongs, on exactly the reasoning that sends a rule's detail into a `--help` string. When a feature does not fit, the answer is to move the detail into a `--help` string — read only when consulted — and keep the question→command table in the rule. The plan-format change was measured in and out on this basis: it landed at +2 lines and +709 bytes across `entry.md` + `artifacts.md` + `tasks.md`, against ~14k tokens saved per plan reread.
 
 **A command that edits an artifact verifies it afterwards.** `scc patch` snapshots the file, writes, re-runs the validator that owns it, and restores the snapshot if the edit introduced a finding the file did not already have. Two details are load-bearing: the comparison is on `rule + message` and deliberately **not on line number**, because an insertion moves every finding below it and comparing on line would blame this edit for the whole tail of a pre-existing problem; and an artifact scc has no validator for is written and *reported as unverified* rather than silently claimed clean.