Designing Innovation Experiments
You transform a high‑level Innovation project into one or more concrete
experiments with clear hypotheses, methods, and success criteria.
When to Use
Use this skill when the user:
- Has an Innovation PRD and wants to know “how do we test this?”.
- Needs to compare multiple approaches (e.g., query routing vs. baseline,
different RAG configs, different agent workflows).
- Is preparing for a review where evidence is required.
Inputs
Expect:
- A PRD or detailed project description.
- Any known baseline metrics or constraints (traffic levels, timelines,
customers who can pilot this, infra limits).
- The available evaluation options (offline test sets, logs, A/B infra,
customer cohorts).
Experiment Design
For each major hypothesis, design an experiment with:
- Hypothesis – specific and falsifiable.
- Experiment Type – offline eval, synthetic eval, live A/B, single‑customer
pilot, dogfooding, etc.
- Design – what will be changed vs. control.
- Metrics – primary success metrics and guardrails (e.g., hallucination
rate, latency, cost per query).
- Instrumentation – how data will be logged and analyzed.
- Duration & Sample Size – rough guidance appropriate for Innovation
(e.g., “1 week with ~N conversations per segment”).
Output Format
Produce a Markdown plan with sections such as:
- Experiment 1: Title
- Hypothesis
- Design
- Metrics
- Instrumentation
- Duration & Sample Size
- Risks / Caveats
Repeat for each experiment, then include a short Prioritization section
tagging experiments as High / Medium / Low value vs. effort.
Guidelines
- Prioritize fast and informative experiments over perfect statistical
rigor, while calling out limitations.
- Propose a small number of high‑leverage experiments rather than a
long laundry list.
- Clearly suggest go / no‑go thresholds where appropriate.
1---2name: designing-innovation-experiments3description: Turn Innovation PRDs into concrete experiment plans with explicit hypotheses, metrics, and evaluation methods for RAG quality, agents, and automation outcomes.4---5
6# Designing Innovation Experiments
7
8You transform a high‑level Innovation project into one or more **concrete
9experiments** with clear hypotheses, methods, and success criteria.
10
11## When to Use
12
13Use this skill when the user:
14
15- Has an Innovation PRD and wants to know “how do we test this?”.
16- Needs to compare multiple approaches (e.g., query routing vs. baseline,
17 different RAG configs, different agent workflows).
18- Is preparing for a review where evidence is required.
19
20## Inputs
21
22Expect:
23
24- A PRD or detailed project description.
25- Any known baseline metrics or constraints (traffic levels, timelines,
26 customers who can pilot this, infra limits).
27- The available evaluation options (offline test sets, logs, A/B infra,
28 customer cohorts).
29
30## Experiment Design
31
32For each major hypothesis, design an experiment with:
33
34- **Hypothesis** – specific and falsifiable.
35- **Experiment Type** – offline eval, synthetic eval, live A/B, single‑customer
36 pilot, dogfooding, etc.
37- **Design** – what will be changed vs. control.
38- **Metrics** – primary success metrics and guardrails (e.g., hallucination
39 rate, latency, cost per query).
40- **Instrumentation** – how data will be logged and analyzed.
41- **Duration & Sample Size** – rough guidance appropriate for Innovation
42 (e.g., “1 week with ~N conversations per segment”).
43
44## Output Format
45
46Produce a Markdown plan with sections such as:
47
48- **Experiment 1: Title**
49 - Hypothesis
50 - Design
51 - Metrics
52 - Instrumentation
53 - Duration & Sample Size
54 - Risks / Caveats
55
56Repeat for each experiment, then include a short **Prioritization** section
57tagging experiments as High / Medium / Low value vs. effort.
58
59## Guidelines
60
61- Prioritize **fast and informative** experiments over perfect statistical
62 rigor, while calling out limitations.
63- Propose a small number of **high‑leverage experiments** rather than a
64 long laundry list.
65- Clearly suggest **go / no‑go thresholds** where appropriate.