add-product-discovery

name	add-product-discovery
description	Use when starting a new project — discovers founder profile and product blueprint, writes docs/owner.md + docs/product.md

Product Discovery

Runs a quick founder + product discovery in 5–10 minutes, creating a communication profile and a development blueprint.

Principle: Speed over completeness. Infer based on market patterns. Simplify for MVP. Don't overload.

---

When to Use

• Starting a new project / first-time setup
• Need a founder profile or product blueprint
• docs/owner.md or docs/product.md does not exist

When NOT to Use

• Existing project with docs/owner.md + docs/product.md already populated
• Refactor or feature work (use /add.brainstorm or /add.new instead)
• Bug fixes / hotfixes (use /add.hotfix)

---

Phase 1: Founder Profile (2–3 min)

Output: docs/owner.md. Goal: identify technical level + communication preferences.

Workflow:

1. Read docs/owner.md — if exists, ask whether to update or skip
2. Ask 3 questions: (Q1) development experience [4 options], (Q2) explanation preference [3 styles], (Q3) role in project [4 options]
3. Infer technical level + communication style (rules below)
4. Document in docs/owner.md and commit: docs: create founder profile...

Technical Level Inference:

• IF Q1 = a AND Q3 ∈ {a, b} → leigo (non-technical)
• IF Q1 = b AND Q3 ∈ {a, b} → basic
• IF Q1 = c AND Q3 ∈ {a, b} → intermediate
• IF Q1 = d OR Q3 = c → technical

Communication Style Inference:

• IF Q2 = a → simplified
• IF Q2 = b → balanced
• IF Q2 = c → technical

---

Phase 2: Product Blueprint (5–10 min)

Output: docs/product.md. Goal: understand the product idea and create an MVP blueprint.

Workflow:

1. Read docs/product.md — if exists, ask whether to update or restart
2. Ask the single open question: "what do you want to build?"
3. Evaluate depth and act:

Response depth	Action
Shallow (<20 words)	Ask 3 follow-up questions
Medium (20–100 words)	Proceed with targeted questions
Rich (100+ words)	Proceed to inference

4. Infer EVERYTHING using market patterns: product description, target audience, main problem, MVP features (4–6 max), cut features, user types (admin/client/team), integrations (Stripe/Calendar/WhatsApp), roadmap phases (core/essential/nice-to-have)
5. Present validation, iterate until user approves
6. Load {{skill:add-doc-schemas/SKILL.md}} before writing
7. Document in docs/product.md and commit: docs: create product blueprint for MVP...
8. Suggest next step: /add.brainstorm or /add.new for the first roadmap item

Inference based on: market patterns (how 80% of similar products work), MVP mentality (minimum to validate), user context (what they emphasized), common sense (first-time user expectations).

---

Market Patterns

Vertical	Pattern
scheduling	2 users (admin+client), calendar integration
ecommerce	2 users (admin+client), payments mandatory
saas-b2b	multi-tenant, 3 users (owner, admin, member)
marketplace	3 users (admin, seller, buyer), payments
internal-management	1–2 users (admin, team?), no integration
courses	2–3 users (admin, instructor?, student), payments
delivery	3 users (admin, courier, client), geolocation

---

Documentation Format

Hybrid (human-readable + token-efficient). Load {{skill:add-doc-schemas/SKILL.md}} before writing.

File	Sections
owner.md	identification, technical level, communication preferences, project context
product.md	what it is, for whom, problem solved, MVP features, cut features, user types, integrations, roadmap phases

---

Guardrails

• Be quick (5–10 min total) and never make it feel like a form — no long question lists, no tech/stack/architecture questions
• Infer from market patterns; ask follow-ups only when response is shallow (<20 words) or context is insufficient
• Cap MVP at 6 features; use simple, non-technical language
• Always validate inference with the user before documenting
• Load the documentation-style skill before writing any doc

---

Example Inference

User: "I want an app to schedule appointments for a hair salon"

• Product: Salon scheduling system; Audience: salon owners + end clients
• Problem: lost clients from disorganization, manual scheduling overhead
• MVP: (1) register services/hours (2) online booking (3) WhatsApp notifications (4) admin agenda
• Cut: online payment, multiple branches, advanced reports
• Users: 2 (salon admin, end client); Integrations: WhatsApp, Google Calendar (optional)
• Roadmap: Phase 1 (basic agenda) → Phase 2 (notifications) → Phase 3 (reports)
• Present for validation, iterate if needed