/reprompter-improve

name: reprompter-improve
description: |
  RePrompter Improve intent — turn a rough prompt into a scored, structured spec prompt (or an outcome-prose build brief when the ask is a whole product).
  Use when: "reprompt", "reprompt this", "clean up this prompt", "improve this prompt", "make my prompt better", "fix my prompt", "before /goal", "compile to workflow", "workflow preflight", or when the reprompter entry skill routes an Improve ask here.
  Don't use for simple Q&A, casual chat, or execution-only tasks.
  Outputs: XML/Markdown prompt with <success_criteria schema_version="1"> + before/after quality score table. Target score: >= 7/10.

RePrompter — Improve (Single prompt)

> Mode skill of the `reprompter` plugin. Entry/routing: `../reprompter/SKILL.md`. Output formats beyond paste (`/goal` card, `.workflow.js`, headless-relay delivery): `../reprompter-goal-workflow/SKILL.md`. Whole-product builds: `../reprompter-oneshot/SKILL.md`. Multi-agent: `../reprompter-team/SKILL.md`. `scripts/<name>` paths resolve to the bundled `../reprompter/scripts/<name>` (e.g. `../reprompter/scripts/outcome-record.js`). > > **Required reading:** `../reprompter/references/advanced-features.md` (context engineering, uncertainty handling, token budget, Flywheel, pattern library). The always-on rules in `../reprompter/SKILL.md` → "Core shared rules" (context check, uncertainty permission, WHAT not HOW) apply to every generated prompt. > Every template named below lives in `references/` next to this file. Content below is verbatim from root SKILL.md (lines 358-591, 1560-1606) except where marked _Moved_.

Intent: Improve (Single prompt)

Shape decision (specifiability router)

Before the template pick, decide the OUTPUT SHAPE from the interview:

**Default is spec-XML.** Only switch to outcome-prose on a STRONG whole-product signal, and when in doubt, stay spec-XML — a scored structured prompt is never the wrong answer for a coding task, and it is what "reprompt this" has always produced.

• **Spec-XML (default)** — any bounded change (bugfix, endpoint, refactor, a feature in named files), anything with an enumerable done-state, and anything ambiguous. Scored on the six dimensions, exactly as always.
• **Outcome-prose (only on a strong signal)** — the ask is to build a WHOLE product or artifact from near-zero (a whole app/game/site/deck), OR it names a real product as the quality bar for a from-scratch build ("build me X like Linear"). Then emit the One-Shot three-paragraph shape (`references/oneshot-template.md`), including its constraints sentence for load-bearing negatives ("never touch auth"). **Announce and offer the exit:** "This looks like a whole-product build — I'll write an autonomous build prompt; say 'spec' for the structured, scored version instead." The user's override always wins. Outcome-prose is not scored on the six dimensions. **This is the same artifact the Build intent produces** — an Improve ask that is really a whole-product build and the Build intent converge on one prose brief, deliberately; there is no separate Improve-only build shape to disambiguate.
• **Mixed asks** (a *bounded* change described with a reference, e.g. "add a settings page like Linear's to our app") are spec-XML: the reference informs the requirements, it does not trigger a from-scratch build. When genuinely unsure which one an ask is, ask one discriminator question — "a fresh build, or a change to something that exists?" — and default to spec-XML on a fresh session with no answer.

Process

1. **Receive raw input** 2. **Input guard** — if input is empty, a single word with no verb, or clearly not a task → ask the user to describe what they want to accomplish

• Reject examples: "hi", "thanks", "lol", "what's up", "good morning", random emoji-only input
• Accept examples: "fix login bug", "write API tests", "improve this prompt"

3. **Quick Mode gate** — under 20 words, single action, no complexity indicators → generate immediately. A quick-mode task is bounded by definition, so it is always spec-XML; the shape decision does not run on this path (there is nothing whole-product about a sub-20-word atomic task). 4. **Smart Interview** — use `AskUserQuestion` with clickable options (2-5 questions max) for interactive Single mode. For prompts destined for autonomous execution (goal/workflow/team lanes), skip questions with reasonable defaults and emit an `<assumptions>` block the user can veto before running. 5. **Flywheel bias check (optional, read-only)** — if `REPROMPTER_FLYWHEEL_BIAS=1` is set in the environment, consult past outcomes before choosing a template. See "Flywheel bias injection" below. 6. **Generate + Score** — **if the shape decision above chose outcome-prose, skip this step's scoring**: emit the One-Shot prose brief (`references/oneshot-template.md`) and stop — outcome-prose is not scored on the six dimensions. Otherwise (spec-XML) apply the template and show before/after quality metrics. Generated prompts include a `<success_criteria schema_version="1">` block with 3-6 `<criterion>` entries. Each criterion has `id` (kebab-case slug, unique in block), `verification_method` (`rule` | `llm_judge` | `manual`), a one-sentence `<description>`, and — depending on method — an inline `<rule type="regex|predicate">` or `<judge_prompt>` (neither for `manual`). Schema of record: `references/outcome-schema.md`. 7. **Single-pass evaluator** — run self-eval rubric and do one delta rewrite if score < 7

**Why criteria are emitted:** so every prompt carries its own testable assertions; outcome records produced by `scripts/outcome-record.js` (added in the same PR) join criteria to results for flywheel learning.

Flywheel bias injection (v3 read-path)

_Moved:_ the full rules for step 5 (flywheel bias injection and attribution) and **Fleet sync (v12.14 privacy boundary)** are in `references/flywheel-bias.md`. Default is off (`REPROMPTER_FLYWHEEL_BIAS=1` enables it); only bias on `confiden