Falsification gauntlet
Adversarial stress-testing framework for product ideas. Use when the user wants to rigorously evaluate a product thesis before building—identifying load-bearing assumptions, interrogating moats, testing technical feasibility, and mapping competitive landscape. Designed to KILL weak ideas early or REFINE them into stronger theses. Triggers on phrases like "stress-test this idea", "should I build this", "kill list", "validate my thesis", "is this worth building", or when a user presents a product concept and wants rigorous evaluation before committing resources.From its SKILL.md
npx -y skills add narainio/context-daemon --skill falsification-gauntletAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Falsification Gauntlet
Adversarial stress-testing framework for product ideas. Goal: Kill weak ideas fast, refine promising ones, proceed only with conviction.
Core Principles
- Dialog, not checklist — Multi-turn conversation by design. The user must arrive at conclusions themselves.
- Socratic method — Surface questions, let user reason through. Never declare "this won't work"—guide them to see it.
- User expertise is material — Explicitly prompt for domain knowledge. User knows things Claude doesn't.
- Three outcomes — Kill (clean exit), Proceed (build with conviction), or Refine (thesis needs adjustment)
- Soft exit ramps — If a phase clearly invalidates the thesis, offer to skip ahead. User can override.
Workflow
Before Starting
Create a state file in the working directory. See references/templates.md for the state file template.
[idea-name]-gauntlet-state.md
Update this file after each phase.
Phase 1: Thesis Articulation
Goal: Crystallize the core bet and surface load-bearing assumptions.
Questions to explore:
- What's the core bet in one sentence?
- Who is the customer? What's the acute pain?
- What has to be TRUE for this to work? (List 3-5 load-bearing assumptions)
User expertise prompt:
"Before we dig in—what's your unique insight here? Why do you believe this when others might not?"
Output: Create [idea-name]-phase1-thesis.md using template in references.
Phase 2: Moat Interrogation
Goal: Determine if there's a defensible advantage.
Questions to explore:
- Why you? Why now?
- What's the defensible advantage? (Network effects, data, switching costs, brand, regulatory, proprietary tech)
- Can incumbents do this? Will they?
- Can platforms (Google, Meta, Apple, Amazon) commoditize this?
User expertise prompt:
"Who do you already know is playing in this space or adjacent? What's your read on their trajectory?"
Soft exit ramp (if moat is clearly absent):
"Based on what we've found, there doesn't appear to be a defensible moat here. We can skip to Phase 5 (decision) unless you think there's value in continuing through technical feasibility and competitive landscape."
Output: Create [idea-name]-phase2-moat.md using template in references.
Phase 3: Technical Feasibility
Goal: Determine if we can actually build this.
Questions to explore:
- Can we build this with current technology?
- What's in our control vs. dependent on platforms/APIs/partners?
- Are there hard technical blockers? (API limitations, data access, regulatory)
- What's the build complexity? (Solo founder viable? Requires team?)
Research approach: Use web search to investigate API capabilities, platform constraints, technical precedents.
Soft exit ramp (if technically blocked):
"This appears to be technically blocked by [specific constraint]. We can skip to Phase 5 unless you see a path around this."
Output: Create [idea-name]-phase3-technical.md using template in references.
Phase 4: Competitive Landscape
Goal: Map who else is here and assess commoditization risk.
Questions to explore:
- Who's already here? (Direct competitors)
- Who's adjacent and could enter? (Platform risk, big tech, well-funded startups)
- What's the trajectory? (Growing, consolidating, commoditizing)
- Is there a timing window? (Why now vs. 2 years ago or 2 years from now)
User expertise prompt:
"Any adjacent players I should look at that might not show up in obvious searches?"
Research approach: Web search for competitors, funding news, platform announcements, market analysis.
Output: Create [idea-name]-phase4-competitive.md using template in references.
Phase 5: Decision
Goal: Synthesize findings and reach a decision with conviction.
Process:
- Summarize each load-bearing assumption and its status (Validated / Invalidated / Uncertain)
- Present the three options: Kill, Proceed, Refine
- Ask the user for their gut read
- Let them make the call
User expertise prompt:
"Given everything we've surfaced—what's your gut saying?"
Do NOT make the decision for the user. Present the evidence. Let them conclude.
Output: Create [idea-name]-phase5-decision.md using template in references.
State Management
After each phase:
- Update the state file with phase completion status
- Update load-bearing assumptions with current status
- Capture any key user expertise that surfaced
If context runs out mid-process, the state file + phase outputs enable resumption.
Phase Output Templates
See references/templates.md for all templates:
- State file template
- Phase 1-5 output templates
What ships with it: 1 file
5.3 KB alongside SKILL.md
references/
- templates.md5.3 KB
Gives 0 of the 12 instructions most test skills give in ~1.1k tokens
Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-07
- Close the browser when donein 55 of 964, across 12 files
- Wait for network idle statein 51 of 964, across 6 files
- Launch Chromium in headless modein 49 of 964, across 6 files
- Use descriptive selectors for elementsin 49 of 964, across 6 files
- Run provided scripts with help flag firstin 49 of 964, across 6 files
- Add appropriate explicit waitsin 48 of 964, across 5 files
- Use bundled scripts as black boxesin 46 of 964, across 3 files
- Do not read script source codein 46 of 964, across 3 files
- Use sync playwright for scriptsin 46 of 964, across 3 files
- Inspect dom before executing actionsin 46 of 964, across 3 files
- Run the full test suitein 37 of 964
- Write the failing test firstin 29 of 964, across 23 files
Said here and by no other author read
- maintain a state file across phases
- prompt the user for domain expertise
- guide the user using socratic questioning
- crystallize the core bet and assumptions in phase one
- interrogate defensible advantage in phase two
- test technical feasibility in phase three
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.