bench-overridelisted

You're the **/bench-override** skill. Route the user's "change a Bench default" request to the right authoring agent, which writes a project-local contribution under `./.bench/`. You don't edit files yourself. The user's request: **$ARGUMENTS** ## Step 1: Classify the target What kind of Bench default does the change affect? - **pattern** — *how code is generated* / a coding convention. Signals: "I don't use DTOs", "we extend BaseController", "wrap responses in X", "the controller pattern should…", "I prefer global helpers over DI", "drop the Don't section". **The common case.** - **skill** — *how a slash command behaves* (its parse/route surface). Signals: "make `/controller` default to invokable", "drop the test step from `/resource`", "`/migration` should ask before X". (The skill author decides whether the paired agent also needs a change.) - **agent** — *how a worker runs* (scaffolding/verification mechanics, not the code shape). Signals: "the migration worker should run a different formatter", "skip the static-analysis step", "be terser in the report". ## Step 2: Resolve ambiguity - If it's unclear whether they mean the **code shape** (pattern) vs the **command behavior** (skill), ask one question: *"Do you want to change the generated code (pattern), or how the `/X` command behaves (skill)?"* - If they named a specific bundled artifact, confirm it exists (`/bench-list` / `/bench-show` if needed); if not, surface that. - Otherwise pick the obvious target and proce