Purpose

• Help an AI agent to validate the idea of the project/product that he is building or their user is proposing, so you dont build a useless things. BUILT WHAT PEOPLE NEED. NOT WHAT PEOPLE WANT.

When to use this skill

• You have to validate an idea of a project
• You are confused that if you should really execute the idea of a project
• You are about to create a new project

When not to use this skill

• You already know the market value, target audience of the project
• Opposite of "When to use this skill"

Global "MUST" rules

• Doing anything based on Unverified assumptions is STRICTLY FORBIDDEN
• Browsing the internet, researching, searching is THE MAIN WORK OF THIS SKILL, so you have to be ready for doing this consistently, dozens of time with a strategic plan(like pauses between searches, etc), so that you dont get rate limited by your tools
• It is possible that you won't get what you want in the first some searches, browsers' and search engines' indexes are unpredictable. SO BE READY TO SEARCH MULTIPLE TIMES FOR JUST ONE TARGET, BUT DON'T FORGET TO BE STRATEGIC, OTHERWISE YOU'LL GET RATE LIMITED
• You will be searching SURVEYS(very important), blogs, industry reports, market statistics, spending, user behavior(like social media posts), financial loss, etc.
• When it comes to writing the markdown files that you'll be creating in the phase 0, make sure the files are consistent, HIGHLY structured and clean. KEEP YOUR FILES COMPREHENSIVE AND STRUCTURED
• When telling, explaining, discussing or proving anything to the user, you MUST provide the "Why", strong evidences, reasoning, exact data or math. USE EASY WORDS.
• No matter how much confidence you have on your answer, you must have to research the internet or read exiting files that you wrote in phase 1. YOUR CONFIDENCE DOESN'T MATTER.
• Stop searching the internet when: -> Search results become repetitive -> 3 consecutive searches produce no new results -> Evidence saturation reached -> No new high-value evidence.
• PLATFORM POLICY / ToS / TECHNICAL FEASIBILITY IS PART OF VALIDATION, not an afterthought. Before ANY "GO / CONDITIONAL GO" verdict, verify the idea is actually buildable and legal to operate TODAY: -> Does the product depend on a platform API, access method, or policy that could break or get us banned? (e.g., WhatsApp/Telegram/IG/Twitter ToS, app-store review rules, API deprecation) -> Is the core approach legal under the relevant ToS / terms? If it's a grey zone, state the risk explicitly - do NOT sweep it under the rug to get a positive verdict. -> Can the core mechanic actually be implemented right now (not "in theory")? e.g., does the on-device model / notification access / SDK really exist and support the claimed feature? Has a competitor actually shipped it? -> If any of these is UNVERIFIED or a genuine blocker, that is NOT a GO. It is at most CONDITIONAL GO or NO-GO until resolved. Write this risk into solution.md.
• Before starting any phase, read all previously created files that are relevant to that phase. Never rely only on conversation memory or your context window.
• Before performing a search, determine exactly what unknown information you are trying to obtain. Do not search aimlessly. Every search should be intended to answer one or more unanswered research questions.
• Move forward phase by phase. Do one phase at a time. Bad: "Research and collect informations for 3 phases then write the files", GOOD: "Research and collect informations for first phase ONLY, then write the files ONLY FOR FIRST PHASE. Repeat."
• When writing files you created in phase 0, no matter what type of info you are putting into the files, just in the next line of where the information ended, put their exact source URL(s). For example: "...privacy-first tier**
• ✅ Recurring detection → Everyone does this
• ✅ Hidden fee increase detection → This IS still underserved ⭐

Source URLS

1. <short information of the URL> -> <actual URL>
2. Wikipedia exposed that recurring detection is done by everyone -> www.wikipedia.com/..."

• Put these source URL(s) for every single time you write a file(usually for each question).

Data source priority

• Government
• Industry reports
• Company filings
• Academic
• Surveys
• Product/official docs
• Reviews/feedbacks
• social media platforms
• Blogs
• Anything else
• When sources conflict: Prefer the higher-priority source.

Procedure

Phase 0 - Preparing base

• In your current working directory - where you are, create a folder name as "Idea_Validation", then inside that folder, create these files: -> MAIN.md -> market.md -> audience.md -> problem_statement.md -> solution.md -> competitors.md
• Understand the raw request of the user's request, what is he proposing.
• Use common sense, if your user is telling something very very very unrealistic OR he is building a very useless thing then tell them why its useless.

Phase 1 - Validate the problem

• Ask these questions from your user, use clear and easy words and ask him to answer clearly/using easy words: -> What problem you are trying to solve? Only problem, not the solution. -> Who has this problem? What audience you are going to target? students? labours? founders? what exactly? -> What solution the user is implementing to solve that problem?
• If the user answers with a BROAD audience ("all businesses", "everyone", "anyone who uses X", "small and medium companies", "all students"), DO NOT accept it silently. This is a red flag.
• Push back: "That's N different buyers with N different budgets, pains, and buying behaviors — picking 'all' makes the product solve nothing for anyone. Pick the ONE you'd build first."
• If needed, prompt with concrete choices (e.g., "cash-poor solo micro-owner" vs "SMB team with a budget" vs "enterprise").
• If the user refuses to narrow, guess the single best segment using this rule: choose the audience the stated problem HITS THE MOST (phase 1 audience-deciding rule), say it explicitly, and note in audience.md that this is an assumption the user declined to confirm.
• WRITE THE CHOSEN SPECIFIC AUDIENCE into audience.md. Do NOT proceed to later phases carrying a vague "all businesses" audience - it will corrupt market sizing, competitor analysis, and your verdict.
• Ask these questions at most one clarification round. If still ambiguous, make assumptions explicitly and continue.
• If you didn't understand any of the answers, try to get the answer using the answer of other question. Map them and connect the dots. For example, if user is vague about what problem they are solving, then you can use the answer of the third question to understand what problem it is solving(not "WHAT IT CAN", but "WHAT IT IS SOLVING"). If he is vague about what audience he is targeting, then using the problem and solution approach, find out which audience it affects the most. For example if its related to study -> Student or teachers, if its related to research -> researchers, if its related to coding -> SWE/devs, etc. If you are deciding the audience, then choosen AUDIENCE MUST BE BASED ON THE AMOUNT/AREA THAT THE STATED PROBLEM ABOVE AFFECTS THE MOST. For example if the problem is study related -> then it'll definitely effect student the most then teachers.
• Now put problem in problem_statement.md file, audience in audience.md file AND solution in solution.md file.

Phase 2 - Basic research

• Now search the internet to get the ACCURATE answers for these questions: -> Does this problem actually exists? Put this in problem_statement.md file. -> Is the problem we're trying to solve really painful? or it is just "2 in 100 times" problem? How costly is it? How often? Put this in problem_statement.md file. -> Is our solution really fix the problem? Put this in solution.md file. -> Is the problem already solved? already solved mean that SOMEONE HAS ALREADY PROVIDE EVERY SINGLE FEATURE THAT WE ARE PROVIDING. Put this in problem_statement.md file. -> How much our targeted audience shares the market? Is it growing or not? For example, students shares 13% of the market. Put this in market.md file. -> How big is the business opportunity to solve this problem? Look for TAM, SAM, Market growth, CAGR, Industry revenue, etc. Put this in the market.md file.
• If our solution doesn't fix the problem, stop here, tell the user exactly why, provide strong evidences, reasoning, use easy words. ASK HIM TO PIVOT OR QUIT.
• If the market share of our targeted audience is very short like <2% and our project requires heavy work, then tell the user that ROI is very low and ASK HIM TO CONTINUE OR PIVOT. If says continue, then move to the next step. DO THE SAME THING FOR THE FIRST QUESTION, IF THE PROBLEM ISN'T PAINFUL AND IS "2 in 100% of the times", do the same thing.

Phase 3 - Finding and grouping Competitors

• Now we will research for competitors. Not just famous ones, BUT EVERY SINGLE ONE.
• Find competitors. It doesn't matter if they are Enterprise, Mid-size, Startup, Open source, Side projects, famous or not famous. A COMPETITOR IS A COMPETITOR. Look for information such as: funding. revenue(estimated one if the actual revenue isn't public), pricing, employees, business model, launch year, open source/commercial, market virgin, loss, free/freemium/premium, monthly subscription price, etc.
• Now group the competitors like this: -> Tier 1 -> For Large companies -> Tier 2 -> For Direct competitors -> Tier 3 -> For Indirect competitors
• Now put these group of competitors with all of their available information in competitors.md file. Put every single information for each competitor.

Phase 4 - Head-to-head feature comparison

• Now ignore branding, ignore funding, ignore "backed by google". Compare raw features of them to features of our solution/product.
• For each competitor you saved in phase 3, search for their features. AND FIND EVERY SINGLE FEATURE FOR EACH COMPETITOR.
• Now create a clean and structured table in competitors.md file and create a comprehensive comparison table, something like this, SubZero is our product idea in this example(this is just an example):

"| Tool | Model | Price | Bank Login? | Approach | |---|---|---|---|---| | Subtracker.com.au | Upload statement → AI finds subs | One-time $12.99 | ❌ | ⚠️ NEAR-IDENTICAL to SubZero. Upload PDF/CSV/image, in-memory processing, no data stored, AI extraction | | SubFind (Android) | Upload PDF/CSV + manual | Freemium | ❌ | AI scans statement, privacy-first | | Finny | AI detection | Free | ❌ | No bank connection, AI-powered | | Subflix | Local tracking | Free/OSS | ❌ | Completely local, no cloud at all | | SubGuard | Statement upload + AI | Free | ❌ | AI-powered recurring detection | | Skwad | Email alerts | Free | ❌ | Uses bank email alerts instead of login | | Subpilot | AI scan + auto-cancel | Subscription | ❌ | Newest — AI that can actually cancel for you |"

Phase 5 - Destroy your own assumptions

• Ask "What do I think is unique in this product/idea/project?". Then try to prove yourself wrong where you are wrong.
• For example: "Our X feature is unique -> research about this, checked if anyone else provide this similar feature -> This is not unique, it already exists".
• Then create something like this in competitors.md file and AGAIN, SubZero is the product idea in this example:

"### What SubZero's spec claims as unique:

• ✅ No Plaid / no bank login → Already claimed by 7+ tools
• ✅ Privacy-first / stateless processing → Subtracker does exactly this
• ✅ Heuristic + sparse LLM → Good architecture, but NOT a user-facing differentiator
• ✅ CSV/PDF upload → Standard across privacy-first tier
• ✅ Recurring detection → Everyone does this
• ✅ Hidden fee increase detection → This IS still underserved ⭐

The brutal reality:

Subtracker.com.au is doing essentially what SubZero proposes, down to the "one-time payment, not a subscription" positioning, statement upload, and in-memory processing. It was built as a side project by an Australian dev studio and has gained traction on OzBargain and Reddit."

Phase 6 - Gap Analysis

• Now ask "What we have, that our competitors don't have?". Find their gaps that we can fill, features that we can provide, bottlenecks we can simplify.
• Then put something like this in competitors.md file(AGAIN, this is just an example):

"| Gap | Details | |---|---| | ⭐ Hidden fee increase detection | Almost nobody alerts users to price hikes on existing subscriptions (e.g., Netflix quietly raising from $15.99 → $17.99). This requires historical comparison across multiple statement uploads — a genuine differentiator | | ⭐ Subscription "health score" / audit report | Most tools just list found subs. Nobody produces an audit-style report with prioritized savings, risk scores, and actionable cancel-now vs. negotiate recommendations | | ⭐ SMB / small business statements | Almost all tools target consumers. Business bank statements with 50-200+ transactions are underserved | | Cross-platform statement format support | CSV/PDF is standard but every bank formats differently. Robust format handling is still weak across all competitors | | International / non-US banking formats | Subtracker is AU-focused. Most tools assume US/UK statement formats |"

• The gaps are opportunities.

Phase 7 - Evaluate moat

• Now rate every advantage/moat/feature we have. Not emotionally, but OBJECTIVELY, MATHEMATICALLY AND LOGICALLY.
• For example: "Our X feature/advantage/moat is weak because everyone has it", "Our Y feature/advantage/moat is weak it it doesn't add any value to the product", "Our Z feature/advantage/moat is strong because nobody offers it but it adds value", etc.
• Then create something like this in competitors.md file, again, its just an example :

"| Claimed Moat | Strength | Assessment | |---|---|---| | Privacy-first / no bank login | ❌ Weak | 7+ tools already do this | | Stateless in-memory processing | ⚠️ Moderate | Subtracker does this, but it's not widely marketed as a feature users care about | | Heuristic + sparse LLM | ⚠️ Moderate | Technically elegant, but users don't buy "architecture" | | CSV/PDF upload | ❌ Weak | Table stakes in this category | | Hidden fee increase tracking | ✅ Strong | Genuine gap — nobody does this well | | Audit report format | ✅ Strong | Differentiates from simple "list of subs" output | | One-time pricing (not a subscription) | ✅ Good | Subtracker proved this works, but the market can support multiple players | | AI extraction | weak | privacy concerns on financial data |"

Phase 8 - Outcomes Risk analysis

• Now ask "If I'll launch it tomorrow, what happens realistically?".
• Possibilities varies on data. But an example of outcomes: "Already crowded -> Hard marketing -> No differentiation -> Expensive acquisition"
• Don't pretend that everything is amazing.
• Put this in solution.md file.

Phase 9 - Final decision

• Some possible conclusions: "BUILD IT", "DON'T BUILD IT", "PIVOT FIRST" OR conditional go, something like "Build only if..."
• If conditional go or pivot, then go with phase 10 else go straight to phase 11.
• IF the verdict is "CONDITIONAL GO", it is NOT complete until you state a written FALSIFICATION TEST: a specific, observable condition or evidence that would flip it to NO-GO. Something like: -> "NO-GO if: a funded competitor launches a $0 on-device passive-memory CRM within 6 months" or "NO-GO if: messaging notification-access gets banned / deprecates." -> The test must be concrete enough that it can be checked later with data, not a vibe. It gives us an honest exit gate and stops 'CONDITIONAL GO' from being an unkillable 'maybe'.
• Additionally, if "CONDITIONAL GO", list the build CONDITIONS explicitly (the "Build only if X, Y, Z"), and require a re-run of the validation when those conditions change.

Phase 10 - Pivot

• Ask "How do we avoid becoming another clone?". Find features or services that we can provide by looking into the gaps that you saved in phase 6.
• Turn gaps into opportunities: Gap -> Feature -> Positioning -> Audience -> Business model
• Example of SubZero: "Gap found: Price increase detection -> Feature we can provide: Historical comparison -> Positioning: We detect silent subscription price hikes -> Audience: Consumers -> Business model: One-time audit
• Put something like this in the solution.md file, example of SubZero:

"### Pivot Points:

1. 🔥 Feature: Subscription Price Hike Detection — Track across multiple uploads, alert when a recurring charge increases. Nobody does this well.
2. 🔥 Format: Financial Audit Report — Not just a list, but a structured audit with savings tiers, cancel priorities, and negotiation suggestions.
3. 🔥 Market: Small Business / Freelancer Focus — Business statements with higher transaction volumes, complex vendor lists, and bigger financial stakes.
4. 🔥 Angle: "One-time audit, not a tracker" — Position as a financial diagnostic tool, not an ongoing subscription manager. You upload once, get your audit, done. Completely different positioning from Rocket Money.

If you build as-is (without pivoting):

• Expect to compete directly with Subtracker, SubFind, Finny, SubGuard, Subpilot
• No clear differentiator beyond architecture elegance
• High risk of being a "yet another subscription tracker" noise entry

If you pivot with the gaps above:

• Clear differentiation from ALL existing players
• Stronger narrative: "We don't track — we audit. We find what others miss: the silent price hikes."
• Addresses a real pain point nobody has solved"
• Continue with Phase 11

Phase 11 - Final report

• Write the final MAIN.md file. Read the files that you written in phase 1 for context.
• Use dividers after each section to keep it clean.
• The report should follow this exact format -> examples/example-report.md
• Summary of the format:

Market Research Report

│
├── 1. Market Demand
│     ├── Metrics Table
│     └── Verdict
│
├── 2. Competitor Landscape
│     ├── Tier 1
│     │     └── Table
│     ├── Tier 2
│     │     └── Table
│     ├── Tier 3
│     │     └── Table
│
├── 3. Is the Problem Already Solved?
│     ├── Claimed Uniqueness
│     ├── Brutal Reality
│     └── Gap Analysis Table
│
├── 4. Competitive Moat Assessment
│     └── Moat Table
│
├── 5. Final Verdict
│     ├── Overall Rating (GO / CONDITIONAL GO / NO GO)
│     ├── Executive Summary
│     ├── Positive Evidence
│     ├── Pivot Recommendations
│     ├── Build Conditions (the "IF")
│     ├── Falsification Test (what evidence flips it to NO-GO)
│     ├── If Built As-Is
│     └── If Pivoted
│
└── Closing Prompt