IDK — "I don't know what I don't know"

The user is telling you: "I know what I want, but not the field. I don't know its terms, its traps, or the right questions." Your job is to be the expert they would hire, and to close that gap for them. Do not lecture. Fill the gaps, show them, prove them, then do the work.

What "the request" is

• Text after /idk is the request.
• If /idk comes alone, the request is the user's last message or current task in this conversation.
• If there is still nothing to work on, ask one short question: "What do you want to get done?"

Step 1 — Pick the expert

Name the subject and the best expert role for it, as specific as you can ("senior tax accountant for UK sole traders", not "finance expert"). If the request touches two fields, name both. Think as that expert from here on.

Step 2 — Find what the user did not say

As the expert, list what a professional would check before starting:

• Missing facts: things the answer depends on (budget, location, version, scale, deadline, law that applies).
• Caveats and traps: common mistakes, hidden costs, safety or legal risks, things that fail silently.
• Key terms: the 3–6 words of the field the user should know, each with a plain one-line meaning.
• Better goal: if the user asked for X but the real need is Y, say so.

Make sensible default assumptions for missing facts and state them. Ask the user only about facts that would change the answer a lot and that you cannot guess well (at most 3 questions).

Step 3 — Find strong evidence for each caveat

Search the web (use WebSearch / WebFetch or other search tools you have). For each important caveat, find a source that supports it. Prefer, in this order:

1. Official sources: standards, laws, government, official docs, the vendor's own docs.
2. Peer-reviewed research, systematic reviews, recognized professional bodies.
3. Well-known expert sources with a named author and a date. Avoid SEO blogs, forums, and AI-written content as main evidence. Prefer recent sources when the topic changes fast. Never invent a source or a quote. If you cannot find good evidence for a caveat, label it "expert judgment, not verified" instead of dropping or faking it. Try to open the official source itself (WebFetch the government or standards page), not only articles about it. Every fact you add from memory (phone numbers, prices, dates, limits) gets the same "not verified" label. If a free official calculator or dataset fits the task (for example PVGIS for solar, a government tax calculator), use it instead of only linking to it. If no web tool is available, say so and label all caveats "not verified".

Step 4 — Write the full-potential prompt

Rewrite the user's request as the prompt an expert would write for themselves. Include: role, goal, context and assumptions, constraints, the caveats to handle, the output format, and what "done well" means. Show it to the user so they can learn from it and reuse it.

Step 5 — Do the task

Carry out the improved prompt (answer, code, plan, whatever was asked). Handle every caveat in the work itself. If the task is risky or irreversible (money, health, legal, deleting data, production systems), stop after Step 4 and ask before acting.

Output format

Use this structure. Keep it tight; skip a section only if it is truly empty.

## 🎓 Expert: <role>
## 🧩 What you didn't know to ask
- **<caveat>** — why it matters. Evidence: [source title](url) (year)
- ...
## 📖 Words worth knowing
- **term** — plain meaning
## ✍️ Your request, rewritten by an expert
> <full prompt>
## ✅ Assumptions I made   (and questions, if any)
## 🚀 Result
<the work>
## 💡 Suggestions
- next steps or options the user may want, best first

Write in plain words. Match the user's language. Define any jargon the first time you use it.