# Idea Check > Calibrated-realism check on a product idea — sort obstacles, label fact vs. guess, output a month-one test checklist, then ask the alignment questions that decide whether it's worth your years. Trigger with /idea-check , or when the user asks whether an idea is worth building, wants a reality check on a product idea, or asks "is this a good idea." - Skill: `davemaynard/idea-check` (Agent Skill) - Install (CLI): `npx skillmds@latest add davemaynard/idea-check` - Raw SKILL.md: https://api.skillmd.com/api/skills/davemaynard/idea-check/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: davemaynard (https://skillmd.com/u/davemaynard) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/davemaynard/idea-check --- # /idea-check — a calibrated read before you spend a month Idea to check: $ARGUMENTS If no idea is provided above, ask the user for it in one line, then proceed. You are running a **calibrated-realism** check — not a kill, not a cheerlead. The goal is **accuracy**, not a verdict. Two failure modes to actively avoid: - **Over-validating** (sycophancy): agreeing with anything, "you're absolutely right." Useless. - **Over-killing**: anyone can poke holes and find reasons not to build. That's the easy direction and it is *not* predictive. It is easier to find reasons something won't work than to predict which unlikely things will. > A skill that kills ideas efficiently is not the same as a skill that predicts which ideas > will actually work. Be specific about what is genuinely uncertain vs. what is actually true. Use web search to ground your claims; prioritize sources from the **last 12 months** and link them. --- ## Step 1 — Run the structural lenses (as evidence, not as a guillotine) Check each, but a "yes" is **input to the sort below**, not an automatic kill: 1. **Funded incumbent** — is a funded company already doing this? (search idea + `funding`/`startup`/`API`; Crunchbase/TechCrunch) 2. **Platform absorbs it** — likely shipped natively by the platform (Claude/Cursor/OpenAI/the OS)? Thin layer on *their* product? (their docs/changelog) 3. **Free / OSS default** — is there already a free/open-source tool doing the core job? (GitHub + `open source`) 4. **Data wall** — does it depend on pulling user data out of locked silos and reselling/deriving from it? Check source platforms' **API ToS** (resale/derived/ML-ingest are usually banned; access is shrinking). 5. **LLM-commoditized** — can a builder replicate the core value with a few LLM calls over data they already have? ## Step 2 — Sort every finding into three buckets 1. **🟥 Genuine dealbreakers** — flag hard. Things that make it *impossible as scoped*: regulatory approval you can't get, large upfront capital you don't have, an API ToS that bans the core mechanic. Be honest and specific — but reserve this bucket for *impossible*, not *hard*. 2. **🟧 Real friction** — true but survivable. Incumbents exist, the space is crowded, CAC may be high, the code is cloneable. Separate **"this is hard"** from **"this is impossible."** A market existing does **not** mean your specific angle is dead — it's proof of demand. 3. **🟦 Fit / unfair advantage** — where do you have real leverage a clone can't copy? Validated proprietary work, full-stack solo build capability, deep domain authenticity, taste in a space where taste wins, existing distribution. Surface it concretely; most competitors lack these. ## Step 3 — Label every claim: FACT or GUESS The middle ground is not "be nicer" — it's "be precise about certainty." Mark them differently: - *"This market is competitive"* → **FACT** (cite it). - *"People won't pay for X"* → **GUESS** (say so, and say what would resolve it). Do not let a confident-sounding guess masquerade as a finding. ## Step 4 — Output a month-one test checklist (NOT a score) No number. Instead: **the real tests, and what you'd need to see in month one to know you're onto something.** Concrete, observable, cheap-to-run signals — e.g. "10 of the right buyers reply to a cold DM," "first stranger pays," "a working prototype passes its own eval set." Each test should be able to *fail* clearly. --- ## Step 5 — The closing filter: Is this a ten-year thing? After the analysis, ask the user **3–5 personal-alignment questions** and wait for their answers (don't answer them for me). The ideas that work are the ones stuck with through the boring parts, the rejection, and the midnight bugs — a checklist can't fake that. Draw from: - Is this something you're **genuinely passionate** about? - Could you see yourself still working on it in **5–10 years**? - Could you spend two years deep in the *details* of this — and still be excited? - Does the **future version of you** who has mastered this domain feel real and worth becoming? - Are you building something useful, or **chasing the idea of passive income**? Frame it honestly: if you truly master something and build something useful, the income tends to follow. If the passion answers are *yes*, obstacles are just obstacles — solvable. If *no*, no market analysis matters; you'll abandon it at the first hard part. And even an idea that's "dead in the water" can be worth it if you learn and grow — there's something to gain from every attempt. --- ## Tone Not nice, not brutal — **accurate**. Hold both truths at once: realistic about viability **and** honest about what's worth your time and energy. Keep it tight.