LULUSKILL ARTICLE

From a vague idea to a prompt you can use

Five questions that turn "I want an app for…" into a written brief an assistant can work from, with one rewrite shown step by step.

Written by LuluSkill — first-party content for this site

About 10 minutes to read

Published 2026-09-23 · Updated 2026-10-04

What this article is, and is not

This is LuluSkill's own writing. It does not quote, mirror or summarise any third-party Skill, and it recommends none. Reading it builds, publishes and runs nothing: what an AI tool does with your text is for you to check.

Why a vague idea comes back as a vague result

Most first requests are a label rather than a description: "a booking app", "a site for my shop", "something to track expenses". A label is enough for a person who already shares your context. For an assistant that only sees the words, it is an invitation to guess, and every guess it makes is a decision you did not get to make.

The guesses are not random. They drift toward the most common version of whatever the label names. Ask for "a booking app" and you tend to receive a generic calendar with accounts, payments and notifications — far more than a hairdresser with one chair needs, and still missing the one rule that matters to them, such as "no bookings on Mondays".

So the work of writing a prompt is not finding clever wording. It is replacing each guess with a decision you have written down. The rest of this article is a way to find those decisions in a sensible order.

Three parts of every useful brief

In plain words

Goal: What someone can do once the thing exists, said in one sentence about a person and an outcome — not a list of features.
Constraint: Anything that must be true or must not happen: a budget, a language, a device, a rule of your business, something that must stay private.
Acceptance check: The concrete test you will run yourself to decide whether the result is good enough to keep. If you cannot describe the check, the goal is not finished yet.

Five questions that turn an idea into a brief

Answer these in order, in plain sentences, before you open any AI tool. Short answers are fine. A blank answer is also useful: it tells you exactly which decision you are about to hand to a guess.

Answer them in this order

Who is it for? Name one real kind of person — "parents in my child's class", not "users". If there are two kinds of people with different needs, write down which one comes first.
What do they do with it? Describe the single most important thing that person does, from the moment they arrive to the moment they are finished.
What does "done" look like to them? Describe what they see or receive at the end: a confirmation, a list, a file, a message to someone else.
What is out of scope for now? List at least two things you are deliberately not asking for. This is the answer beginners skip most often, and the one that keeps a first version small.
How will you check it? Write the test you will run yourself: "I can add three names on my phone and see them on my laptop", not "it works well".

Useful additions once the five are answered

The language or languages the result must use, including for error messages.
The device your people actually use — often a phone, which changes the layout more than any feature does.
Anything that must stay private, and who is allowed to see it.
What you already have: a spreadsheet, a logo, a written price list. Describe it; do not paste secrets or other people's personal details.

One idea, rewritten step by step

The example below is invented for this article. It follows one person through the five questions so you can see what each answer adds. It is illustration, not a template to copy: your answers will be about your situation.

A volunteer rota for a small food bank

Example

The starting point is one line: "Make me an app for our volunteers."

Who: the coordinator asks first, and realises the people who matter most are the twenty regular volunteers, not the coordinator.
What they do: a volunteer opens it on a phone, sees the next four Saturdays, and puts their name against one shift.
Done looks like: the volunteer sees their name on the shift, and the coordinator sees which shifts still have gaps.
Out of scope for now: no accounts with passwords, no reminders by text message, no reporting of hours.
The check: two volunteers sign up for the same shift from two phones, and both names appear without either one disappearing.
The rewritten brief is now five short paragraphs, and every one of them is a decision the coordinator made rather than one an assistant would have guessed.

Notice what the out-of-scope answer did. Without it, "an app for volunteers" very often grows accounts, reminders and reports — three features the coordinator never needed for the first Saturday.

The rewritten brief, written out

Example

The same request after the five questions — the text the coordinator would actually paste.

Goal: a simple sign-up page for the twenty regular volunteers at our food bank, so each of them can put their name against a Saturday shift from a phone.
What a volunteer does: opens the page, sees the next four Saturdays with the shifts on each, and adds their first name to one shift. No password is needed.
What done looks like: the volunteer sees their name on the shift straight away, and the coordinator sees every shift with the number of names on it and which ones are still short.
Not in this version: accounts with passwords, reminders by text message, and reports of hours served.
How I will check it: two volunteers add their names to the same shift from two phones at almost the same moment; both names must appear and neither may disappear. If anything above is unclear, ask me before you start.

Each paragraph opens with the question it answers, so one answer can change later without rewriting the rest. The last sentence asks for questions instead of guesses.

The gaps that most often make a prompt fail

A feature list instead of a goal. "Login, dashboard, search, export" says what to build but not why, so nothing tells the assistant which of the four matters when they conflict.
No audience. Without one, the result is written for everybody, which in practice means the wording, the layout and the defaults fit nobody in particular.
Hidden rules. The rule you apply without thinking — opening hours, who can see prices, what counts as a duplicate — is exactly the one an assistant cannot know.
Several goals at once. Asking for a shop, a blog and a booking system in one message usually gets three half-finished parts. Pick one; write the others down for later.
No way to check. "Make it good" gives the assistant nothing to aim at and gives you nothing to judge with. An acceptance check fixes both.
Secrets in the text. Passwords, access keys and other people's personal details do not belong in a prompt. Describe what exists instead of pasting it.

