Falsifiability test pattern

Skill fabioc-aloha/Alex_Skill_Mall/plugins/code-quality/falsifiability-test-pattern

Plans without measurable success criteria drift into wishful thinking:From its SKILL.md

Install

npx -y skills add fabioc-aloha/Alex_Skill_Mall --skill falsifiability-test-pattern

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 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

2.2 KB, 515 tokens by cl100k_base, as published. Nobody here has run it

Falsifiability Test Pattern

The Problem

Plans without measurable success criteria drift into wishful thinking:

"Improve performance" — how much? by when?
"Better user experience" — measured how?
"Reduce tech debt" — which debt? how will we know?

The Solution

Every deferred or speculative work item declares a measurable rule for success/failure.

## Feature: Caching Layer

**Hypothesis**: Adding Redis caching will reduce API latency by 50%.

**Falsifiability Test**: 
- Measure: p95 latency for /api/users endpoint
- Baseline: 450ms (measured 2026-04-20)
- Target: <225ms
- Window: 30 days post-deployment
- Decision rule: If p95 > 300ms after 30 days, revert and investigate

**Evidence collection**: Datadog dashboard, weekly snapshots

Template

## [Feature/Change Name]

**Hypothesis**: [What you believe will happen]

**Falsifiability Test**:
- Measure: [Specific metric]
- Baseline: [Current value with date]
- Target: [Success threshold]
- Window: [Time to evaluate]
- Decision rule: [What to do if fails]

**Evidence collection**: [How you'll gather data]

Good vs Bad Tests

Bad	Good
"Will be faster"	"p95 latency < 200ms within 14 days"
"Users will like it"	"NPS > 40 after 500 responses"
"Reduces bugs"	"Bug reports for module X < 2/month"
"More maintainable"	"Time to implement similar feature < 2 days"

Decision Rules

| Outcome | Action |
|---------|--------|
| Target met | Keep, document win |
| Partial (80%+) | Keep, note limitation |
| Missed | Revert or iterate |
| Can't measure | Fix instrumentation first |

Verification

Every plan item has a falsifiability test
Tests have specific numbers and dates
Decision rules exist before implementation
Results are recorded

When to Apply

Feature planning
Architecture decisions
Process changes
Any speculative investment