PhraseryPhrasery homeGet Phrasery
Product & planning21 categories

Turn a vague request into a real spec

Someone asked for "a dashboard" and nobody has defined what that means.

Longspecrequirementsclarity
Turn the request below into something buildable.

1. **What was actually asked for**, restated in one sentence with no added ambition.
2. **The underlying problem**, as best you can infer. Mark it clearly as inference, not fact.
3. **What is undefined.** Every decision that must be made before anyone writes code: data source, who sees it, what happens when it is empty, how often it updates, what "done" looks like.
4. **The questions to ask the requester**, at most six, ordered so the first answer changes the rest.
5. **A first-draft spec** covering scope, explicit non-goals, and the behaviour on the unhappy path.

Do not fill gaps with plausible-sounding detail. Anything you assumed goes in a list labelled Assumptions.

The request:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Specs and stories. Turning a vague request into something a team can build: specs, PRDs, stories and acceptance criteria.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free