“Could you make a simple signup form for the workshop?” Your colleague sends the message, then disappears into a meeting. You ask AI to turn it into a brief. A moment later, the brief includes a confirmation email, a waiting list, and a dashboard.
It sounds organized. But who asked for those three things?
Before building anything, use AI to separate what was requested, what still needs a decision, and how you will check the result. Here is a small example you can try with an approved workplace AI assistant.
The useful result: a brief you can discuss
Known: collect name, work email, and one workshop choice. Let people submit without creating an account.
Unresolved: what happens when a workshop is full?
Next conversation: ask the organizer to decide capacity behavior before drafting that requirement.
The workshop, source notes, and example drafts below are fictional teaching material. They are not a transcript of a product test or a claim about any AI tool’s performance.
Give the assistant the decisions you actually have
A vague request alone cannot establish a complete brief. Add the requester’s existing answers and give each note a short label. For this exercise, imagine the organizer has confirmed these:
Your source packet
R1. A participant supplies a name and work email, then chooses exactly one workshop from the published list. All three fields are required.
R2. No account or sign-in is required.
R3. A successful submission displays “Registration received.” Confirmation emails and an organizer dashboard are outside this task.
Q1. Capacity limits and waiting-list behavior have not been decided.
Only paste material your organization permits you to use with that assistant. For a first practice run, these fictional notes are enough.
Ask for checks, then look for invented decisions
Ask AI for a draft completion checklist tied to R1–R3. These are often called acceptance criteria: observable conditions for accepting this particular piece of work. Keep unanswered questions in a separate section.
Before: tidy wording, hidden scope
“Build a user-friendly registration experience with automatic confirmations and a waiting list.”
This sentence leaves “user-friendly” undefined, adds an undecided feature, and could quietly turn “confirmation” into an email.
After: concrete checks with sources
C1 — R1: A submission with a name, work email, and exactly one listed workshop can be accepted. A submission missing any of those fields cannot be accepted.
C2 — R2: A participant can complete the form without creating an account or signing in.
C3 — R3: After a successful submission, the page displays “Registration received.” This task adds neither confirmation emails nor an organizer dashboard.
Decision needed — Q1: How should the form behave when a workshop reaches capacity?
These are proposed checks for the fictional brief, not proof that a form passes them. Even “work email” needs clarification if the team wants to reject particular domains. Ask for that rule; don’t let the assistant invent one.
Try it: which line needs a conversation?
Imagine your AI draft adds: “When a workshop is full, automatically move the participant to a waiting list.” Would you keep it, delete it, or ask the organizer?
Reveal the reasoning
Move it to the open questions. Q1 explicitly says capacity behavior is undecided. Deleting the line entirely would hide an important gap; accepting it would create an unapproved rule. Ask whether to block registration, offer a waiting list, or use another agreed behavior.
Copy this prompt into your approved assistant
Open the brief-to-checklist prompt
Help me clarify a small work request before implementation. Treat the source notes as the authority for this draft. Do not build anything or claim that a test has run.
Return three sections: (1) Candidate acceptance criteria, each with a source-note label and an observable way to check it; (2) Open questions that need the requester’s decision; (3) Explicit exclusions stated in the notes.
Do not invent limits, deadlines, approval rules, notifications, or extra features. If an idea is useful but unsupported, phrase it as a question. Identify ambiguous terms rather than silently choosing a meaning. Keep each criterion short enough to discuss separately.
Then review your draft for contradictions and unsupported additions. Keep unresolved items visible. A clean-looking draft is not approval.
Work request: [paste here]
Confirmed notes with labels: [paste here]
Known unknowns and exclusions: [paste here]
Check your result before handing it over
Use this short review on the AI draft. You can do it without building the form.
Four checks for your draft
1. Trace it. Can you point from every proposed requirement to a confirmed note? Unsupported ideas belong in questions.
2. Try the opposite. If a required field were blank, would the criterion tell you what should happen?
3. Keep the gap. Is capacity still visibly unresolved, rather than hidden behind a confident waiting-list rule?
4. Check the boundary. Are emails and dashboards still excluded?
If a check fails, revise the brief with the requester. Once the decisions are agreed, record who approved the criteria and which version they approved. Testing the implemented form comes later.
The next useful message to your colleague is small: “Here are the conditions I understand. Capacity is the remaining decision—what should happen when a session is full?” That is easier to answer than a polished page full of assumptions.
Keep going
Already agreed on the work? See how to turn handoff notes into a usable procedure. If the request changes later, use an AI-assisted change log to make the differences visible.
Sources and editorial notes
Checked November 2, 2026. Atlassian: What is acceptance criteria? Examples and best practices explains observable completion conditions. Mountain Goat Software: The Two Ways to Add Detail to User Stories compares adding criteria with splitting work. Their explanations informed this guide; the workshop exercise and visual cards are original.
This is a tool-neutral drafting workflow. It makes no claim about a current paid feature, price, measured time saving, or guaranteed model behavior. The illustration was generated for WorkTool Note; no external blog images were reused.