# Three Starter Spec Prompts **Copy, paste, fill in the brackets, build.** *Part of the MxP Studio spec-driven development kit* --- ## How to use this document Three prompts. Three escalating levels of stakes. Pick the one that matches your actual situation: - **Prompt 1 — The Personal Tool.** You are the customer. Low stakes, high motivation. - **Prompt 2 — The Team Tool.** Internal use at work. Real friction, real audience. - **Prompt 3 — The Public MVP.** Something you'd show strangers. Real risk, real reward. ### The ritual 1. **Pick ONE.** Don't try to do all three. The point is to ship one thing, not plan three. 2. **Fill in the brackets** with your real specifics. 3. **Paste into Kiro** (or Lovable, or Claude) as your opening prompt. 4. **Let the tool generate** the PR-FAQ, requirements, and design — then review and refine. 5. **Tag [@ajbubb](https://linkedin.com/in/ajbubb) on LinkedIn** when you ship it. Each prompt is self-contained — you don't need the PR-FAQ template, steering file, or EARS cheat sheet to use them (though you'll want all three once you're past your first build). --- ## Prompt 1 — The Personal Tool **Best for:** Your first spec ever. Low stakes, high motivation. You are the customer. > I want to build a personal tool for myself. The problem: **[describe a friction you experience weekly. Examples: "I lose track of which books I've lent to friends." "I want to remember every restaurant I've liked but my notes are scattered across three apps." "I spend 20 minutes every Sunday figuring out what I did last week for my weekly review."]** > > Help me work backwards from the problem. First, write a one-paragraph "press release" for the tool as if I just launched it — who it's for, what it does, what outcome I get. Then write a PR-FAQ with 3 internal questions I need to answer before I build, and 3 external questions a user would ask in the first 30 seconds. > > Once the PR-FAQ feels right, generate the requirements document in EARS format for the **minimum lovable version** — the smallest possible version that would make me say "this is useful." Keep it to no more than 5 user stories. For each story, include at least one event-driven and one unwanted-behavior requirement. > > Tech preference: **[pick one: "simple web app (React + local storage)" OR "mobile-friendly web app with a backend (React + Supabase)" OR "I don't care, pick what's fastest"]** > > Constraints: > - I want to ship v1 in under 4 hours of build time. > - No auth, or the simplest possible auth (magic link / anonymous). > - No third-party integrations in v1. > > Let's start with the PR-FAQ. Don't skip ahead. **Why this one works:** You're the customer, which means you can answer every clarifying question without a research call. The 4-hour constraint forces real scope discipline. And you'll actually use what you build, which creates the feedback loop that makes you better at spec-driven dev. --- ## Prompt 2 — The Team Tool **Best for:** Builders inside an org. Solves a real friction. Creates a share-worthy artifact at work. > I want to build an internal tool for my team at **[company / team name]**. The problem: **[describe a specific friction. Examples: "My team spends 30 minutes in every standup restating what's blocked." "New hires take 2 weeks to figure out who owns which system." "We run the same weekly report manually every Monday morning."]** > > The customer for this tool is **[specific role on your team — e.g. "the engineering manager who runs the weekly review" or "a new hire in their first two weeks"]**. There are roughly **[number]** of them. > > Help me work backwards. Write a PR-FAQ: a one-paragraph press release, a customer quote from one of the specific people I named, 5 internal questions my team should answer before building, and 5 external questions the tool's users would ask. > > Then generate requirements in EARS format for the **minimum version that would genuinely save these people time**. Cover: > - The happy path (the feature's main flow) > - At least 3 unwanted-behavior requirements (things that break, what should happen) > - Any ubiquitous requirements relevant to working inside a company (audit logging? access control? PII?) > > Flag any assumptions you're making about our existing stack. My team currently uses: **[list the tools relevant — e.g. "Slack, GitHub, Notion, AWS, and Datadog"]**. > > Tech preferences: **[pick one: "stay within what my team already uses — I want zero new vendor approvals" OR "I can add one new service if it's worth it" OR "assume I have full flexibility"]** > > Constraints: > - v1 must ship in under 2 weekends of my own time (I have a day job). > - Must be shareable as a URL inside my team's network (not a CLI). > - Must not require anyone else on my team to do anything to start using it. > > Start with the PR-FAQ. Don't skip ahead. **Why this one works:** The constraints prevent the most common failure mode — building a tool that requires organizational buy-in before anyone uses it. If your v1 needs an email to IT or a Jira ticket to deploy, you've already lost. Spec-driven dev should produce something you can share on a Friday and have used by Monday. --- ## Prompt 3 — The Public MVP **Best for:** People who've built at least one thing already, and are ready to put something in front of strangers. > I want to build a public MVP. The idea: **[one-sentence description. Example: "A tool that turns any blog post URL into a set of tweet-sized summaries, formatted for LinkedIn carousels."]** > > The customer is **[specific — not "marketers" but "B2B content marketers at SaaS companies who publish 2-4 long-form posts per month and struggle to get their team to reshare them"]**. The durable need is **[not the feature, the underlying human need. Example: "they need their own content to travel further without asking colleagues to individually reshare every post"]**. > > Help me work backwards. Write a full PR-FAQ including: > - Press release (headline, subheadline, problem, solution, customer quote, leader quote, call to action) > - 7 internal FAQ questions covering: who exactly the customer is, the durable need, what happens if we don't build this, what we will NOT build, how we'll know it's working, the riskiest assumption, and why now > - 6 external FAQ questions covering: how this differs from the obvious alternative, pricing, technical requirements, integrations, data handling, and how to get started > > Then generate a complete requirements document in EARS format covering: > - 5-8 user stories for the minimum viable public version > - Each story must have: ubiquitous requirements, at least 2 event-driven requirements, at least 2 unwanted-behavior requirements > - Separate requirements for: authentication/auth flow, payment (if applicable), public-facing marketing surface (landing page, pricing, signup), and the core product > > Then propose an architecture: > - Frontend framework > - Backend/API design > - Database schema (as a simple list of tables + key fields) > - Third-party services needed (auth, payments, email, analytics) > - Hosting + deployment story > > Then produce a task breakdown for the first week of build time (40 hours), organized by day. Each day should end with something that works, even if not complete. > > Constraints and preferences: > - Stack preference: **[e.g., "React + Vite + Supabase + Stripe + Vercel, I know this stack"]** > - Budget for third-party services in the first 3 months: **[e.g., "$50/month max"]** > - I am the only developer. **[Or: "I have one part-time collaborator who can do design but not code."]** > - I can realistically spend **[e.g., "12-15 hours a week"]** on this. > - My "definition of done" for v1 is: a stranger can sign up, pay, get value, and recommend it to a colleague without me intervening. > > Start with the PR-FAQ. Do not skip to requirements or architecture until the PR-FAQ is tight. If anything in the PR-FAQ feels weak to you, push back — don't just generate something to fill the space. **Why this one works:** The "stranger can sign up and get value without me intervening" line is the real forcing function. Most public MVPs fail not because the tech is wrong, but because they silently depend on the creator's hand-holding. EARS requirements surface those dependencies early. And the final line — *"if anything feels weak, push back"* — turns the AI tool from a generator into a collaborator. --- ## What to do with the output You'll get a lot of text back. Don't try to build from all of it at once. Instead: 1. **Read the PR-FAQ out loud.** If it doesn't sound like something you could defend in a conversation, iterate. 2. **Read the customer quote.** If you can't imagine a specific person saying it, rewrite it (or ask the tool to rewrite it with a more realistic voice). 3. **Pick ONE user story.** Just one. The first one. Paste it back into the tool and say: *"Generate the first 2 hours of build work for this one story only. Let's ship this part before we think about the next story."* Spec-driven development isn't about having the perfect plan. It's about having *enough* plan to make the next two hours of work productive. --- ## If you get stuck The most common failure mode: the tool generates a spec that's too abstract. Symptoms: - The user story says "As a user, I want to manage my tasks" - The requirements say things like "The system shall handle task management properly" - You can't tell what to build first **Fix:** go back to the PR-FAQ. Specifically, look at the customer quote. If the quote is vague, the rest of the spec will be vague. Paste the quote back in and say: *"This customer quote is too generic. Rewrite it with a specific name, a specific work context, a specific Tuesday morning when they had a specific problem, and a specific moment when this tool solved it. Avoid superlatives. Make it sound like something a real person said to a real interviewer."* You'll get back a better quote. The rest of the spec gets better automatically. --- ## License Use these prompts freely. Remix them. Share them. If they help you ship something, tag [@ajbubb](https://linkedin.com/in/ajbubb) on LinkedIn. I'm collecting real examples of what people built from these — the good ones, the weird ones, the failed experiments. Add yours to the pile. *Built by AJ Bubb / MxP Studio.*