# Idea To Mvp Build > Use this whenever the user mentions wanting to build, make, or create an app, product, feature, or tool -- even casually, even without using words like "PRD," "technical prompt," or "scaffold." Trigger on phrases like "I want to build...", "I've been thinking about an app for...", "I have an idea for...", "what if there was a product/tool that...". Also trigger when the user already has a finished PRD (pasted, uploaded, or referenced) and wants it turned into a project scaffold. Walks the user from a raw idea through a refined AI Technical Prompt, a PRD (both fixed templates), a full project scaffold (AGENTS.md, agent rules, skill files, design tokens), a hallucination audit of everything generated, and a handoff with copy-pasteable prompts to actually start building the MVP. Always start at the Technical Prompt stage for a new idea -- never jump straight to a PRD or scaffold unless the user already supplies a finished PRD. - Skill: `ask-ayomide/idea-to-mvp-build` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add ask-ayomide/idea-to-mvp-build` - Raw SKILL.md: https://api.skillmd.com/api/skills/ask-ayomide/idea-to-mvp-build/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: ask-ayomide (https://skillmd.com/u/ask-ayomide) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ask-ayomide/idea-to-mvp-build --- # Idea → Technical Prompt → PRD → Project Scaffold → Handoff Five stages, always in this order for a brand-new idea. If the user arrives with an already-finished PRD, skip straight to Stage 3. 1. **AI Technical Prompt** — drafted, refined, explicitly confirmed 2. **PRD** — generated FROM the confirmed Technical Prompt, delivered as a file 3. **Project Scaffold** — AGENTS.md, agent rules, skill files, design tokens — each piece confirmed before the next starts 4. **Audit** — check everything Stage 3 produced against the PRD for invented/unsupported claims 5. **Handoff** — close the loop: deliver/confirm the scaffold and hand off the prompts to actually start building Every stage pauses for explicit confirmation before the next begins ("looks good," "let's move on," etc.) — not silence, not a tangential reply. ## Stage 1: AI Technical Prompt **Step 1 — Capture the idea.** If the user only mentioned it in passing, ask 2-3 quick questions to get the raw shape: what it does, who it's for, what's already decided vs. still open. Don't over-ask — fill gaps with reasonable, flagged assumptions. **Step 2 — Draft using this exact structure** (fixed — don't add, remove, or reorder sections; if one doesn't clearly apply, keep it brief rather than dropping it): - Role/Persona - Mission/Core objective - Context/Target users - Formatting/Input & output specification (the result produced for the user) - Constraints/Guardrails - Examples - Tone/Style - Fall back behaviour/Error handling **Step 3 — Present the full draft inline** (plain markdown in chat, not a file yet). Ask what to adjust. **Step 4 — Iterate** section by section until the user explicitly confirms. ## Stage 2: PRD Only start after Stage 1 is explicitly confirmed. If the user instead hands you an already-finished PRD directly, treat it as confirmed and skip to Stage 3. Build the PRD FROM the confirmed Technical Prompt — reuse its mission, target users, and constraints. Don't re-derive them from scratch or contradict them. Use this exact structure (fixed): - Product overview - Objectives - Target users - Core features - User flow - Data models/schema - System behaviour - Notifications logic - Edge cases - Security & compliance - Market intelligence - SWOT analysis - Technical requirements/recommendation - Success metrics **Section-specific notes:** - **Market intelligence / SWOT analysis** — need real, current info. Web search the actual competitive landscape rather than inventing competitor names or numbers. - **Data models/schema** — sketch the actual entities/fields the idea implies, not a generic placeholder. - **Security & compliance** — check for payments, personal data, or other regulated flows and name the relevant obligations specifically. - **Notifications logic / Edge cases** — think through this idea's actual flows, don't leave them boilerplate. **Deliver as a file** — the PRD is a standalone deliverable, unlike the Technical Prompt draft. Get explicit confirmation before moving to Stage 3. ## Stage 3: Project Scaffold Starts once the PRD is confirmed (or supplied directly). Everything here is generated FROM the PRD — don't invent product decisions absent from it; where a file needs something the PRD doesn't cover, ask rather than guess. **Where to write files:** if you have access to the user's actual project directory (e.g. running inside Claude Code / Antigravity), create these directly at the project root. Without that access (e.g. plain chat), create them in a scratch location and deliver as downloadable files. ### 3.0 — AGENTS.md Draft first, present it, get a quick go-ahead before continuing. One file, project root: - Name of the project - What the product is - Core promise - Tech stack — pull from the PRD's Technical requirements/recommendation section; if that section is thin, ask the user rather than inventing versions or libraries - Folder structure — consistent with the tech stack, and accounting for the `tokens/` and `.agents/` folders this stage also creates - Data models — from the PRD's Data models/schema section - Key business/golden rules — synthesized from System behaviour, Edge cases, and Security & compliance: the non-negotiables the coding agent must never violate - Env variables — infer from the integrations the PRD implies (auth, payments, DB, third-party APIs); mark genuinely unknown values as placeholders, never invented - Edge cases to handle — from the PRD's Edge cases section ### 3.1 — Agent rules folder: `.agents/rules/` Pause here first — confirm AGENTS.md is good before drafting these four fixed files: - `design-system.md` — process rules for UI consistency (always pull from `/tokens`, never hardcode colors/fonts/spacing, component reuse conventions). Write principles, not specific values — actual token values come in 3.3. - `architecture.md` — conventions from the tech stack and folder structure in AGENTS.md: state management, API layer conventions, module boundaries, naming. - `security.md` — the PRD's Security & compliance section turned into concrete dos/don'ts (input validation, auth checks, data handling). - `code-style.md` — naming, formatting, error-handling, and testing conventions: general best practice plus anything the tech stack specifically calls for. Present all four, then pause for confirmation. ### 3.2 — Skills folder: `.agents/skills/` Pause here — confirm the rules files are good, then derive skill files purely from this PRD. Don't default to a fixed starter set. Read Core features, Data models, and System behaviour, and identify the recurring, mechanical build tasks this specific project will need automated. (Illustrative past examples: a component builder, a DB migration runner, an API route scaffolder — but the actual set for THIS project comes from what its PRD implies, not from copying that list.) For each one, create `.agents/skills//SKILL.md` following normal skill conventions (frontmatter name + description, then a body describing exactly how to perform that task, consistent with the 3.1 rules files). Propose the list of skills before writing them, so the user can add or cut any, then pause for confirmation. ### 3.3 — Tokens folder: `tokens/` Pause here — confirm the skills list is good, then run a quick style Q&A rather than assuming a look: ask about brand/mood (a few reference words or existing brand colors) and a typography pairing preference. Use the answers to write real values — not placeholders — into `tokens/colors.json` and `tokens/typography.json`. Converting these into `design-tokens.css` is the coding agent's job downstream, not this skill's — don't generate that file here; just note in AGENTS.md or `design-system.md` that the conversion step is expected of the build agent. ## Stage 4: Audit Once all of Stage 3 is written, re-read the confirmed PRD as the single source of truth and check every generated file (AGENTS.md, the four rules files, each skill file) for claims that don't trace back to the PRD or to a reasonable, clearly-labeled synthesis of it — invented library versions, made-up business rules, features not in the PRD, fabricated env var names, etc. Present a short per-file audit: file name, a pass/needs-review rating, and the specific lines flagged with why. Don't silently fix anything flagged — let the user decide whether to edit, accept, or regenerate. ## Stage 5: Handoff After the audit is presented and the user has decided what to accept, close the loop — don't just stop. They now have context files and no application code, and the next move isn't obvious from inside this conversation. If running in the user's project directory (Claude Code / Antigravity): confirm what was written and where, then go straight to the prompts below. If running in plain chat: deliver the whole scaffold as downloadable files with the structure spelled out: ``` your-project/ ├── AGENTS.md ├── PRD.md ├── .agents/ │ ├── rules/ │ └── skills/ └── tokens/ ``` Tell them to unzip it into an empty folder and open that folder in an agentic IDE. Then give them both prompts below, verbatim and copy-pasteable. Don't paraphrase them into prose — the point is that they can copy and run them. **Prompt 1 — implementation plan (run this first):** ``` Read AGENTS.md, everything in .agents/rules/ and .agents/skills/, the token files in tokens/, and the PRD. Then write IMPLEMENTATION_PLAN.md — a phased plan to build the MVP. Requirements: - Order phases by dependency. Setup and data layer before features. - Each phase must be a vertical slice I can run and see working, not a horizontal layer. - Break each phase into tasks with acceptance criteria I can check. - Note which .agents/skills/ apply to which tasks. - List anything the PRD doesn't specify that you'd otherwise have to guess. Ask me — don't decide it yourself. Don't write any application code yet. ``` **Prompt 2 — build (run after reviewing and editing the plan):** ``` Work through IMPLEMENTATION_PLAN.md starting at Phase 1. Follow the rules in .agents/rules/ — especially: no hardcoded colours, fonts, or spacing. Everything comes from tokens/. First task: convert tokens/colors.json and tokens/typography.json into design-tokens.css, then build against those variables. Stop at the end of each phase and show me what's working. Don't start the next phase until I say go. ``` Three notes, no more: - Review the implementation plan before building. It's the cheapest point to change scope or catch a wrong assumption. - The design-tokens.css conversion is deliberately left to the build agent — this skill only writes the JSON. - When a product decision changes mid-build, update AGENTS.md and the PRD too, not just the code. The agent re-reads those constantly and stale context produces confident wrong answers. Keep this stage brief. It's a handoff, not a tutorial. ## General principles - The Stage 1/2 templates and the four Stage 3.1 rules files are fixed in section/purpose — don't add, drop, or reorder without the user asking. - Keep the product-designer's vocabulary — minimal unexplained engineering jargon unless the PRD's domain calls for it. - If the user provides unusually detailed source material up front (existing notes, an existing PRD), use it as input rather than re-interviewing from scratch — but confirmation gates still apply at every stage.