Pol Probe by @deanpeters

Purpose

Define and document a Proof of Life (PoL) probe—a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Use this when you need to eliminate a specific risk or test a narrow hypothesis without building production-quality software. PoL probes are reconnaissance missions, not MVPs—they're meant to be deleted, not scaled.

This framework prevents prototype theater (expensive demos that impress stakeholders but teach nothing) and forces you to match validation method to actual learning goal.

Input

Works best with: The hypothesis or risk you need to test. Also useful: What evidence would change your mind, available time/resources, and what you've validated already.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the hypothesis and the riskiest assumption inside it before designing the probe.

Example invocation: Define a PoL probe: we believe restaurant managers will photograph invoices daily if it auto-updates food costs.

Key Concepts

What is a PoL Probe?

A Proof of Life (PoL) probe is a deliberate, disposable validation experiment designed to answer one specific question as cheaply and quickly as possible. It's not a product, not an MVP, not a pilot—it's a targeted truth-seeking mission.

Characteristic	What It Means	Why It Matters
Lightweight	Minimal resource investment (hours/days, not weeks)	If it's expensive, you'll avoid killing it when the data says to
Disposable	Explicitly planned for deletion, not scaling	Prevents sunk-cost fallacy and scope creep
Narrow Scope	Tests one specific hypothesis or risk	Broad experiments yield ambiguous results
Brutally Honest	Surfaces harsh truths, not vanity metrics	Polite data is useless data
Tiny & Focused	Reconnaissance missions, never MVPs	Small surface area = faster learning cycles

Dimension	PoL Probe	MVP
Purpose	De-risk decisions through narrow hypothesis testing	Justify ideas or defend roadmap direction
Scope	Single question, single risk	Smallest shippable product increment
Lifespan	Hours to days, then deleted	Weeks to months, then iterated
Audience	Internal team + narrow user sample	Real customers in production
Fidelity	Just enough illusion to catch signals	Production-quality (or close)
Outcome	Learn what doesn't work	Learn what does work (and ship it)

Type	Core Question	Timeline	Tools/Methods	When to Use
1. Feasibility Checks	"Can we build this?"	1-2 days	GenAI prompt chains, API tests, data integrity sweeps, spike-and-delete code	Technical risk is unknown; third-party dependencies unclear
2. Task-Focused Tests	"Can users complete this job without friction?"	2-5 days	Optimal Workshop, UsabilityHub, task flows	Critical moments (field labels, decision points, drop-off zones) need validation
3. Narrative Prototypes	"Does this workflow earn stakeholder buy-in?"	1-3 days	Loom walkthroughs, Sora/Synthesia videos, slideware storyboards	You need to "tell vs. test"—share the story, measure interest
4. Synthetic Data Simulations	"Can we model this without production risk?"	2-4 days	Synthea (user simulation), DataStax LangFlow (prompt logic testing)	Edge case exploration; unknown-unknown surfacing
5. Vibe-Coded PoL Probes	"Will this solution survive real user contact?"	2-3 days	ChatGPT Canvas + Replit + Airtable = "Frankensoft"	You need user feedback on workflow/UX, but not production-grade code

Pol Probe

Purpose

Input

Key Concepts

What is a PoL Probe?

The 5 Essential Characteristics

PoL Probe vs. MVP

The 5 Prototype Flavors

When to Use a PoL Probe

Application

PoL Probe Template

Quality Checklist

Examples

Common Pitfalls

References

Related Skills

External Frameworks

Tools Mentioned