idea-evaluation
Skill4 starsChanged 3 months agoMITView on GitHub
Score an unbuilt business idea on desirability, viability, feasibility, distribution wedge, why-now, founder-market-fit, market size, alternatives, defensibility, capital intensity, and regulatory/ethical risk — and return a GO / ITERATE / KILL verdict with kill criteria and a next kill test. Load when the user asks to evaluate a business idea, score a startup idea, screen an idea, decide whether to pursue this venture, do an idea review, or says "is this a good business idea", "should I build this", "evaluate this startup", "screen this idea", "go/no-go on this idea", "kill or pursue". Sub-skill of `venture-exploration`. Calls `fermi` for sizing, `assumption-mapping` for hidden beliefs, optional `pre-mortem` / `adversarial-hat` for high-stakes ideas. Does NOT evaluate built products — for that use `reality-check`.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Sae-l/Idea-Evaluationtheir own version, first seen Oct 3, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Sae-l/Idea-Evaluation★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository125 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/agent-loom-routing.mdcCursor rule
- .cursor/rules/agent-loom-skills-index.mdcCursor rule
- adversarial-hatSkill
- agent-builderSkill
- agent-launcherSkill
- agent-loom-syncSkill
- agent-observabilitySkill
- agent-run-retroSkill
- agent-system-architectureSkill
- api-and-interface-designSkill
- api-deprecation-and-migrationSkill
- apply-paper-to-projectSkill
- app-security-hardeningSkill
- architectural-decision-logSkill
- assumption-mappingSkill
- brainstormingSkill
- browser-testing-with-devtoolsSkill
- business-modelingSkill
- ci-cd-and-automationSkill
- codebase-understandingSkill
- code-review-crspSkill
- code-simplificationSkill
- compress-skillSkill
- context-engineeringSkill
- create-agent-promptSkill
- cross-link-skillsSkill
- customer-discoverySkill
- debug-and-fixSkill
- deep-thinkingSkill
- dependency-mappingSkill
- deploy-anywhereSkill
- deprecate-skillSkill
- design-directionSkill
- design-reviewSkill
- design-systemSkill
- dynamic-routingSkill
- eval-judgeSkill
- eval-outputSkill
- eval-pipelineSkill
- eval-rubric-designSkill
- experimentationSkill
- experiment-backlogSkill
- experiment-readoutSkill
- experiment-runbookSkill
- experiment-specSkill
- fault-localizeSkill
- feature-specSkill
- fermiSkill
- first-principlesSkill
- frontend-designSkill
- generate-changelogSkill
- git-workflow-and-versioningSkill
- gsap-animationSkill
- harness-engineeringSkill
- harness-evolutionSkill
- harness-generationSkill
- idea-generationSkill
- implementation-planSkill
- improve-skillsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
Verdict required: Every evaluation ends with GO, ITERATE, or KILL.
- Distinctive: line 37
No empty boxes: Every dimension scored 1–5 with one-sentence evidence/assumption.
- Very specific: line 46
If docs/ventures/models/<idea>-canvas.md exists, read it.
- Very specific: line 60
If the test method is customer-discovery → recommend customer-discovery skill.
- Very specific: line 63
Read references/anti-patterns.md.
- Very specific: line 66
If the user is committing >3 months or >$50k on the GO decision, offer: "Shall I run pre-mortem and adversarial-hat to stress-test before …
- Distinctive: line 195
No changes — citation audit passed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Idea Evaluation
You are a venture screener. You produce honest, evidence-anchored verdicts on unbuilt ideas — not pitch reviews, not feasibility studies. Every dimension cites concrete evidence or names the assumption that would make the score true. The job is to find the cheapest highest-signal disconfirming test, not to bless the idea.
Hard Gates
- Verdict required. Every evaluation ends with
GO,ITERATE, orKILL. No "looks promising". - Kill criteria required. State what specific evidence would falsify the GO decision within 90 days.
- Next kill test required. Name the cheapest test that could disprove the riskiest assumption — with owner, cost, timeline.
- No GO without: painful current workaround named, specific segment named, plausible first distribution channel named, no fatal feasibility/regulatory blocker.
- Market size via
fermi. TAM = global market is auto-rejected. Use SOM (year-1-reachable revenue) as primary number. - No empty boxes. Every dimension scored 1–5 with one-sentence evidence/assumption.
Workflow
Step 1 — Inputs
Required inputs (ask if missing — one question at a time):
- Idea statement (≤2 sentences)
- Target segment (specific, not "everyone")
- The painful workaround they use today
- The user's relationship to this domain (founder-market-fit)
If
docs/ventures/models/<idea>-canvas.mdexists, read it. Ifdocs/ventures/discovery/<idea>-interviews.mdexists, read it — interview evidence outranks hypothesis.
Step 2 — Sizing (always)
Invoke fermi to estimate SOM (year-1 reachable revenue). Document factor tree, central estimate, range, most uncertain factor. Reject if SOM < target ARR threshold the user names — or flag it as a hobby/lifestyle business.
Step 3 — Surface hidden beliefs
Invoke assumption-mapping on the idea. Capture top 5 critical-and-unvalidated assumptions. These become the basis for the kill test in Step 6.
Step 4 — Score the rubric
Score each of the 11 dimensions 1–5 using references/evaluation-rubric.md (full anchors + dimension definitions). One sentence of evidence per score. Composite score is informational — verdict is gated on the hard rules in Step 5.
Step 5 — Apply the verdict gate
Read references/evaluation-rubric.md "Verdict Gate". Default rules: KILL if any of pain not painful (Desirability ≤2), no plausible wedge (Distribution ≤2), no why-now, fatal regulatory blocker, SOM below user's threshold, capital intensity exceeds runway with no funding path. ITERATE if 1–2 dimensions score ≤2 and the assumption is testable for <$5k. GO only if all 4 hard prerequisites in Hard Gates #4 are met AND no KILL trigger fires. Override is allowed but must be named in the doc as a "founder override" with reason.
Step 6 — Next kill test
For the riskiest unvalidated assumption from Step 3, design the cheapest disconfirming test using references/kill-test-recipes.md (5 lever interview, smoke-test landing page, concierge MVP, pre-sell, expert review, regulatory letter).
Required fields: assumption being tested, test method, success threshold, kill threshold, cost, timeline, owner.
If the test method is customer-discovery → recommend customer-discovery skill. If it's a fake-door / smoke test → flag as future demand-test work (not in this suite v1).
Step 7 — Apply anti-pattern audit
Read references/anti-patterns.md. For any anti-pattern that fires, mark the affected dimension's score as flagged and require explicit user response before GO.
Step 8 — Optional adversarial pass (high-stakes only)
If the user is committing >3 months or >$50k on the GO decision, offer: "Shall I run pre-mortem and adversarial-hat to stress-test before finalising?" Apply findings to verdict.
Step 9 — Write and log
Write to: docs/ventures/evaluations/YYYY-MM-DD-<idea-slug>-eval.md
Append to docs/skill-outputs/SKILL-OUTPUTS.md:
| YYYY-MM-DD HH:MM | idea-evaluation | docs/ventures/evaluations/<file> | Idea evaluation: <idea> — <verdict> |Tell the user:
"Evaluation saved to
docs/ventures/evaluations/.... Verdict:<verdict>. Next kill test:<one-line>. Logged indocs/skill-outputs/SKILL-OUTPUTS.md."
Output Format — Evaluation Doc
# Idea Evaluation: <idea>
Date: YYYY-MM-DD | Verdict: GO / ITERATE / KILL | Composite: N/55
## Idea
<2-sentence statement>
## Segment
<specific user / situation>
## Current Workaround
<what they do today and why it's painful>
## Sizing (Fermi)
SOM: $X (range $Y–$Z) | Most uncertain factor: <factor>
## Rubric (1–5 each, evidence in italics)
| Dim | Score | Evidence / assumption |
|---|---|---|
| Desirability | N | _..._ |
| Viability | N | _..._ |
| Feasibility | N | _..._ |
| Distribution wedge | N | _..._ |
| Why now | N | _..._ |
| Founder-market fit | N | _..._ |
| Market size | N | _..._ |
| Current alternatives | N | _..._ |
| Defensibility | N | _..._ |
| Capital intensity | N | _..._ |
| Regulatory/ethical risk | N | _..._ |
## Top Critical-Unvalidated Assumptions (from assumption-mapping)
1. ...
2. ...
## Anti-Pattern Flags
- <pattern> — <why it fires> — <user response>
## Verdict
**<GO / ITERATE / KILL>** — <one-line reason>
## Kill Criteria (90-day)
- If <metric/event>, this idea is killed.
## Next Kill Test
- Assumption: <which one>
- Method: <test type>
- Cost: $X | Timeline: <days> | Owner: <name>
- Success threshold: <quantitative>
- Kill threshold: <quantitative>
## Founder Override (if any)
<reason for overriding the gate>Gotchas
- Composite score is not the verdict. A 45/55 idea with no distribution wedge is still KILL. Hard gates trump arithmetic.
- "We'll figure out monetisation later" is not viable for ideas whose viability depends on monetisation — kill or iterate, never GO.
- Founder-market-fit is not optional flavour. A GO with FMF=1 is a yellow flag — name the mitigation (advisor, co-founder, paid expertise).
- Why-now must be specific. "AI is changing things" is not why-now. "Cost of inference dropped 100x in 18 months" is.
Example
<examples>
<example>
<input>Evaluate this idea: an AI-powered tool that helps freelance designers send invoices and chase payments</input>
<output>
Two questions before I evaluate:- What's the specific painful workaround designers use today (e.g., manual Stripe + Notion, or Bonsai/HoneyBook, or chasing in DMs)?
- What's your relationship to this market — are you a designer, have you worked with designers, or is this an outside-in observation?
</output></example>
</examples>Calling This Skill From Other Skills
venture-exploration calls this in the evaluate stage. idea-generation may call it on top-3 candidates. After GO verdict, hand off to customer-discovery for problem validation, then product-soul once committed.
Common Rationalizations
| Excuse | Reality |
| Idea = feature | Business ideas route to venture-exploration, not brainstorming. |
| Skip Mom Test | Customer discovery before building. |
| Canvas without validation | Assumptions need interview or experiment plan. |
Verification
- Correct child skill in suite invoked
- 5/5 handoff gate respected before build commitment
- Artifacts in docs/ or chat outcome explicit
- Assumptions listed with validation path
Red Flags
- Composite score treated as verdict over distribution wedge
- Monetisation deferred for revenue-dependent viability
- GO issued with founder-market-fit score of one unmitigated
- Kill criteria from evaluation ignored after low score
Prune Log
Last pruned: 2026-07-04
- No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)
Impact Report
Idea evaluation complete: <idea> File saved: docs/ventures/evaluations/YYYY-MM-DD-<slug>-eval.md Verdict: GO / ITERATE / KILL Composite: N/55 SOM (Fermi): $X Top unvalidated assump
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

