Imported from AytuncYildizli/reprompter (SKILL.md). Install upstream with npx skills add AytuncYildizli/reprompter. Copyright stays with the author.

RePrompter v13.1.0

Your prompt sucks. Let's fix that. Two intents — improve my prompt, or build this whole thing — with /goal, Workflow, team execution and cross-model delivery as places the result can go. v13 (RePrompter v2) restructures six lanes into two intents: a specifiability router picks spec-XML or an autonomous build prompt inside Improve, and Build can run as one prompt or split across a team. Every v12 trigger keeps working.

Two intents

Users learn two sentences. Everything else is machinery underneath them.

Output formats (Improve): these apply to spec-XML results only — an outcome-prose build brief is delivered as-is (it must not be compressed to /goal or compiled to a workflow, which would discard its staffing plan and checklist). paste (default) · compress to a /goal <objective> command (Codex CLI, Claude Code v2.1.139+, Hermes) · compile to a runnable .workflow.js (Claude Workflow tool) · deliver to another model via headless-relay (post-output step). The /goal and Workflow sections below define these formats; their triggers ("before /goal", "workflow preflight", "compile to workflow", "dynamic workflow", ...) jump straight to Improve with that format.

Team execution (Build and beyond): "repromptverse", "reprompter teams", "smart run", "smart agents", "run with quality" and the swarm triggers route to the Repromptverse machinery below — either standalone as today, or seeded by a Build brief.

Advanced: Reverse mode (extract the prompt DNA from a great output — "reverse reprompt", "prompt dna") keeps working exactly as before and feeds the flywheel; it lives in its own section below.

Specifiability rule (Improve): when the router picks outcome-prose, announce it in one line — "This looks like a whole-product ask — generating an autonomous build prompt; say 'spec' for the structured version." — and switch shapes if the user objects. Outcome-prose always keeps a constraints sentence (the home for "never touch auth"); it is not scored on the six dimensions.

Auto-detection: if task mentions 2+ systems, "audit", or "parallel" → ask: "This looks like a multi-agent task. Want to use Repromptverse mode?"

Definition — 2+ systems means at least two distinct technical domains that can be worked independently. Examples: frontend + backend, API + database, mobile app + backend, infrastructure + application code, security audit + cost audit.

Don't use when

• User wants a simple direct answer (no prompt generation needed)
• User wants casual chat/conversation
• Task is immediate execution-only with no reprompting step
• Scope does not involve prompt design, structure, or orchestration

Clarification: RePrompter does support code-related tasks (feature, bugfix, API, refactor) by generating better prompts. It does not directly apply code changes in Single mode. Direct code execution belongs to coding-agent unless Repromptverse execution mode is explicitly requested.

Format: /goal command (Improve output)

When the user mentions /goal, before /goal, for /goal, "Codex /goal", "Claude Code /goal", "Hermes /goal", or asks to improve a goal prompt, run RePrompter before the goal is submitted.

This lane works on Codex CLI (any version exposing the goals feature), Claude Code CLI v2.1.139+ (the release that shipped a native /goal slash command on 2026-05-11), and Hermes Agent (persistent goals documented in the v0.13.0 / 2026.5.7 release). These runtimes accept the same /goal <objective> shape, so the compression flow is identical; only the setup check and a few runtime-specific operational notes differ. If the target runtime is Claude surfaces without /goal support, OpenClaw, Grok CLI, Gemini, or another LLM, use Improve (spec-XML) or Repromptverse instead; do not emit a /goal command for runtimes that have no /goal surface.

Detecting the target runtime

Pick the runtime once, at the start of the lane, and pass it through to the Card:

Process:

1. Treat the input as Single prompt mode unless it clearly needs Repromptverse.
2. Detect the target runtime (table above). Carry the runtime label through the rest of the lane.
3. Render the Goal Command Card first, with Runtime populated from step 2.
4. Infer the user's real intent from the rough prompt: desired outcome, hidden constraint, success signal, and likely risk.
5. Build the rich expanded prompt first, using the normal RePrompter structure: goal/task, context, assumptions, requirements, constraints, execution notes, and success criteria.
6. Compress that expanded prompt into a dense one-line goal summary. This should feel like a summary of a long XML prompt, not a slightly polished copy of the user's rough sentence. The compression rule is identical across runtimes — both Codex's alpha /goal and Claude Code's v2.1.139+ /goal consume <objective> as a single argument.
7. Generate an exact copy-paste command: /goal <summary of expanded prompt>.
8. Do not put the full XML or Markdown document after /goal; only the compressed summary belongs in the command.
9. Include the expanded prompt basis after the command so the user can inspect what was compressed or send it as a follow-up normal message after the goal is set.
10. Tell the user to run the exact /goal <summary of expanded prompt> command in the runtime chosen at step 2.
11. Do not claim RePrompter can automatically intercept /goal; slash commands are user-invoked in both Codex and Claude Code unless the local runtime adds a separate hook.