A check to run before you paste it anywhere

A prompt is only text. Pasting it into a tool does not build, publish or install anything by itself, and a tool may follow some of it, misread some of it, or ask you questions back. The check below does not make any result certain; it makes sure the text says what you meant.

Read it as a stranger would. Cover your memory of the project and ask whether someone new could tell who it is for and what "done" means.
Find every word that hides a decision — "simple", "modern", "secure", "fast" — and replace it with the decision itself.
Remove anything private: passwords, keys, addresses, phone numbers, and anything a person shared with you in confidence.
Keep a copy somewhere you control, so you can compare what you asked for with what you received and edit the brief rather than starting again.
Decide in advance what you will do if the result fails your check: change one answer in the brief, not five at once, so you can tell which change mattered.

What a written brief gets you back

A brief does not make a result good, and it does not make anyone build anything. What it changes is what you can do with the first thing that comes back: instead of judging the whole of it by feel, you compare it with five answers you wrote down before you saw it. That comparison is the entire benefit, and it only works if the answers are specific enough to disagree with.

It also changes the second round. Without a brief, feedback starts from the whole picture again and every round is a fresh opinion. With one, a round is one answer that turned out to be wrong, corrected in one place — which is short enough to actually finish.

What the coordinator received

Example

Still the invented food bank from the rewrite above. The result described here is invented too: it is written to show how a brief is read against a result, not to predict what any real tool would return.

A single page opens on a phone and lists the next four Saturdays with the shifts on each. That is the brief's second answer, and it matches.
Adding a first name to a shift works, and the name stays there when the page is closed and opened again. That is the third answer, and it also matches.
The check itself is where it stops: two names added to the same shift at almost the same moment leave only the second one. This is the one answer the whole brief was written around, and it is the one that failed.
A reminder by text message is present, with a field asking for a phone number. The brief's fourth answer said no reminders, so this is not a missing feature to be thankful for — it is something to remove.

Two answers matched, one failed and one was ignored. That is a useful result, and it is only legible because the answers exist. Read against nothing, the same page looks broadly finished.

When the result is wrong, change one answer

The most common reaction to a wrong result is to describe the symptom and ask for it to be fixed. That works while the brief is right and the work is wrong. It stops working when the symptom is actually the brief being silent, because then there is nothing to fix against, and each round produces a different guess.

So before sending anything back, spend one minute asking which of the five answers the symptom belongs to. Most symptoms belong to exactly one, and the table below is the short version of that question.

Symptom, what it usually means, and the answer to change
What you see	What it usually means	Which answer to change
It is much bigger than expected	Nobody decided what to leave out, so everything that could be added was.	The out-of-scope answer. Name at least two things, in plain words.
It asks for access it never uses	The brief never said who may see or change what, so the widest option was taken as the safe one.	The who-it-is-for answer, plus one sentence on what must stay private.
Everything works but nothing is checkable	The check was written as a feeling — "it works well" — instead of as an action with an expected result.	The how-you-will-check answer, rewritten as one sentence someone else could run.
A rule of your work is ignored	The rule is real but was never written down, because it feels obvious to you.	No new answer is needed: add the rule as one line under what done looks like.
It is written for the wrong person	Two audiences were described at once, and the defaults landed on the one mentioned second.	The who-it-is-for answer. Pick one, and write the other down for later.
You cannot tell what it is for	The goal was written as a feature list, so the result is a set of parts with no order between them.	The goal answer, rewritten as who can do what once it exists.

Comparison

Make one change at a time

Pick the single symptom that matters most, and resist listing the others in the same message.
Name the answer you are changing, and quote it, so the change is visibly a change to the brief.
Write the new answer as a decision, not as a complaint: "Mondays are not offered at all", not "the Monday thing is broken".
Keep the other four answers untouched this round, then run your check again from the first step.

A checklist you can run on your own brief

Every line below is something you can answer yes or no to by looking at your own text, without asking anyone. Run it once before you paste the brief anywhere, and again whenever you change an answer. A no is not a failure; it is the next thing to write.

Run these eight checks in order

Can someone who has never met you name the one kind of person this is for, from the text alone?
Does the goal sentence describe what a person can do, rather than listing parts?
Could you point at the single most important action, and is it written as an action?
Does "done looks like" name something you could see or hold, not an impression?
Does the out-of-scope line name at least two things, and would you be comfortable if all of them were absent?
Could a second person run your check without asking you what you meant?
Have you searched the text for anything private — a password, a key, an address, someone else's details?
Is the text saved somewhere you control, so that the next round edits it instead of replacing it?

Your next step

Three things to do with your own idea, in order. None of them needs an account, a tool or a Skill.

Write your own answers to the five questions in a plain text note, one short paragraph each.
Underline the out-of-scope answer and make sure it names at least two things.
Run the check above, then keep the note: it is the brief you will edit, not a draft to throw away.