菜单
Guide product managers through selecting the right Proof of Life (PoL) probe type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specifi
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Full-stack software engineering via Claude Code CLI session with self-correction.
Review code for correctness, style, security vulnerabilities, and potential issues.
Guide product managers through evaluating whether to scale, test, or kill an acquisition channel based on unit economics (CAC, LTV, payback), customer quality (retention, NRR), and scalability (magic
Assess whether your product work is "AI-first" (using AI to automate existing tasks faster) or "AI-shaped" (fundamentally redesigning how product teams operate around AI capabilities). Use this to eva
Defines the two-axis mental model that distinguishes Director-level thinking from PM thinking: Altitude (how wide you zoom out) and Horizon (how far ahead you look). Use this to understand what actual
Diagnose overall SaaS business health by analyzing growth, retention, unit economics, and capital efficiency metrics together. Use this to identify problems early, prioritize actions by urgency, and d
| name | Pol Probe Advisor |
| description | Guide product managers through selecting the right Proof of Life (PoL) probe type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specifi |
Type: interactive
Guide product managers through selecting the right Proof of Life (PoL) probe type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building.
This is not a tool for deciding if you should validate (you should). It's a decision framework for choosing how to validate most effectively.
Common failure mode: PMs choose validation methods based on tooling comfort ("I know Figma, so I'll design a prototype") rather than learning goal. Result: validate the wrong thing, miss the actual risk.
Solution: Work backwards from the hypothesis. Ask: "What specific risk am I eliminating? What's the cheapest path to harsh truth?"
| Type | Core Question | Best For | Timeline |
|---|---|---|---|
| Feasibility Check | "Can we build this?" | Technical unknowns, API dependencies, data integrity | 1-2 days |
| Task-Focused Test | "Can users complete this job without friction?" | Critical UI moments, field labels, decision points | 2-5 days |
| Narrative Prototype | "Does this workflow earn stakeholder buy-in?" | Storytelling, explaining complex flows, alignment | 1-3 days |
| Synthetic Data Simulation | "Can we model this without production risk?" | Edge cases, unknown-unknowns, statistical modeling | 2-4 days |
| Vibe-Coded PoL Probe | "Will this solution survive real user contact?" | Workflow/UX validation with real interactions | 2-3 days |
Golden Rule: "Use the cheapest prototype that tells the harshest truth."
✅ Use this when:
❌ Don't use this when:
problem-statement.md or problem-framing-canvas.md first)Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
This interactive skill uses adaptive questioning to recommend the right PoL probe type based on your context.
Agent asks:
Let's figure out which PoL probe type is right for your validation needs. First, I need some context:
1. What hypothesis are you testing? (Describe in one sentence, or use "If [we do X] for [persona], then [outcome]" format)
2. What specific risk are you trying to eliminate? Examples:
3. What's your timeline?
4. What resources do you have available? Examples:
Agent synthesizes user input and asks:
Based on your hypothesis and risk, which of these core questions are you really trying to answer?
Offer 5 options (aligned to probe types):
User response: [Select one number, or describe if none fit]
Based on user selection, agent recommends the matching probe type:
→ Recommended Probe: Feasibility Check
What it is: A 1-2 day spike-and-delete test to surface technical risk. Not meant to impress anyone—meant to reveal blockers fast.
Methods:
Timeline: 1-2 days
Tools:
Success Criteria Example:
Disposal Plan: Delete all spike code after documenting findings.
Next Step: Would you like me to generate a pol-probe artifact documenting this feasibility check?
→ Recommended Probe: Task-Focused Test
What it is: Validate critical moments—field labels, decision points, navigation, drop-off zones—using specialized testing tools. Focus on observable task completion, not opinions.
Methods:
Timeline: 2-5 days
Tools:
Success Criteria Example:
Disposal Plan: Archive session recordings, document learnings, delete test prototype.
Next Step: Would you like me to generate a pol-probe artifact documenting this task-focused test?
→ Recommended Probe: Narrative Prototype
What it is: Tell the story, don't test the interface. Use video walkthroughs or slideware storyboards to explain workflows and measure interest. This is "tell vs. test"—you're validating the narrative, not the UI.
Methods:
storyboard.md component skill)Timeline: 1-3 days
Tools:
Success Criteria Example:
Disposal Plan: Archive video, document feedback, delete supporting files.
Next Step: Would you like me to generate a pol-probe artifact documenting this narrative prototype?
→ Recommended Probe: Synthetic Data Simulation
What it is: Use simulated users, synthetic data, or prompt logic testing to explore edge cases and unknown-unknowns without touching production. Think "wind tunnel testing, cheaper than postmortem."
Methods:
Timeline: 2-4 days
Tools:
Success Criteria Example:
Disposal Plan: Delete synthetic data, archive findings, document edge cases.
Next Step: Would you like me to generate a pol-probe artifact documenting this synthetic data simulation?
→ Recommended Probe: Vibe-Coded PoL Probe
What it is: A Frankensoft stack (ChatGPT Canvas + Replit + Airtable) that creates just enough illusion for users to interact with a semi-functional workflow. Not production-grade—just enough to catch UX/workflow signals in 48 hours.
⚠️ Warning: This is the riskiest probe type. It looks real enough to confuse momentum with maturity. Use only when you need real user contact and other methods won't suffice.
Methods:
Timeline: 2-3 days
Stack Example:
Success Criteria Example:
Disposal Plan: Delete all code after user sessions, archive Loom recordings, document learnings.
Next Step: Would you like me to generate a pol-probe artifact documenting this vibe-coded probe?
Agent offers:
I recommend using [selected probe type] for your hypothesis. Would you like me to:
pol-probe artifact (using the pol-probe.md template) with your hypothesis, success criteria, timeline, and disposal plan?User selects option, and agent executes accordingly.
If user is uncertain or hypothesis is too broad:
Agent asks:
Your hypothesis seems broad or tests multiple things at once. PoL probes work best when they're narrow and falsifiable. Let me ask a few clarifying questions:
Clarifying Questions:
Agent then re-recommends probe type based on refined hypothesis.
User Context:
Agent Reasoning:
Recommendation: Task-Focused Test using UsabilityHub
User Context:
Agent Reasoning:
Recommendation: Feasibility Check using prompt engineering spike
Outcome: Error rate was 18%. Decided NOT to build feature. Saved 6 weeks of development.
User Context:
Agent Reasoning:
Recommendation: Narrative Prototype using Loom walkthrough
Why NOT Vibe-Coded Probe: You don't need users to interact with security settings—you need them to understand the concept. Narrative is cheaper and faster.
User Context:
Agent Response:
⚠️ This is prototype theater, not a PoL probe.
You're testing internal politics, not user behavior or technical feasibility. PoL probes eliminate product risk, not organizational risk.
Recommendation: Skip the prototype entirely. Instead:
If executives need a demo, build it after you've validated the hypothesis with real users.
Failure Mode: "I know Figma, so I'll design a UI prototype" (even if design isn't the risk).
Consequence: Validate the wrong thing; miss the actual risk.
Fix: Answer the core question first, then pick the method. If you need a Feasibility Check but only know design tools, pair with an engineer for 1 day.
Failure Mode: "Let's just build it and see what happens."
Consequence: 2 weeks of development before learning you tested the wrong hypothesis.
Fix: Ask: "What's the cheapest prototype that tells the harshest truth?" Usually it's NOT code.
Failure Mode: Vibe-Coded probe "looks real," so team treats it like production code.
Consequence: Scope creep, technical debt, resistance to disposal.
Fix: Set disposal date before building. Vibe-Coded probes are Frankensoft by design—celebrate the jank, delete after learning.
Failure Mode: "Let's test the workflow, the pricing, and the UI in one probe."
Consequence: Ambiguous results—you won't know which variable caused failure.
Fix: One probe, one hypothesis. If you have 3 hypotheses, run 3 probes.
Failure Mode: "We'll know it when we see it."
Consequence: No harsh truth—just opinions and vanity metrics.
Fix: Write success criteria before building. Define "pass," "fail," and "learn" thresholds.