aytuncyildizli/reprompter/reprompter-improve

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 360-594, 1574-1620) 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.
• Design-loop prose (a page judged by how it looks) — the ask is how a page looks: a redesign, a landing page, the visual layer of a dashboard. Emit references/design-loop-template.md instead of spec-XML, because a design pass needs a direction and a critic, not a spec to satisfy. Like outcome-prose, it is not scored on the six dimensions.

Precedence: the prose shapes are exempt from every spec-XML rule in this file. One-Shot outcome-prose and the design loop take no base tags, none of the template fields, no <success_criteria> block, no score, no evaluator loop, no flywheel template override, and no /goal or workflow compilation. Wherever another section says "all templates", "every prompt", "always" or "both modes" about structure or scoring, it means every spec-XML prompt.

• 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"

1. 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).
2. 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.
3. 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.
4. Generate + Score — if the shape decision above chose outcome-prose or the design loop, skip this step's scoring: emit the One-Shot prose brief (references/oneshot-template.md) or the design-loop prompt (references/design-loop-template.md) and stop. Neither prose shape is 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.
5. 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 confidence ∈ {"medium", "high"} AND sampleCount >= 3.

Generate after interview

After interview completes, immediately:

1. Select template based on task type
2. Generate the full polished prompt
3. Show quality score (before/after table) for spec-XML. Outcome-prose and design-loop prompts are delivered unscored.
4. Ask if user wants to execute or copy

❌ WRONG: Ask interview questions → stop
✅ RIGHT: Ask interview questions → generate prompt → show score → offer to execute

Interview questions

Ask via AskUserQuestion. Max 5 questions total.

Standard questions (priority order — drop lower ones if task-specific questions are needed):

1. Task type: Build Feature / Fix Bug / Refactor / Write Tests / API Work / UI / Design loop / Security / Docs / Content / Research / Multi-Agent

• If user selects Multi-Agent while currently in Single mode, immediately transition to Repromptverse Phase 1 (Team Plan) and confirm team execution mode (Parallel vs Sequential).

1. Execution mode: Single Agent / Team (Parallel) / Team (Sequential) / Let RePrompter decide
2. Motivation: User-facing / Internal tooling / Bug fix / Exploration / Skip (drop first if space needed)
3. Output format: XML Tags / Markdown / Plain Text / JSON (drop first if space needed)

Task-specific questions (required for compound prompts — replace lower-priority standard questions):

• Extract keywords from prompt → generate relevant follow-up options
• Example: prompt mentions "telegram" → ask about alert type, interactivity, delivery
• Vague prompt fallback: if input has no extractable keywords (e.g., "make it better"), ask open-ended: "What are you working on?" and "What's the goal?" before proceeding

Single mode pattern pack (Microsoft-inspired)

Apply these patterns to spec-XML output, even without multi-agent execution. The prose shapes (One-Shot outcome-prose and the design loop) skip the spec contract and the evaluator loop.

1. Intent router — map task to template with explicit priority rules
2. Constraint normalizer — convert vague goals into measurable requirements/limits
3. Spec contract — enforce role/context/task/requirements/constraints/output/success structure
4. Evaluator loop — score clarity/specificity/structure/constraints/verifiability/decomposition; if score < 7, produce one delta rewrite

This keeps Single mode deterministic and compatible across Claude, OpenClaw, and Codex runtimes.

Auto-detect complexity

Quick mode

⚠️ Force interview signals (check first)

If ANY of the following signals are present, SKIP Quick Mode and go directly to interview — no exceptions:

Clause detection: Treat any prompt with two or more independent clauses (comma-separated actions, semicolon-joined tasks, or consecutive imperative verbs) as a compound task — force interview.

Broad-scope noun enforcement (`count_distinct_systems()`): Count the number of distinct systems/modules implied by broad-scope nouns (system, module, suite, platform, pipeline, dashboard, management). If count >= 1 AND the prompt does not name a single, specific identifier — force interview.

Enable Quick Mode (only when NO force-interview signals are present)

Enable when ALL true:

• < 20 words (excluding code blocks)
• Exactly 1 action verb from: add, fix, remove, rename, move, delete, update, create
• Single target (one specific, named file, component, or identifier — NOT a broad-scope noun such as system, module, suite, or management)
• No conjunctions (and, or, plus, also)
• No vague modifiers (better, improved, some, maybe, kind of)

Task types & templates

Detect task type from input. Each type has a dedicated template in references/: