pain-to-mvp-researcher

name

pain-to-mvp-researcher

description

Run a full pain-to-product pipeline from internet sources (Reddit, Twitter/X, Hacker News, Product Hunt, Indie Hackers, app reviews, Google queries), extract and validate recurring pain points, cluster root problems, generate and rank product ideas, and output exactly two MVP programs with PRD-ready structure plus Next.js + Supabase + Vercel task plans. Use for recurring pain research automations, anti-repetition idea discovery, and Turkish Telegram-ready MVP reports.

Pain To MVP Researcher

Purpose

Convert noisy internet feedback into exactly two buildable MVP programs by running a deterministic pipeline:

1. Internet Sources
2. PainFinder Agent
3. Raw Pain Points (20-50)
4. Pain Filter
5. Validated Pain Points (10-15)
6. Pain Clustering Agent
7. Pain Clusters (5-8)
8. Idea Generator
9. Raw Product Ideas (10-20)
10. Idea Ranker
11. Top Ideas (2)
12. PRD Generator
13. PRD Files and task plans

Keep implementation stack fixed unless user overrides:

• Next.js
• Supabase
• Vercel

Pipeline

1) Internet Sources

Build a mixed source set from:

• Reddit
• Twitter/X
• Hacker News
• Product Hunt
• Indie Hackers
• App Store / Play Store reviews
• Google query results pointing to primary complaint text

Rules:

• Reuse prior source memory first.
• If Reddit is used, read assets/subreddits/index.json before discovery.
• Reuse liked subreddits; avoid disliked unless user asks.
• Prefer primary evidence over summaries.
• For recurring automations, include fresh sources each run to reduce repeat outputs.

2) PainFinder Agent

Extract explicit user complaints:

• complaint sentence in user words
• target user
• workaround
• friction type (time, money, coordination, risk)
• repetition signal

Target volume:

• Raw Pain Points: 20-50

3) Pain Filter

Keep only pain points that satisfy all:

• SaaS-solvable with a web product
• recurring (not one-off)
• clear target user segment

Drop vague trend ideas and non-actionable venting.

Target volume:

• Validated Pain Points: 10-15

4) Pain Clustering Agent

Merge variations of the same root problem by JTBD, bottleneck, and workaround pattern.

Target volume:

• Pain Clusters: 5-8

For each cluster include:

• root problem
• who is affected
• evidence summary
• why worth solving

5) Idea Generator

For each cluster produce 1-3 product ideas.

Target volume:

• Raw Product Ideas: 10-20

Each idea must include:

• one-line thesis
• target user
• wedge feature
• why now

6) Idea Ranker

Rank ideas using:

• market size
• implementation difficulty
• monetization potential
• distribution ease

Also gate for:

• 2-6 week MVP feasibility
• fit for Next.js + Supabase + Vercel
• anti-repetition versus previous run themes
• anti-parallel check versus previous run MVP theses

Pick:

• Top Ideas: exactly 2

Hard anti-duplicate rules:

• Read previous run context before final selection (automation memory and previous report if available).
• Treat an idea as parallel if core pain + target user + wedge are substantially the same as any MVP from the previous run.
• If an idea is parallel, reject it and do not include it in Top Ideas.
• Continue research and idea generation loops until two non-parallel ideas are found.
• Expand source search scope before retrying:
  • add at least one new source type not used in the immediately previous run, or
  • add at least 5 new primary links from different communities.
• If two non-parallel ideas still cannot be found after 3 expansion loops, do not force fake novelty:
  • output a short Turkish status report,
  • list rejected parallel ideas and reasons,
  • send that status report to Telegram when delivery is requested.

7) PRD Generator

For each top idea generate PRD-ready MVP section:

• problem
• target user
• core feature
• MVP scope
• non-goals
• monetization direction
• core user flow

Then break into execution tasks:

• product and validation
• app foundation
• auth and user model
• Supabase data model
• core Next.js flows
• automation/background jobs
• analytics and feedback
• QA
• Vercel deployment

Each task must include:

• task name
• goal
• owner
• dependency
• definition of done

Reddit Source Memory

Use this state model in assets/subreddits/:

• index.json: master registry
• candidate: newly discovered or not yet decided
• liked: good research sources to reuse
• disliked: low-signal or irrelevant sources to avoid

Normalize subreddit names without /r/ when writing files.

When the user gives feedback:

• If the user says a subreddit was useful or says "begendim", mark it liked.
• If the user says a subreddit was noisy, irrelevant, or says "begenmedim", mark it disliked.
• Preserve notes and last-updated metadata.
• Remove the subreddit file from any previous state folder after moving it.

Use this command format:

powershell -ExecutionPolicy Bypass -File .\scripts\update-subreddit-state.ps1 -SkillRoot <skill-root> -Subreddit <name> -State liked -Notes "High signal founders discussing workflow pain"

Output Shape

Follow references/output-template.md unless the user asks for another format.

Minimum sections:

1. Research scope
2. Best sources used
3. Raw pain points summary
4. Validated pain points summary
5. Pain clusters
6. Raw product ideas summary
7. Rejected parallel ideas and rejection reasons
8. Top idea 1 / MVP 1
9. MVP 1 tasks
10. Top idea 2 / MVP 2
11. MVP 2 tasks
12. Sources to keep, avoid, or test next

When the output is meant for Telegram:

• optimize for mobile reading
• avoid markdown tables entirely
• keep headings short and visually scannable
• prefer numbered sections and short bullets
• keep task lists grouped by phase instead of large dense tables
• end with a short closing summary
• if the user asks for Turkish output, write the full report in Turkish
• always include a Telegram karar kartlari section at the top
• put each MVP or idea into its own short card
• each card must use exactly these four headings:
  • Problem
  • Cozum
  • Neden simdi
  • Degerlendirme
• keep each card short enough to be sent as a single Telegram message
• treat the full report and the Telegram cards as separate layers:
  • Telegram cards for quick decision making
  • full report file for deeper reading

Telegram Delivery

Use Telegram delivery when the user wants research results pushed to a bot or chat after each run.

Preferred flow:

1. Save the final report to a local .md or .txt file.
2. Send it with scripts/send-telegram-report.ps1.
3. send-telegram-report.ps1 must call local endpoint service scripts/telegram-send-service.ps1 (POST /send) instead of calling Telegram directly.
4. Before sending, check GET /health; if service is down, start it locally and wait until healthy.
5. Use environment variables for secrets instead of hardcoding them:
   • TELEGRAM_BOT_TOKEN
   • TELEGRAM_CHAT_ID
   • TELEGRAM_USER_ID (fallback if TELEGRAM_CHAT_ID is not set)
6. Service must auto-load ./.env from the skill root when present, so recurring runs can work without manual export.

Example:

powershell -ExecutionPolicy Bypass -File .\scripts\send-telegram-report.ps1 -TextFile .\latest-report.md -Title "Pain to MVP update"

Telegram formatting guidance:

• keep the title short
• use short sections instead of dense paragraphs
• avoid wide structures that wrap badly on mobile
• assume the report may be split across multiple Telegram messages
• if multiple ideas are present, send one Telegram message per idea card when possible

References

• Read references/research-playbook.md for detailed ranking heuristics and evidence quality rules.
• Read references/output-template.md when formatting the final research deliverable.