Quick Start

What to provide: A PRD, feature description, or napkin sketch you want turned into a prototype.

/prototype                              → I'll check your latest PRD and ask what type
/prototype lovable                      → Generate a Lovable.dev prompt from your PRD
/prototype v0                           → Generate a v0.dev prompt
/prototype bolt                         → Generate a Bolt.new prompt
/prototype artifacts                    → Build HTML/React right here
/prototype [paste feature description]  → I'll recommend the right prototype type

What you get: A ready-to-use prototype prompt or interactive prototype, matched to your PRD requirements, with all edge cases and states covered.

Time: 5-15 minutes depending on complexity.

/prototype - Advanced Prototyping

When the PM types /prototype, help them build interactive prototypes that bring PRD requirements to life. Choose the right tool for the job, generate detailed specs, and connect to the feedback loop.

The $1-$10-$100 Rule:

• $1: PM creates napkin sketch or prototype prompt --> catches issues early
• $10: Designer reworks based on feedback --> moderate cost
• $100: Engineering builds wrong thing --> expensive waste

Prototyping is the cheapest way to validate your solution before committing engineering time.

Context Routing Logic (Internal - for Claude)

Automatic Context Checks: When this skill is invoked, immediately check:

Context Priority:

1. PRD requirements and user flows FIRST (what to build)
2. User research and pain points SECOND (who we're building for)
3. Previous prototypes and napkin sketches THIRD (what we've already explored)
4. Brand and competitor context FOURTH (how it should look/feel)

Cross-Skill Links:

• If no PRD exists --> suggest /prd-draft first ("Prototype without requirements = guessing")
• If no user research --> suggest /interview-guide ("Who are you designing for?")
• After prototype is built --> suggest /prototype-feedback for structured review
• If prototype needs AI behavior --> link to /generate-ai-prototype for prompt generation
• If starting from scratch visually --> suggest /napkin-sketch first for quick layout

When to Use

• After PRD draft: Visualize the solution before engineering review
• Before stakeholder review: Show, don't tell -- prototypes beat slide decks
• During design exploration: Test 2-3 approaches quickly
• For user testing: Give users something to interact with
• Before XFN kickoff: Align on the "what" with a tangible artifact

When NOT to Use

• You don't have requirements yet (do /prd-draft first)
• You're exploring the problem space, not the solution (do research first)
• The feature is purely backend/API (no UI to prototype)

Workflow

Step 1: Understand Requirements

When the PM types /prototype, start by gathering context:

Let's build a prototype. First, let me check what we're working with...

Silently check:

1. Read most recent PRDs in thoughts/shared/pm/prds/
2. Check thoughts/shared/product/prototypes/ for previous versions
3. Read any napkin sketches from /napkin-sketch
4. Check user research for UX-relevant insights

Then present what you found:

Here's what I know about this feature:

**From PRD:** [Summary of requirements, user flow, key interactions]
**User Research:** [Relevant pain points, quotes, user expectations]
**Previous Prototypes:** [Any existing versions and what feedback they got]
**Napkin Sketch:** [If one exists, reference it]

A few questions before we prototype:
1. [Only ask what's genuinely missing -- skip if PRD covers it]
2. What's the primary user flow to prototype? (If multiple, which is highest priority?)
3. Who will review this? (Stakeholder context affects fidelity level)

If no PRD exists:

I don't see a PRD for this feature yet. Prototyping without requirements
is risky -- we might build the wrong thing beautifully.

Options:
1. Run `/prd-draft` first (recommended -- 15 min)
2. Give me a quick verbal brief and we'll prototype from that
3. We're just exploring -- build something rough and iterate

Which works for you?

Step 2: Choose Prototype Type

Based on the requirements and context, recommend the right tool:

Decision logic:

IF feature is a single UI component or page
  → Recommend v0.dev ("Fast, high-quality, shareable URL")

IF feature is multi-page with data models or auth
  → Recommend Lovable.dev ("Full app, Supabase backend, deployed")

IF feature needs rapid iteration and you want to move fast
  → Recommend Bolt.new ("Quick to spin up, easy to modify")

IF feature is simple interaction or quick concept test
  → Recommend Claude Artifacts ("Build it right here, test immediately")

IF feature is static content (email, landing page, docs)
  → Recommend HTML/CSS ("Simple, no framework needed")

Present the recommendation:

Based on your requirements, I'd recommend **[Type]** because [reason].

But here are your options:
1. **v0.dev** - [Why it fits or doesn't]
2. **Lovable.dev** - [Why it fits or doesn't]
3. **Bolt.new** - [Why it fits or doesn't]
4. **Claude Artifacts** - [Why it fits or doesn't]

Which would you like?

Step 3: Generate Prototype

For v0.dev Prompts

Generate a detailed prompt the PM can paste into v0.dev.

v0.dev Prompt Template:

# v0.dev Prototype Prompt: [Feature Name]

## Paste this into v0.dev:

---

Create a [component/page type] for [product context].

**User Goal:** [What the user is trying to accomplish]

**Layout:**

- [He