Goal Command Card

Both runtimes shape the slash command as /goal <objective>. Render this card before the generated command:

Then output:

/goal {dense single-line summary of the expanded prompt}

Then show the expanded prompt basis:

<goal>{specific outcome}</goal>
<context>
- {known repo/runtime/user context}
</context>
<assumptions>
- {reasonable default applied because this autonomous goal should not block on a low-value question}
</assumptions>
<requirements>
- {measurable requirement}
</requirements>
<constraints>
- {boundary or non-goal}
</constraints>
<execution_notes>
- Start with discovery before edits.
- Keep changes scoped and reversible.
- Run the verification checks listed in the Goal Command Card.
</execution_notes>
<success_criteria schema_version="1">
  <criterion id="{kebab-case-id}" verification_method="manual">
    <description>{testable pass condition}</description>
  </criterion>
</success_criteria>

Runtime-specific operational notes

The compression flow is shared, but the two /goal surfaces have small behavioral differences worth surfacing in the expanded prompt's <execution_notes> block:

Claude Code CLI (≥ v2.1.139):

• /goal sets a thread-level persistent objective that survives /resume, terminal close, and context compaction. Only one goal per session — setting a new /goal replaces the previous one.
• After each turn a separate fast evaluator model (Haiku) checks the completion condition against the transcript. If not met, the runtime triggers another turn without user input.
• The evaluator only judges what Claude surfaces in the transcript, so the expanded prompt should require the agent to print artifact paths, file contents, or test results — proof must be visible.
• Pause / resume controls: /goal pause and /goal resume (handy for long-running goals interrupted by ad-hoc work).
• Optional budget constraints (token or wall-clock) prevent runaway costs.
• /goal requires hooks. When disableAllHooks or allowManagedHooksOnly is set in settings.json, /goal is unavailable. v2.1.139 silently hung in this case; v2.1.140 changed the failure mode to a clear error message but did not make /goal work under those settings. If you operate in a managed environment that blocks hooks, the /goal preflight lane cannot run on Claude Code until hooks are permitted — use Single mode in that case.

Codex CLI:

• /goal is an experimental alpha feature gated by features.goals = true in ~/.codex/config.toml. The local alpha binary exposes Usage: /goal <objective>, ThreadGoal.objective, tokenBudget, /goal pause, /goal resume, and /goal clear.
• Codex's /goal is invoked the same way (/goal <objective>), but config-gated — a fresh session is required after enabling.

Hermes Agent:

• /goal sets a persistent objective that continues across turns until the runtime's goal judge considers it complete, the user pauses/clears it, or the configured turn budget is reached.
• Goal state survives /resume, and user messages preempt the continuation loop.
• Useful controls: /goal status, /goal pause, /goal resume, and /goal clear.
• Default continuation budget is bounded (goals.max_turns, documented default 20), so the expanded prompt should make success criteria and verification visible.
• Hermes supports /goal in both CLI and messaging-command surfaces; RePrompter still only emits the copy-paste command and does not intercept slash commands.

The Card's Risk Level and Verification fields apply equally to all supported /goal runtimes.

Setup check

Pick the block matching the detected runtime.

Codex CLI:

npm install -g @openai/codex@latest
codex features list | grep '^goals'

If the feature exists but is disabled, configure:

[features]
goals = true

Then start a fresh Codex session so the slash-command surface reloads.

Claude Code CLI:

claude --version
# Expect "2.1.139" or later. If older, upgrade:
#   curl -sL https://claude.ai/install.sh | bash
# or follow the install path you used originally.

No config flag is required — /goal is enabled by default once Claude Code is at v2.1.139 or later. However, /goal depends on Claude Code's hooks layer: if disableAllHooks or allowManagedHooksOnly is set in ~/.claude/settings.json, the command is unavailable on any version. v2.1.139 silently hung in that case; v2.1.140 surfaces a clear error message instead. Upgrading does not re-enable /goal under hook-blocking settings — permitting hooks is the only way to use /goal on Claude Code. Managed environments that block hooks should use Single mode for goal-shaped work.

Hermes Agent:

hermes --version
# Expect a release with persistent goals support (v0.13.0 / 2026.5.7 or later).

No feature flag is required for normal /goal use. Optional tuning lives in Hermes config:

[goals]
max_turns = 20

Format: Workflow script (Improve output)

When the user says "compile to workflow", "build a workflow script", "workflow preflight", "make a workflow", "run via workflow tool", or "dynamic workflow", reprompt the task and compile it into a runnable Claude dynamic Workflow script. This is the execution-compilation sibling of the /goal preflight lane: RePrompter builds the expanded prompt first, then emits a .workflow.js the user runs via the Workflow tool — RePrompter does not run it.

This lane is the same surface as Repromptverse Option H; use this lane when the user wants the compiled script directly, and Option H when Phase 3 auto-picks the Workflow tool during a Repromptverse run.

Compatibility

Single Claude-native surface: requires the Workflow tool in the current toolset. There is no /goal-style command — the output is a Workflow({ scriptPath, args }) invocation. Other runtimes (Codex, Grok, Hermes, OpenClaw) use their own Repromptverse options (D/F/G/C) and the /goal preflight lane instead.

Runtime detection

Process

1. Treat the input as a team task. Run routeIntent — a workflow-lane trigger returns mode: "workflow".
2. Infer the real intent and build the rich expanded prompt (the XML basis below) with all eight base tags + <assumptions> + <success_criteria>. Because Workflow preflight is autonomous execution, skip clarification questions when a reasonable default exists and document the default in <assumptions>.
3. Reprompt one prompt per role (each owns ONE domain, no overlap), exactly as Repromptverse Phase 2.
4. Compile to a .workflow.js via scripts/workflow-command.js (buildWorkflowCommand): pure-literal meta, schema-validated agent() returns, parallel()/pipeline() per the H1/H2 heuristic, runId/taskname from args, model omitted, filter(Boolean), bounded delta-retry (max 2/role).
5. Render the Workflow Command Card first, then the emitted script, then the expanded-prompt basis.
6. High-risk forbidden surfaces (prod/auth/secret/...) block emission — set blocked: true, script: null. There is no in-tool override; rescope the task (remove the high-risk surface) to compile a script. Same block-gate as /goal.
7. Tell the user to run Workflow({ scriptPath, args }); resume an interrupted run with resumeFromRunId (cached agent() prefix short-circuits).

Workflow Command Card

Then output the emitted script:

export const meta = {
  name: "rpt-{taskname}",
  description: "{one-line objective}",
  phases: [
    { title: "Plan" },
    { title: "Execute" },
    { title: "Evaluate" },
  ],
}

const taskname = (args && args.taskname) || "{taskname}"   // bare fallback == command args; only meta.name is prefixed (resume id stability)
const runId = (args && args.runId) || taskname

const FINDINGS_SCHEMA = {
  type: "object",
  additionalProperties: false,
  required: ["role", "findings", "self_score"],
  properties: {
    role: { type: "string" },
    findings: { type: "array", items: { type: "string" } },
    self_score: { type: "integer", minimum: 1, maximum: 10 },
  },
}

const AGENTS = [ /* one reprompted prompt per role; model omitted */ ]

phase("Plan")
log(`Workflow ${runId}: dispatching ${AGENTS.length} reprompted agents`)

phase("Execute")
const results = (await parallel(
  AGENTS.map((a) => () => agent(a.prompt, { label: a.label, phase: "Execute", schema: FINDINGS_SCHEMA }))
)).filter(Boolean)

phase("Evaluate")
const ACCEPT = 8
const final = []
for (const r of results) {
  let current = r, attempts = 0
  while (current && current.self_score < ACCEPT && attempts < 2) {
    attempts += 1
    current = await agent(`Previous ${current.role} attempt scored ${current.self_score}/10 (need ${ACCEPT}). Fix the gaps; return the improved structured result.`,
      { label: `retry:${current.role}`, phase: "Evaluate", schema: FINDINGS_SCHEMA })
  }
  if (current) final.push(current)
}

return {
  schema_version: "reprompter.workflow_outcome.v1",
  runId, taskname,
  results: final,
  missing: AGENTS.length - final.length,
  scores: final.map((f) => ({ role: f.role, score: f.self_score })),
}

Then the expanded-prompt basis (the reprompted XML that authors the workflow):

<role>{Workflow architect for this domain}</role>
<context>
- Raw operator request, target = Claude dynamic Workflow tool, route mode/profile
</context>
<assumptions>
- {Documented default used instead of blocking workflow compilation on a low-value question}
</assumptions>
<task>{Compile the request into a runnable .workflow.js fan-out.}</task>
<motivation>{Why this matters}</motivation>
<requirements>
- One reprompted agent per role; schema returns are the source of truth.
- meta pure-literal; runId/taskname from args; bounded retry.
</requirements>
<constraints>
- No wall-clock/randomness in-script; model omitted; filter(Boolean).
- High-risk forbidden surfaces block emission (no in-tool override; rescope to proceed).
</constraints>
<output_format>A .workflow.js script + a Workflow Command Card.</output_format>
<success_criteria schema_version="1">
  <criterion id="schema-returns-source-of-truth" verification_method="manual">
    <description>In-run data flows through schema-validated agent() returns; tmp files are never read back as a handoff.</description>
  </criterion>
</success_criteria>

Schema-truth + parent-written mirror

The emitted script returns a reprompter.workflow_outcome.v1 payload; it never reads /tmp/rpt-{taskname}-{role}.md back. The parent writes those tmp artifacts from the returned objects after the run completes, so the existing Status Line count, Phase-4 evaluation, and outcome-record.js --role flywheel path keep working unchanged — and the throwing wall-clock/randomness calls stay out of the sandbox.

Setup check

Confirm the Workflow tool is present in the current toolset (Claude dynamic Workflow runtime). If absent, use Repromptverse Option B/A or the /goal preflight lane instead.

Compile with the workflow compiler (scripts/workflow-command.js) on the rough task with an --out-dir: it writes workflow-command.json, the runnable rpt-{taskname}.workflow.js, workflow-command-card.json, and reprompter-expanded-prompt.md. Add --ultracode / --no-ultracode to force the emission tier.

See references/workflow-template.md and references/runtime/claude-workflow-runtime.md for the full template and runtime contract.

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)

Default: off. Enable explicitly with REPROMPTER_FLYWHEEL_BIAS=1 so runs with and without bias can be compared apples-to-apples until it earns the default.

When the flag is set, between the interview and the template pick:

1. Run npm run flywheel:query -- --task-type <slug> where <slug> is the task type identified from the interview (e.g. fix_bug, write_code).
2. Read the command's stdout. It's either null (cold start / low N) or a single JSON object with recipe, confidence, sampleCount.
3. Only bias on confidence ∈ {"medium", "high"} AND sampleCount >= 3. Low-confidence recommendations add noise without signal; treat them as cold start.
4. When biasing:
   • Prefer recipe.vector.templateId over the default intent-routed template.
   • Adopt recipe.vector.patterns alongside anything you would have picked from references/patterns/.
   • Match recipe.vector.capabilityTier in your reasoning about downstream execution.
5. Announce the decision in one line before the generate step so the user sees what happened:

   Flywheel: preferring <template> + [patterns] based on N past runs (score X/10, confidence) Or, if no bias applied: Flywheel: no bias (cold start / low confidence)

6. The bias changes which template/patterns you start from. The rest of the pipeline (interview content, generated prompt's XML structure, criteria emission) is unchanged. The flywheel never rewrites Claude's output.
7. Attribution (v3 part 3). When bias is applied, remember the chosen recipe's hash, confidence, and sampleCount until the outcome is recorded for this run. Then stamp them onto the record via scripts/outcome-record.js --applied-recommendation '{"recipe_hash":"<hash>","confidence":"<low|medium|high>","sample_count":<N>,"applied_at":"prompt_gen"}'. Use applied_at="phase_2" for Repromptverse team-wide bias. If no bias was applied (flag off, query returned null, or low confidence) OMIT the flag entirely — the absence of applied_recommendation on a record is what marks it as the bias-off control group for npm run flywheel:ab analysis. Never stamp a zero/placeholder block; absence is the signal.

Fleet sync (v12.14 privacy boundary)

Fleet sync shares only sanitized aggregate ledger rows from .reprompter/flywheel/outcomes.ndjson. It never reads .reprompter/outcomes/, and a pack contains no prompt text, no raw prompt hashes, no raw task slugs, no raw role/domain labels outside the coarse allowlist, and no hostnames.

npm run flywheel:export -- --origin o-laptop
npm run flywheel:import -- .reprompter/flywheel/packs/o-laptop-20260703.ndjson

Exported rows deterministically hash runId/taskId, coarsen non-allowlisted recipe.vector.domain labels, and recompute the recipe fingerprint from the sanitized vector. Identical sanitized recipes from different machines still group together in flywheel:query/flywheel:report, but raw prompt fingerprints and local task labels do not leave the machine.

Transport is user-owned: put packs in a shared directory, rsync them, or move them through your own git/Tailscale/mesh workflow. RePrompter itself does not network for fleet sync. The default flywheel cap remains 500 rows; active fleets can opt into a larger local ledger with REPROMPTER_FLYWHEEL_MAX_OUTCOMES=5000.

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)
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 / 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).
2. Execution mode: Single Agent / Team (Parallel) / Team (Sequential) / Let RePrompter decide
3. Motivation: User-facing / Internal tooling / Bug fix / Exploration / Skip (drop first if space needed)
4. 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 even without multi-agent execution:

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/:

Priority (most specific wins): marketing-swarm > engineering-swarm > ops-swarm > research-swarm > repromptverse > api > security > ui > testing > bugfix > refactor > content > docs > research > feature. For multi-agent tasks, use the best-fit swarm template + repromptverse-template + team-brief-template, then type-specific templates for each agent sub-prompt.

How it works: Read the matching template from references/{type}-template.md, then fill it with task-specific context. Templates are NOT loaded into context by default — only read on demand when generating a prompt. If the template file is not found, fall back to the Base XML Structure below.

To add a new task type: create references/{type}-template.md following the XML structure below, then add it to the table above.

Base XML structure

All templates follow this core section structure (8 required fields). XML is the default emitted format; Markdown headers are equally valid when requested by the user or runtime. Use as fallback if no specific template matches:

Exception: team-brief-template.md uses Markdown format for orchestration briefs. This is intentional — see template header for rationale.

<role>{Expert role matching task type and domain}</role>

<context>
- Working environment, frameworks, tools
- Available resources, current state
</context>

<task>{Clear, unambiguous single-sentence task}</task>

<motivation>{Why this matters — priority, impact}</motivation>

<requirements>
- {Specific, measurable requirement 1}
- {At least 3-5 requirements}
</requirements>

<constraints>
- {Load-bearing boundary or limit}
- {What to do instead of an unsafe or out-of-scope action}
</constraints>

<output_format>{Expected format, structure, length. If the target runtime supports structured-output APIs, name the shape here and enforce it through the API; embed full schemas only as fallback.}</output_format>

<success_criteria schema_version="1">
  <criterion id="no-regression" verification_method="rule">
    <description>Output does not reintroduce the original error signature.</description>
    <rule type="regex"><![CDATA[^(?!.*TypeError: cannot read property 'id' of undefined).*$]]></rule>
  </criterion>
  <criterion id="guards-null-user" verification_method="llm_judge">
    <description>Fix guards against the null-user edge case from the bug report.</description>
    <judge_prompt><![CDATA[Does the diff check that `user` is non-null before reading `user.id`? Reply pass or fail.]]></judge_prompt>
  </criterion>
  <criterion id="regression-test-added" verification_method="manual">
    <description>At least one regression test covers the previously failing scenario.</description>
  </criterion>
</success_criteria>

(The Base XML <success_criteria> example above matches the v1 schema in references/outcome-schema.md; real generated prompts should adapt the ids, descriptions, and rules to the task at hand.)

Project context detection

Auto-detect tech stack from current working directory ONLY:

• Scan package.json, tsconfig.json, prisma/schema.prisma, etc.
• Session-scoped — different directory = fresh context
• Opt out with "no context", "generic", or "manual context"
• Never scan parent directories or carry context between sessions

After the final prompt

Apply Deliver via headless-relay (post-output step): offer delivery once, only when that skill is installed; otherwise stay completely silent about it.

Team execution: Repromptverse (Agent Teams)

TL;DR

Raw task in → quality output out. Every agent gets a reprompted prompt.

Phase 1: Score raw prompt, dimension interview if needed, plan team, show Agent Cards (YOU do this, ~45s)
Phase 2: Write XML-structured prompt per agent (YOU do this, ~2min)
Phase 3: Launch agents (tmux, TeamCreate, Workflow tool, sessions_spawn, Codex, or sequential) (AUTOMATED)
Phase 4: Show Result Cards, score, retry if needed (YOU do this)

Key insight: The reprompt phase costs ZERO extra tokens — YOU write the prompts, not another AI.

Repromptverse control plane (Microsoft-inspired)

Every multi-agent run must include:

1. Routing policy — who speaks next and why (selector-style routing for non-trivial teams)
2. Termination policy — max turns, max wall time, and no-progress stop condition
3. Artifact contract — one writer per output file, fixed schema for handoffs
4. Evaluator loop — score each artifact, retry only with delta prompts (max 2 retries)

Use references/repromptverse-template.md to enforce this contract.

Domain profile auto-load rules (lazy-load, on demand):

• Marketing intent (campaign, launch, growth, seo, content calendar, funnel) -> references/marketing-swarm-template.md
• Engineering intent (architecture, feature delivery, refactor, migration, test coverage) -> references/engineering-swarm-template.md
• Ops intent (incident, uptime, gateway, latency, cron, slo, health) -> references/ops-swarm-template.md
• Research intent (benchmark, compare, tradeoff, analysis, research) -> references/research-swarm-template.md

Then merge with references/repromptverse-template.md for routing/termination/evaluation contract and add task-specific constraints.

Canonical implementation for deterministic routing lives in scripts/intent-router.js. If docs and code ever diverge, the script is the source of truth for benchmark/testing paths.

Phase 1: Team plan (~45 seconds)

1. Score raw prompt (1-10): Clarity, Specificity, Structure, Constraints, Decomposition
   • Phase 1 uses 5 quick-assessment dimensions. The full 6-dimension scoring (adding Verifiability) is used in Phase 4 evaluation.
2. Dimension Interview gate — check which askable dimensions scored < 5 (see Dimension Interview section below). In autonomous or batch-destined runs, prefer documented assumptions over blocking questions when a reasonable default exists.
3. Pick mode: parallel (independent agents) or sequential (pipeline with dependencies)
4. Define team: 2-5 agents max, each owns ONE domain, no overlap (informed by interviewContext if interview ran)
5. Show Plan Cards (see Agent Cards section below)
6. User confirmation gate — "Team plan ready. Proceed to execution?" User can approve, adjust, or cancel. In automated/batch runs, auto-proceed.
7. Write team brief to /tmp/rpt-brief-{taskname}.md (use unique tasknames to avoid collisions; includes interviewContext section if interview ran)

Dimension Interview (Repromptverse only)

Score-driven interview for Repromptverse mode. Distinct from Single mode's "Smart Interview" (which uses a standard question list). The Dimension Interview derives questions from low-scoring raw prompt dimensions.

Trigger logic

scores = score_raw_prompt(rawInput)  # 5 dimensions from step 1

# Structure is EXCLUDED — reprompter fixes structure via templates.
# Only 4 dimensions are interview-eligible:
askable = [d for d in scores if d.name != "Structure" and d.value <= 5]

# Threshold: less-than-or-equal. Scores of 5 ARE borderline and trigger questions.
if len(askable) == 0:
    SKIP interview → proceed to step 3 (pick mode)
elif len(askable) <= 2:
    ASK 1-2 questions (one per low dimension)
else:
    ASK 3-4 questions (max 4, prioritized by lowest score first)

Dimension-to-question mapping

Question rules:

• Use AskUserQuestion with clickable options (consistent with Single mode)
• Options are dynamic: extracted from prompt keywords + codebase context (config files + top-level dirs only — no deep analysis)
• Every question includes a free-text escape hatch option
• Priority order: lowest scoring dimension first
• Language follows user's input language

Skip/dismiss handling

• User skips all questions → proceed with empty interviewContext. Plan Cards note: "Interview: skipped by user"
• User answers some, skips others → populate only answered fields

Interview output (interviewContext)

Responses merge into an interviewContext written to the team brief file:

interviewContext = {
  scope: [from Specificity answer],
  excludes: [from Constraints answer],
  successCriteria: [from answers, or omitted — Phase 2 derives from requirements],
  taskClarification: [from Clarity answer, if asked]
}

When successCriteria is not gathered (question not asked or user skipped), omit the field. Phase 2 derives success criteria from requirements as it does today.

For autonomous execution lanes, record safe defaults in the generated prompt instead of asking low-value clarification questions:

<assumptions>
- Scope defaults to the files and systems named or strongly implied by the request.
- Excludes default to unrelated refactors, new dependencies, and destructive production changes.
- Verification defaults to the smallest local checks that prove the requested outcome.
</assumptions>

The user can veto or edit these assumptions before execution. Interactive Single mode still asks when ambiguity changes the requested outcome.

How interviewContext feeds into later phases:

• Agent count and roles — scope determines which agents are created
• Per-agent <constraints> — excludes injected into each agent's prompt
• Per-agent <success_criteria> — user expectations propagated
• Template selection — clarified task type may route to a different swarm profile

Precedence: Interview responses override auto-detected codebase context. Conflicts noted in Plan Cards.

Flywheel: interviewContext is excluded from recipe fingerprint hash. The fingerprint captures strategy (template + patterns + tier), not user scope answers.

Agent Cards (transparency layer)

Three fixed-format card types rendered at different phases. Templates are exact — do not invent new formats.

Plan Cards — rendered at end of Phase 1 (step 5)

After team plan is complete, before Phase 2 prompt writing. Use this exact table format:

## Team: {N} Opus Agents ({Parallel|Sequential})

| # | Agent | Scope | Excludes | Output |
|---|-------|-------|----------|--------|
| 1 | {role} | {scope} | {excludes or "-"} | {output path} |
| 2 | {role} | {scope} | {excludes or "-"} | {output path} |

Interview context applied: {summary of influence, including override conflicts, or "No interview (high-quality prompt)", or "Interview: skipped by user"}

Rules:

• Render before any agent is launched
• If interview ran, show which constraints came from interview vs auto-detected
• If user requests agent adjustments at confirmation gate, re-render Plan Cards with updated team
• Single-agent runs: table renders with one row (valid)

Status Line — rendered during Phase 3 polling

Compact one-line status with each poll cycle:

Agents: ✅ 2/4  ⏳ 1/4  🔄 1/4 (retry 1)

Emoji mapping: ✅ = completed, ⏳ = in-progress, 🔄 = retrying

