validation-planner
Validation Planner
Overview
This skill turns a chosen opportunity into a real demand test. The goal is not to produce activity. The goal is to create a short validation plan with numeric targets that can prove, narrow, or kill the idea quickly.
The plan should focus on the single biggest unknown, not on validating everything at once.
Load references/experiment-patterns.md when selecting the right validation
motion. Load references/validation-metrics.md when defining thresholds.
When to use
- When a user already has a best bet or chosen opportunity
- When an idea needs validation before building, scaling, or quitting a path
- When a service-first, audience-first, or product-first wedge needs concrete testing steps
Do NOT use when:
- The user still needs help choosing the opportunity itself
- The problem is purely implementation and demand is already proven
Workflow
1. Identify the real unknowns
Name the key risks behind the idea, such as:
- demand risk
- buyer-access risk
- willingness-to-pay risk
- workflow-repeatability risk
- legal-scope risk
Then choose the single biggest unknown. Name it explicitly and explain why it matters more than the others right now.
2. Choose the right validation motion
Pick a test that matches the opportunity:
- Warm outreach and paid pilot
- Marketplace or directory test
- Audience pre-sell or waitlist
- Async product test
- Constraint-change plan for
no_goopportunities
Use the strongest available commitment signal the user can realistically ask for, such as:
- deposit
- paid pilot
- pre-order
- signed implementation slot
- completed checkout
Do not stop at interviews, clicks, opens, or waitlist signups when a stronger signal is feasible.
3. Define numeric success and failure criteria
Every plan should include numbers where possible:
- outreach count
- interview count
- conversion target
- payment target
- activation target
- stop or pivot threshold
Use decision-grade thresholds:
gorevisekill
Briefly justify the numbers based on channel quality, audience size, price point, access level, or sales cycle. Avoid fake precision.
4. Produce the plan
Return both:
- a readable validation plan
- a JSON block using
assets/validation-plan-template.json
Default sections:
Validation ThesisKey Unknowns7-Day PlanSuccess CriteriaKill CriteriaStructured Plan
Also include a brief Why Not The Lower-Signal Alternative explanation when
there is an obvious weaker motion, such as interviews instead of paid pilots.
Checklist
- The plan is testing the biggest unknown, not generic activity
- Numeric success and failure thresholds are explicit
- The motion matches the opportunity and the user's constraints
- The strongest feasible commitment signal is used
- The plan isolates one primary unknown instead of many
- The response includes readable plan and structured JSON
Examples
Example:
Input: Best bet is an HVAC missed-call recovery service with warm owner access.
Output: A 7-day plan with owner interview counts, pilot target counts, an offer statement, and kill criteria tied to urgency and willingness to pay.
Common mistakes
| Mistake | Fix |
|---|---|
| Writing generic activity lists | Tie the plan to a specific unknown and numeric target |
| Validating everything at once | Choose the single biggest risk first |
| No stop condition | Add clear pivot or kill thresholds |
| Using weak signals when stronger ones are feasible | Ask for money, commitments, or defined next steps |
Quick reference
| Operation | How |
|---|---|
| Pick motion | Match the test to the opportunity and buyer access |
| Set targets | Use numeric thresholds from references/validation-metrics.md and justify them briefly |
| Format result | Human-readable plan plus JSON using assets/validation-plan-template.json |
Key principles
- Test the real risk — Validate the biggest uncertainty, not the easiest activity.
- Numbers beat vibes — Use thresholds, counts, and time windows.
- Use the strongest available signal — If money or commitment can be asked for, do not hide behind soft interest metrics.
- Kill fast when needed — A weak idea should be narrowed or stopped, not endlessly studied.
More from accolver/skill-maker
skill-maker
Create or iteratively improve agent skills with eval-driven refinement when the task is to build a new SKILL.md package or tune an existing skill’s trigger accuracy and performance.
26git-conventional-commits
Generate conventional commit messages from staged git changes when the task is to name or format a commit, not to review code or write release notes.
16pdf-toolkit
Operate the bundled PDF scripts to extract, OCR, create, merge, split, or convert PDFs when the task explicitly involves PDF document processing.
14nostr-event-builder
Construct valid Nostr event JSON and tag structures from requirements when the task is to create or validate concrete events rather than choose which NIPs to use.
12error-handling
Standardize application error handling—taxonomy, propagation, response shapes, logging, and correlation IDs—when the task is to improve consistency of existing error behavior across a codebase.
12pr-description
Generate pull-request descriptions from branch diffs when the task is to explain change scope, motivation, testing, risk, and reviewer guidance for a reviewable branch.
12