Rekdan
Try Rekdan

Writing prompt · Built for Apollo

Turn a vague request into a good prompt

Rewrites what you asked into a prompt that can actually be answered, and names the things the model was silently guessing.

The prompt

Turn what I wrote into a prompt that can actually be answered well.

What I asked, or was about to ask:
[PASTE IT, EXACTLY AS YOU WROTE IT — DO NOT TIDY IT]

What I am actually trying to achieve: [THE REAL GOAL BEHIND THE REQUEST]
What I will do with the answer: [DECIDE SOMETHING, SEND IT, PUBLISH IT, LEARN FROM IT]
What a bad answer would look like: [IF YOU KNOW]

Produce four sections.

1. WHAT YOU WOULD HAVE HAD TO GUESS — the specific decisions my original wording left open: audience, length, format, tone, level of detail, what to do when information is missing, what "good" means here. This is the section I need most, because each guess is a way the answer comes back wrong for reasons I would not have been able to name.

2. WHAT ONLY I CAN SUPPLY — the facts, constraints, and context no model has. Ask me for them as a short list rather than inventing plausible values.

3. THE REWRITTEN PROMPT — ready to use, with [BRACKETED] gaps where section two applies. It should state the task, the constraints, the output shape, and what to do when something is unknown. Do not pad it with roleplay or flattery; "you are a world-class expert" changes nothing.

4. WHY THIS VERSION IS BETTER — two or three lines tied to specific changes, so I can write the next one myself.

Do not answer my original question. If my request was already clear, say so and stop rather than inflating it.
Try in Rekdan

Replace the outlined parts before running

  • [PASTE IT, EXACTLY AS YOU WROTE IT — DO NOT TIDY IT]
  • [THE REAL GOAL BEHIND THE REQUEST]
  • [DECIDE SOMETHING, SEND IT, PUBLISH IT, LEARN FROM IT]
  • [IF YOU KNOW]
  • [BRACKETED]

When to use this

Most disappointing answers are not a failure of the model, they are a question that could be answered forty different ways being answered one of them. "Write me a summary" leaves length, audience, what to keep, and what to do with uncertainty all undecided — the answer picks silently, and the result is fine, and not what you wanted, and you cannot say why.

Section one is the whole point: it lists the decisions your wording handed over. Reading them is usually the moment the problem becomes obvious, because two or three will be things you had a firm opinion about and never said. That is also why the section is more valuable than the rewritten prompt — it teaches you what your requests habitually leave out, and most people leave out the same two things every time.

Section two is the honest boundary. A better prompt cannot supply facts about your situation, and a model asked to be more specific without them will invent specifics. Being asked for them instead is the difference between a prompt that fits your case and one that reads well.

How to use it

  1. Paste your request exactly as you wrote it

    Tidying it first removes the vagueness that is the subject of the exercise. The messy original is the input.

  2. Say what you will do with the answer

    Something you will publish and something you will glance at need different prompts, and this is the single piece of context that most changes the rewrite.

  3. Fill in section two yourself

    These are the facts only you have. Letting a model fill them with plausible values is how you get a confident answer about a situation that is not yours.

  4. Read section one before using the prompt

    It is the part that transfers. Nobody wants to run a prompt-improver forever; after a few rounds you start writing the missing constraints in the first place.

Variations

The answer was disappointing — work out why

I asked something and the answer was not useful. Diagnose it.

What I asked: [PASTE]
What I got: [PASTE, OR SUMMARISE IT]
What I wanted instead: [DESCRIBE IT]

Produce:
1. WHICH PART OF THE MISS came from my prompt and which came from the model — say plainly if the request was clear and the answer was simply weak.
2. THE SPECIFIC AMBIGUITY that produced the gap between what I got and what I wanted, quoting my own words.
3. THE CORRECTED PROMPT.
4. WHETHER THIS IS EVEN THE RIGHT TASK to ask a model for — some things are not, and saying so is more useful than a better prompt.
Try this variation

Turn a prompt I use often into a reusable template

I keep typing variations of this. Make it a template.

What I usually ask: [PASTE TWO OR THREE OF YOUR ACTUAL VERSIONS]
What changes each time: [DETAIL]
What is always the same: [DETAIL]
Where it goes wrong when it goes wrong: [DETAIL]

Produce:
1. THE TEMPLATE, with [BRACKETED] slots for exactly the parts that vary and nothing else.
2. WHAT I HAD BEEN INCONSISTENT ABOUT across my versions — differences that were probably accidental.
3. THE INSTRUCTION THAT FIXES the failure I described.
4. WHEN NOT TO USE THIS TEMPLATE — the case it would handle badly.
Try this variation

Where it falls short

  • A longer prompt is not a better onePadding with personas, urgency, and flattery adds nothing and can crowd out the instruction that mattered. If the rewrite is three times the length and none of it is constraint, it got worse.
  • When the task itself is the problemSome requests cannot be answered well by any wording — they need a source, a calculation, or a person. A better prompt makes those failures more fluent, not more correct.
  • Over-constrainingSpecifying the output down to the sentence gets you exactly what you asked for and nothing you did not think of. Leave room where you actually want the answer to surprise you.

Related prompts