Rules:

• Replace verbose poll output with this compact format
• Platform-dependent: TeamCreate uses TaskList status; tmux uses best-effort pane parsing; sequential is trivial
• Show retry count for retrying agents
• Each poll cycle MAY consult node scripts/run-supervisor.js --advise --run-id {runId} --json and fold its verdict into the Status Line. On stalled, follow the current Option's stall runbook; on failing-evals, begin drafting Phase-4 delta prompts early. The supervisor is advisory and read-only.

Result Cards — rendered at start of Phase 4

After reading all agent outputs, before synthesis. Use this exact table format:

## Results

| Agent | Score | Findings | Key Insight |
|-------|-------|----------|-------------|
| {role} | {score}/10 {pass/retry emoji} | {count} findings | {one-sentence top finding} |

Total: {N} findings | {accepted}/{total} accepted | {retry_count} retries

Rules:

• Render before synthesis is written
• "Key Insight" = single most important finding per agent (forces prioritization)
• Retry agents show retry reason in findings column

Token budget (Agent Cards + Dimension Interview)

Phase 2: Repromptverse prompt pack (~2 minutes)

Flywheel bias check (optional, read-only): Same rules as Mode 1 (see "Flywheel bias injection" in Mode 1). When REPROMPTER_FLYWHEEL_BIAS=1, run npm run flywheel:query -- --task-type <team-task-slug> once for the overall team task before per-agent adaptation. If confidence ∈ {"medium", "high"} with sampleCount >= 3, prefer the recommended templateId/patterns as the team-wide starting point; each agent still picks its own role-specific template on top. Announce the bias decision once at the start of Phase 2, not per agent, to keep the output readable. Per-role bias queries are a v3 follow-up once enough role-stamped records exist.

For EACH agent:

1. Pick the best-matching template from references/ (or use base XML structure)
2. Read it, then apply these per-agent adaptations:

• <role>: Specific expert title for THIS agent's domain
• <context>: Add exact file paths (verified with ls), what OTHER agents handle (boundary awareness)
• <requirements>: At least 5 specific, independently verifiable requirements
• <constraints>: Scope boundary with other agents, read-only vs write, file/directory boundaries
• <output_format>: Exact path /tmp/rpt-{taskname}-{agent-domain}.md, required sections
• <success_criteria>: use the v1 structured shape (same as Mode 1) — see references/outcome-schema.md. Include 3–6 <criterion> entries scoped to this agent's artifact (not the whole team's output). Each criterion has id, verification_method (rule | llm_judge | manual), a one-sentence <description>, and an inline <rule> or <judge_prompt> per the method. Bullet-list placeholders in the template files are acceptable scaffolding but the generated per-agent prompt upgrades them to the structured form.

Score each prompt — target 8+/10. If under 8, add more context/constraints.

Write all to /tmp/rpt-agent-prompts-{taskname}.md

Flywheel hook (per-agent): after Phase 3 execution, each agent's artifact at /tmp/rpt-{taskname}-{agent-domain}.md can be recorded separately with scripts/outcome-record.js --role <agent-name> (one record per agent, mode="repromptverse", and --role set to the teammate's name so the flywheel bridge uses it as the domain when building the recipe fingerprint). Score each record with scripts/evaluate-outcome.js. Without --role, all agents on the same task_type collapse into the same recipe bucket and the strategy learner can't tell which roles consistently win vs struggle — so always pass it for Repromptverse records.

Reprompt quality scorecard (mandatory)

After writing all agent prompts, show the before/after comparison so the user sees the improvement:

## Reprompt Quality

| Metric | Raw prompt | After reprompt | Change |
|--------|-----------|----------------|--------|
| Overall | {raw}/10 | {after}/10 | +{pct}% |
| Per-agent avg | - | {avg}/10 | - |
| Agents | - | {N} | - |

Raw prompt scored {raw}/10. After reprompting, each agent prompt scores {min}-{max}/10 (avg {avg}/10).

Rules:

• Render after Phase 2 prompt generation, before Phase 3 execution
• Shows the user exactly how much reprompter improved their input
• If any agent prompt scores < 8, note which ones and what was added to fix them

Phase 3: Execute

