Falsification-first research skill that actively seeks counter-evidence before supporting evidence to eliminate cognitive biases and ensure rigorous, objective conclusions.
A research skill grounded in Karl Popper's falsificationism. Before gathering supporting evidence, it actively seeks counter-evidence, boundary cases, and contradictory data to eliminate anchoring effects and confirmation bias.
Identify the core claim in the user's query. Restate it as a testable proposition.
Example: "React is better than Vue for large-scale apps" → Hypothesis: React provides superior developer experience, performance, and maintainability for large-scale applications compared to Vue.
Search for evidence that contradicts the hypothesis. Use query patterns such as:
"limitations of [X]", "problems with [X]""[X] vs [Y] disadvantages", "why [X] fails""criticism of [X]", "[X] drawbacks"Record each piece of counter-evidence with its source.
Search for evidence that supports the hypothesis. Compare evidence strength against Step 2.
Analyze contradictions between Steps 2 and 3:
Deliver a conclusion grounded in the weight of evidence, explicitly stating:
# Research Report: [Topic]
## Hypothesis
[Testable proposition extracted from the query]
## Counter-Evidence (Falsification)
| # | Finding | Source | Strength |
|---|---------|--------|----------|
| 1 | ... | ... | High/Med/Low |
## Supporting Evidence (Corroboration)
| # | Finding | Source | Strength |
|---|---------|--------|----------|
| 1 | ... | ... | High/Med/Low |
## Conflict Analysis
[How do the two sides reconcile? Biases detected?]
## Conclusion
- **Verdict**: [Supported / Partially Supported / Weakened / Falsified]
- **Confidence**: [High / Medium / Low]
- **Key caveat**: [Most important limitation]
## Sources
[Numbered list of all referenced URLs]
User: "Should we migrate from REST to GraphQL?"
Step 1 → Hypothesis: GraphQL is a better API architecture than REST for our use case.
Step 2 → Falsification: search "GraphQL limitations", "GraphQL performance problems",
"why companies moved back to REST from GraphQL"
Step 3 → Corroboration: search "GraphQL benefits at scale", "GraphQL migration success"
Step 4 → Reconcile: GraphQL adds complexity for simple CRUD; excels for complex,
nested data queries. N+1 problem requires DataLoader.
Step 5 → Verdict: Partially Supported (context-dependent)
User: "Is serverless the future of backend development?"
Step 1 → Hypothesis: Serverless will replace traditional server architectures.
Step 2 → Falsification: search "serverless cold start problems", "serverless vendor lock-in",
"why we left serverless", "serverless cost at scale"
Step 3 → Corroboration: search "serverless adoption growth", "serverless success stories"
Step 4 → Reconcile: Cost-effective for bursty workloads; expensive for steady high-throughput.
Vendor lock-in is a real concern. Cold starts problematic for latency-sensitive apps.
Step 5 → Verdict: Weakened as universal replacement; Supported for specific workloads