MODULE 01 / 18 · PART 1 · DECIDE & DESIGN
Requirements & Scoping
Turn a vague ask into a testable spec, an honest scope, and a decision you can defend.
THE SHORT ANSWER
What this module changes.
Most expensive defects are written before the first line of code. These prompts turn a vague request into functional requirements, non-goals, assumptions, acceptance criteria, and a risk register you can test.
Ambiguity is the most expensive defect. These prompts convert vague asks into testable specs, surface the questions nobody asked, and cut scope before a line of code exists.
East African briefs often arrive as a WhatsApp voice note, a forwarded PDF from a donor, or a sentence from a founder who has already promised the feature to a customer. These prompts make the hidden assumptions visible before they become a budget line or a rewrite. They also help you separate a genuine compliance requirement from a habit nobody has questioned.
THE MODULE PROMPT LIBRARY
20 prompts for requirements & scoping.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Turn this request into a precise spec: [request]. List functional requirements, non-functional requirements, explicit non-goals, and open questions. Mark anything you had to assume.
Why it worksSeparates what is known from what is guessed, so assumptions get challenged before they become code.
Before writing anything, ask me the ten questions whose answers would most change the design of [feature]. Rank them by how much rework a wrong answer causes.
Why it worksFront-loads the expensive unknowns instead of discovering them mid-implementation.
Here is the ticket: [ticket]. Write the acceptance criteria as Given/When/Then scenarios, including the unhappy paths and the boundary values.
Why it worksForces testable criteria and drags edge cases into the open at planning time.
What is the smallest version of [feature] that delivers the user value? Then list what we are deliberately deferring and what that deferral costs us later.
Why it worksProduces an MVP with an honest price tag on the debt it creates.
Restate this requirement in your own words and tell me where it is ambiguous or self-contradictory: [requirement].
Why it worksCheap ambiguity detector; contradictions surface before they are encoded.
Identify the implicit requirements hiding in this request: [request]. What will users assume works that we have not mentioned?
Why it worksCatches the unstated expectations that generate "but I thought it would…" bugs.
For [feature], list every stakeholder and what each one needs to be true for them to call this a success.
Why it worksPrevents optimizing for the loudest stakeholder and missing the compliance or ops view.
Estimate this work in three sizes: smallest possible, realistic, and with the unknowns resolved. State what drives the spread.
Why it worksMakes uncertainty explicit instead of hiding it in a single optimistic number.
What would make us regret building [feature] in six months? List the assumptions that, if wrong, turn this into a rewrite.
Why it worksSurfaces the load-bearing assumptions while they are still cheap to test.
Decompose [epic] into vertical slices that each ship independently and are individually valuable. Order them by risk retired per unit of effort.
Why it worksProduces a delivery plan where every slice de-risks the next one.
Here is the requirement and here is the existing system: [context]. What does this requirement conflict with, and which existing behavior must change?
Why it worksFinds the collisions with current behavior before they become regressions.
Write the one-page design brief for [feature]: problem, users, success metric, constraints, non-goals, and the decision we are asking for.
Why it worksGives you the artifact that gets a decision made in a review meeting.
What is the definition of done for [task], including observability, docs, migration, and rollback — not just "code merged"?
Why it worksExpands "done" to include everything production actually requires.
List the failure modes of this requirement as written: [requirement]. For each, propose a sharper wording.
Why it worksTurns a fuzzy requirement into a precise one by attacking it first.
Given these constraints [constraints], what is explicitly out of scope, and what would we have to give up to bring it back in?
Why it worksMakes scope trade-offs visible instead of silently absorbing them.
Draft the questions I should ask the requester of [feature] to close every gap in this description.
Why it worksGives you a ready-made clarification agenda for the next conversation.
Turn this vague goal into measurable success criteria: [goal]. Include the metric, the target, and the time window.
Why it worksConverts aspiration into something you can actually verify after launch.
What is the blast radius of [feature] if it behaves exactly as specified but the specification is wrong?
Why it worksSeparates "did we build it right" from "did we build the right thing".
Compare this request against what the system already does: [request] + [context]. Is this a new capability or a variant we should generalize?
Why it worksPrevents a fourth near-duplicate feature where one abstraction would do.
Write the risk register for [initiative]: risk, likelihood, impact, early warning signal, and mitigation owner.
Why it worksProduces a living artifact that turns vague worry into tracked, owned risk.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Take the last feature request you received. Run prompts 1, 3 and 10, then commit the spec, acceptance criteria and risk register to docs/ in the repo. Ask one stakeholder to challenge the non-goals.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.