Phase 3 has platform-specific execution methods. The reprompted prompts from Phase 2 work with any method — you just need to pick which one to run. In most runs you should not ask the user; auto-pick below and announce the decision so they can redirect if they want. (One exception: Grok Option F inside a git repo — get the user's explicit consent first, per the data-egress consent gate under the table below.)

Status Line (all platforms): During polling, show compact agent status with each cycle. See Agent Cards section for format.

Runtime auto-pick (default behaviour — do this first)

If the user explicitly named an option in their request (e.g. "use tmux", "run it sequentially", "via sessions_spawn"), honour that and skip the detection. Otherwise run the decision tree below top-to-bottom and use the first option whose capability is available.

After picking, announce the selected option in one short line before starting Phase 3 work, so the user can redirect. Use this shape with the actual option and runtime you selected:

Auto-picked Option {letter} ({runtime}) — {short detection reason}. Override by saying "use Option B", "use Option H (Workflow)", "use Option A (tmux)", "use Option D", "use Option G (Hermes)", or "use Option E" (sequential).

⚠️ Grok Option F — data-egress consent gate (overrides the "don't ask" default above). Option F runs grok (F1 spawn_subagent / F2 grok -p) in the caller's working directory, handing the repo's contents to xAI as model context. Earlier Grok Build versions additionally bundled the entire tracked repo + full git history and uploaded it (confirmed incident; not stopped by --sandbox, --yolo, or a read-only profile); xAI turned that off server-side on 2026-07-13 and the path is gone from the 2026-07-15 open-sourced code, but the off-state is a reversible server flag and the shipped binary is unverifiable. So for Option F only, the "in most runs you should not ask the user" default does NOT apply: before launching F1 or F2 inside a git repo, warn the user once, get explicit consent, and offer to route the run to another runtime (or a non-git copy of just the needed files created outside any git repo — e.g. a fresh dir under /tmp, verified with git rev-parse --is-inside-work-tree returning non-zero; note that a .git-removed subdirectory of the project is still inside the parent work tree, and a clone/worktree is still a repo). Full detail and the required warning: the "Data egress" section of references/runtime/grok-cli-runtime.md.

Why F is first for Grok: when an unambiguous Grok signature is detected (spawn_subagent + at least two of the supporting tools), Repromptverse must use Grok-native execution (Option F) to honour the "full Grok runtime support" claim. This check is intentionally strict to prevent false positives on other runtimes. Option B (Claude native teams with cross-agent SendMessage) is preferred on Claude Code surfaces because it offers richer inter-agent messaging than Grok subagents currently provide. The rest of the priority order is unchanged.

Why G is next for Hermes: delegate_task is a Hermes-specific fork/join primitive. When that tool appears with Hermes' file, terminal, skills, or todo tools, Repromptverse should use the native Hermes path instead of falling through to OpenClaw, tmux, Codex, or sequential mode. Hermes workers receive fresh context, so the parent must pass the full per-agent prompt and artifact path in each task's context.

Why H sits just below B on Claude surfaces: both are Claude-native, but the dynamic Workflow tool has no mid-run cross-agent messaging — workers cannot talk; data flows only through pipeline()/parallel() return values. So Option B stays the default when teammates must negotiate during the run (review/audit teams), and Option H wins when you want deterministic background fan-out, schema-validated return handoffs, and resumable runs (the script's agent() prefix is cached on resumeFromRunId). Full contract in references/runtime/claude-workflow-runtime.md.

Tool-schema guard (all options)

Before invoking any tool named in Options A–H, verify it appears in your current toolset and that the call signature matches the schema loaded for the current runtime. Modern CLI runtimes reject calls against an unknown tool or a non-matching signature instead of inferring intent. If a named tool is unfamiliar, halt and report back rather than substituting a similar-looking one.

Known pitfalls captured from 4.6 → 4.7 drift in this skill:

• Task → Agent. The legacy spawn tool was named Task and took subagent_type as a keyword argument. It has been split into Agent(...) for spawn and TaskCreate / TaskUpdate / TaskList for todos. Any example still calling the old spawn name is broken under 4.7.
• SendMessage signature. Current shape is SendMessage(to=<name-or-"*">, message=<str-or-obj>). Legacy type= and recipient= kwargs do not exist on the current tool.
• Broadcast restriction. SendMessage(to="*", ...) accepts plain strings only. Structured payloads such as {"type": "shutdown_request"} must be sent per-agent by name; the runtime rejects structured broadcasts.
• TeamDelete ordering. TeamDelete() fails if any teammate is still active. Shutdown is async; in-process teammates need a turn yield to approve each shutdown_request before cleanup succeeds.
• TeamCreate precedence. Agent(team_name=...) errors if that team was not created first. Always call TeamCreate before any Agent with a team_name argument.

Canonical signatures Option B depends on. These are reference documentation, not a schema enforced by the validator. npm run validate:tool-refs is a blocklist — it catches known-bad shapes from this repo's history (obsolete tool names, reordered broadcast calls, hardcoded model pins) but does not positively verify that every call here matches its schema. If you change a signature below, update

*Truncated - read the full file at https://github.com/AytuncYildizli/reprompter/blob/f8c234032c9d73f7089a84018e81f9a1ef19831e/SKILL.md