The Spec

Why this matters

Building software without a spec is the most common failure mode in AI-assisted development. You describe something vague, get something vague, iterate randomly, and end up with an app that kind-of does what you wanted. The spec is the solution. It forces you to think before you build — to turn a vague idea into a precise description that constrains what gets built. The skill being trained here is not writing — it is product thinking.

How to do it

1. 1

   Use your capstone brief from Drill 0.3 as the starting point

   You wrote 3 sentences describing what you want to build. Now we expand that into a full product brief using a structured approach.

2. 2

   Use the Spec Writer prompt to expand the brief

   Claude will ask you questions and help you think through the scope, constraints, and user flows. Answer each question specifically.

3. 3

   Review the output spec for scope — trim anything beyond MVP

   The most common spec mistake: adding features you do not need for the first version. The Spec Review prompt helps identify scope creep.

4. 4

   Save the final spec — you will use it in Drill 3.2

   Copy the spec to a document. The first prompt in Lovable will be a refined version of this spec.

The prompt

I want to build a web application. Here is my starting vision:

[PASTE YOUR CAPSTONE BRIEF — 3 sentences from Drill 0.3]

Help me turn this into a complete product spec by asking me these questions one at a time:

1. Who is the primary user? What problem does this solve for them specifically?
2. What are the 3 most important things a user needs to be able to DO with this app?
3. What does the simplest possible version look like — what can we cut?
4. What does it look like? (Simple layout description)
5. What data does it need to store or display?

After I answer all five, write the complete product spec as a structured brief I can paste into a builder tool.

Review this product spec for scope creep:

[PASTE YOUR SPEC]

For each feature, tell me:
1. Is this essential for the MVP (first working version)?
2. Could this be added in a future iteration without breaking anything?
3. Is this nice-to-have or genuinely required for the core use case?

Give me a trimmed MVP spec that includes only the essential features.

Success criteria

• ✓You expanded your capstone brief into a complete product spec
• ✓The spec was reviewed and trimmed for MVP scope
• ✓The spec names specific user actions (not just features)
• ✓You saved the spec and could paste it into a builder tool right now

Common mistakes