prompt-improver

name

prompt-improver

description

Diagnose and rewrite a draft prompt so a frontier model is engaged as a senior partner rather than a junior task-taker. Use when the user asks to improve, sharpen, review, fix, level-up, or rewrite a prompt; says things like "make this prompt better", "review my prompt", "is this a good prompt"; pastes a prompt and asks for feedback; or invokes `/prompt-improver`. Applies to prompts for heavy knowledge work (research, analysis, synthesis, strategy docs, PR FAQs, code planning) — not to short one-shot lookups or to agentic-pipeline prompts where strict structure and evals are the goal.

Prompt Improver

Rewrite a user's draft prompt as a senior-partner question, applying three principles.

Core mental shift

Frontier models work best when treated as a senior partner, not a junior teammate. The old pattern — define the task tightly, hand it over, evaluate the output — leaves leverage on the table. The better pattern is to ask layered questions that convey perspective, invite synthesis, and force engagement with real data.

Apply this skill only to heavy knowledge work. For agentic pipelines (ticket triage, invoice processing, deterministic flows), strict task-style prompts with evals are still correct — do not rewrite those.

Workflow

1. Read the draft prompt. If the user has not provided one, ask for it.
2. Diagnose against the checklist below. Name specific weaknesses, not generic advice.
3. Rewrite the prompt applying the three principles. Preserve the user's actual intent, files, and constraints — do not invent facts.
4. Output in the format below.

Diagnosis checklist

For each item, mark present / missing / weak:

• Senior-partner framing — Does it invite the model to think with the user, push back, propose a thesis? Or does it dictate a task to execute?
• Flashlight intent (Principle 1) — Is there a clear center of focus (the user's angle/thesis) and clear edges (what to include, what to exclude)?
• Synthesis surface (Principle 2) — Does it pose multiple open-ended questions the model must reconcile, or is it a single closed task that could be evaluated by a checklist?
• Data + opinion wrestle (Principle 3) — Are specific data artifacts named (files, transcripts, dashboards, PRDs)? Is the user's working hypothesis stated, with explicit permission to disagree?
• Common failure modes to call out when present:
  • Too open-ended ("help me with marketing")
  • Too closed ("write a 300-word summary of X")
  • No perspective (asks for neutral output, model defaults to bland mirroring)
  • No data anchors (model picks one source and dives, missing the rest)
  • Junior-partner framing ("do X then do Y then output Z")
  • Mirror trap (opinion stated so strongly the model will just agree — no invitation to push back)

The three principles (apply during rewrite)

1. Flashlight intent — center + edges

The prompt should read like a flashlight beam: a bright center showing where to focus, and a defined edge showing the boundary of relevance.

• Center: state the user's angle, thesis, or hunch. "My thesis is that our marketing attribution is broken because Google organic isn't bucketed correctly."
• Edges: name what's in scope and what to ignore. "The first 15 minutes of the meeting transcript covers a separate greenlight decision — exclude that."

2. What good looks like — multi-part open synthesis

Instead of one closed task, ask a series of harder open questions that force the model to synthesize across them.

Example shape (PR FAQ for a product launch):

• "How does this feature stay accessible for customers who haven't used 3D before — and how should we weave that into the press release?"
• "How do we convey the software/hardware interplay both emotionally in the press release and concretely in the internal FAQ?"

Each sub-question is hard enough that no checklist eval would capture a good answer.

3. Wrestle with data + opinions — name artifacts, invite pushback

• Name the data: list the specific inputs (PRDs, voice-of-customer transcripts, support tickets, dashboards, MRR analytics, meeting notes, code files). Vague pointers ("our data") cause the model to pick one source and dive.
• State a thesis tied to those artifacts: "I think product-led growth is broken — I see it in flat MRR for six months, dead-cat-bounce launches, and our own framing in the last three PRDs."
• Explicitly invite disagreement: "You don't have to agree with me. Come back with the cleanest, most explanatory thesis the data supports — even if it contradicts mine."

Output format

Respond with exactly two sections:

## Diagnosis
- [Specific weakness 1 — quote or paraphrase the offending part of the draft]
- [Specific weakness 2]
- [...]

## Improved Prompt
[The rewritten prompt — written in the user's voice as if they will paste it directly into a frontier model. Includes flashlight intent, named data artifacts, the user's thesis, multi-part open questions, and explicit invitation to push back.]

Keep diagnosis to 3–6 bullets. Keep the improved prompt as long as it needs to be — good senior-partner prompts are often long. Do not pad with meta-commentary about the rewrite.

Edge cases

• Draft is already strong — Say so. Suggest at most one targeted sharpening rather than a full rewrite.
• Draft is for an agentic pipeline (deterministic, repeated, evaluated by metrics) — Do not apply this skill. Tell the user this prompt style is for one-shot heavy knowledge work; agentic pipelines need tight task framing and evals instead.
• User has not shared the data they reference — Do not fabricate file names or metrics. Use placeholders like [attach: voice-of-customer transcripts] and flag them in the diagnosis so the user fills them in before sending.
• User's stated thesis is missing — Ask one question: "What's your current hunch on this — even a rough one? The rewrite needs an angle to anchor on." Do not invent a thesis for them.