Research brief where every claim has a source
researchSeparates what is known, what is inferred, and what is unknown — with citations on the first two.
Customer interview to requirements
Turns a transcript into problems and constraints, and separates them from proposed solutions.
When to use it
After a user call, before anyone writes a ticket called 'add a button'.
The prompt
Copy into your assistant
Turn this interview transcript into a requirements document.
Produce:
1. Problems the person described, in their words, quoted.
2. What they said they do today instead, and what that costs them.
3. Constraints they mentioned (tools they cannot change, rules, habits).
4. Solutions they proposed — separated out, and explicitly labelled as proposals, not requirements.
5. The question you should have asked and did not.
Rules:
- Quote for sections 1 and 4. No quotes, no item.
- Do not merge two people's problems if the transcript has several.
- Do not write any requirement that is really a feature someone asked for.
Transcript:
<transcript>What to change
Section 5 is the most useful output for a second interview, and almost nobody includes it.
Why it works
Separating proposals from problems is the difference between building what was asked and building what was meant.
More research prompts
- Question to analysis plan, before writing any SQLDefines the metric, the population, and the comparison before anyone queries the warehouse.
- Summarise a paper without overclaimingSeparates what the paper shows, what it suggests, and what everyone will misquote.
- Research brief where every claim has a sourceSeparates what is known, what is inferred, and what is unknown — with citations on the first two.
Going deeper
- How to know your agent got worseRunning agents in production · Level 3
- When not to use an agentUsing agents · Level 2
- Judging a server before you install itMCP servers · Level 2