recipe-validate

Context: Validate hypotheses using appropriate methods based on risk type. Invoke hypothesis-verifier for bias-free validation design. Record results in hypothesis files.

Required Skills [LOAD BEFORE EXECUTION]

1. [LOAD IF NOT ACTIVE] hypothesis-discipline — lifecycle, evidence, confidence, and stopping conditions
2. [LOAD IF NOT ACTIVE] product-principles — 4 Risks and validation sufficiency

Conditional Skills [LOAD WHEN TRIGGERED]

• WHEN the selected method is prototype validation: [LOAD IF NOT ACTIVE] prototype-guide
• WHEN the selected method uses business-model, market, or viability analysis: [LOAD IF NOT ACTIVE] business-context

Delegate validation design to hypothesis-verifier for bias-free assessment.

Execution Decision Flow

1. Hypothesis Assessment

Input: Use the path or text supplied with the explicit skill invocation. If no input was supplied and the target cannot be inferred unambiguously, ask for it.

Read the target hypothesis file(s). Understand:

• What is being tested (the hypothesis statement)
• Which risk dimension is primary (Value / Usability / Feasibility / Viability)
• Current confidence scores
• Validation stopping condition, including a time budget or deadline when present
• Parent Opportunity context

2. Validation Design

Invoke hypothesis-verifier to design the validation:

• hypothesis-verifier operates in a separate context to prevent confirmation bias
• It designs the test without knowing the orchestrator's expectations
• It defines success/failure criteria independently

Present the validation design to the user when executing it would commit external resources, change the product outcome, or exceed the confirmed time or cost boundary:

• Proposed validation method
• Success and failure criteria
• Required resources and time estimate
• Risk of the validation approach itself

When any of these conditions applies, end the current turn with the validation design as the workflow output. Execute that validation only after the user confirms it in a later turn.

Otherwise, execute local and reversible validation within the confirmed boundary without an additional stop.

3. Validation Execution

Execute validation based on the risk type and method:

Prototype Generation (for Usability validation)

Invoke prototype-generator in a separate context:

1. Pass hypothesis_path as the canonical target hypothesis path.
2. Pass one exact output_path per invocation. Use docs/discovery/prototypes/hypo-{id}-prototype.html by default; when the confirmed validation design requires separate artifacts, use docs/discovery/prototypes/hypo-{id}-{variant}-prototype.html for each artifact.
3. The generator reads the decision-relevant product and design sources directly and writes one self-contained HTML artifact at that path. The validation design determines whether one artifact or separate variant artifacts supply sufficient evidence.
4. Consume its completion report as prototype-readiness evidence. When it returns blocked, resolve only the named incomplete condition before invoking it again.
5. Collect the observations defined by the confirmed validation design before recording a hypothesis result. When observation has not run, report the prototype as ready and validation as pending; use inconclusive only when executed validation produced insufficient evidence.
6. Continue validation and result recording in the parent context; prototype-generator does not update the hypothesis record.

Market Research (for Value/Viability validation)

Use web search to gather market data. See product-principles skill references/mvp-definition.md for scope assessment.

4. Result Recording

After validation execution:

1. Update the hypothesis file:

- Change status (validated / invalidated / inconclusive / timeout) - Update confidence scores with evidence - Record evidence and artifacts - Document a learning when the result can change a later decision

1. Link to validation artifacts (prototypes, data, interview notes)

Present the results to the user:

• Validation outcome (validated / invalidated / inconclusive)
• Updated confidence scores with evidence
• Key learnings
• Next decision, when the result creates one

5. Timeout Handling

When a hypothesis with a deadline reaches it without conclusion:

1. Set status to timeout
2. Present options to user:

- Extend: Add more time with justification - Pivot: Modify the hypothesis based on partial evidence - Abandon: Stop validation, record learnings from partial evidence

Sub-agent Usage

Scope Boundaries

Included: Hypothesis validation design, validation execution, result recording Not included: Hypothesis generation (→ recipe-discover), PRD creation (→ recipe-define), reflection/distillation (→ recipe-reflect)

Completion

The workflow is complete when the hypothesis record contains the validation result and evidence, including a bounded inconclusive or timeout result, and the user has received the next decision when one exists.