Pol ProbeSAFE

Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: pol-probe
argument-hint: "[hypothesis to test]"
description: Define a Proof of Life probe to test a risky hypothesis cheaply. Use when you need harsh truth before building real product.
intent: >-
  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.
type: component
best_for:
  - "Documenting a lightweight validation artifact before build"
  - "Testing a narrow hypothesis without shipping production software"
  - "Reducing risk before spending engineering time"
scenarios:
  - "Define a Proof of Life probe for a new workflow automation idea"
  - "Help me write a PoL probe for this pricing hypothesis"
  - "Create a low-cost validation probe before we build this feature"
theme: validation-experiments
estimated_time: "15-25 min"
---

## 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.

**Origin:** Coined by Dean Peters (Productside), building on Marty Cagan's 2014 work on prototype flavors and Jeff Patton's principle: *"The most expensive way to test your idea is to build production-quality software."*

---

### The 5 Essential Characteristics

Every PoL probe must satisfy these criteria:

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

**Anti-Pattern:** If your "prototype" feels too polished to delete, it's not a PoL probe—it's prototype theater.

---

### PoL Probe vs. MVP

| 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) |

**Key Distinction:** PoL probes are **pre-MVP reconnaissance**. You run probes to decide *if* you should build an MVP, not to launch something.

---

### The 5 Prototype Flavors

Match the probe type to your hypothesis, not your tooling comfort.

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

**Golden Rule:** *"Use the cheapest prototype that tells the harshest truth. If it doesn't sting, it's probably just theater."*

---

### When to Use a PoL Probe

✅ **Use a PoL probe when:**
- You have

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.