Skip to main content

hypothesis-design

Converts a clear business goal into a falsifiable hypothesis before implementation begins. Activate when triggered by CF-02 from the release-decision framework, or when a goal exists but there is no explicit causal claim linking a change to an expected outcome. Triggers — "write a hypothesis", "what do we expect", "what should we test", "we think this will work because". Do not use when the hypothesis is already sharp and falsifiable.

Ir a la instalación

Datos de origen

Repositorio
featbit/featbit-release-decision-agent
Última actividad en el origen
5 de mayo de 2026 a las 08:48
Idioma detectado de SKILL.md
inglés
Estrellas
1
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
hypothesis-design
description
Converts a clear business goal into a falsifiable hypothesis before implementation begins. Activate when triggered by CF-02 from the release-decision framework, or when a goal exists but there is no explicit causal claim linking a change to an expected outcome. Triggers — "write a hypothesis", "what do we expect", "what should we test", "we think this will work because". Do not use when the hypothesis is already sharp and falsifiable.
license
Apache-2.0
metadata
{"author":"FeatBit","version":"1.1.0","category":"release-management"}
# Hypothesis Design This skill handles **CF-02: Hypothesis Discipline** from the release-decision framework. Its job is to convert a goal into a testable, falsifiable statement before any implementation or measurement work begins. ## When to Activate - Goal exists but no causal claim links the change to the outcome - User says "we think this will help" without explaining the mechanism - `hypothesis` field is empty or non-falsifiable - User is about to build without stating what they expect ## On Entry — Read Current State Use the `project-sync` skill's `get-experiment` command to load the current project state from the database. Check: - `goal` and `intent` — were they set by `intent-shaping`? If empty, go back to `intent-shaping` first. - `hypothesis`, `change`, `variants`, `primaryMetric` — are they already filled? If so, verify with the user whether to refine or start fresh. - `stage` — confirms where the project is in the loop. This read is required. Do not rely on conversation memory alone — the database is the canonical source. ## Core Template > We believe **[change X]** will **[move metric Y in direction Z]** for **[audience A]**, because **[causal reason R]**. Every component is required. A hypothesis without a causal reason is a hope, not a testable claim. ## Validation Questions Check each component: 1. **Change X** — Is this specific enough to implement? Could two engineers build the same thing from this description? 2. **Metric Y** — Is this measurable? Does instrumentation exist or can it be built? 3. **Direction Z** — Is the direction stated (increase / decrease / maintain)? 4. **Audience A** — Is the target audience specific enough to be segmented in analysis? 5. **Reason R** — Is the causal mechanism explicit? "Because users will like it" is not a reason. ## Decision Actions ### Draft the hypothesis Work with the user to fill all five components. Ask about missing parts one at a time. ### Test for falsifiability Ask: "Under what conditions would we conclude this hypothesis was wrong?" If the answer is "none", it is not falsifiable. ### Sharpen the metric claim The hypothesis does not need a specific number at this stage. It needs a direction. Quantitative targets belong in the evaluation plan, not the hypothesis. ## Operating Rules - Do not proceed to implementation planning until all five components are present - Do not conflate the hypothesis with the success threshold (that belongs in `evidence-analysis`) - Hand off to `reversible-exposure-control` once hypothesis is confirmed ### Persist State Use `Skill("project-sync", ...)` to sync state to the web database. All three writes are required: ```python assert Skill("project-sync", f'update-state {experiment_id} --hypothesis "We believe [change] will [move metric] for [audience] because [reason]" --change "[specific change]" --variants "[control (annotation)|treatment (annotation)]" --primaryMetric "[metric name] — [rationale]" --lastAction "Hypothesis formed"').ok assert Skill("project-sync", f"set-stage {experiment_id} hypothesis").ok assert Skill("project-sync", f'add-activity {experiment_id} --type stage_update --title "Hypothesis formed"').ok ``` ## Execution Procedure ```python def design_hypothesis(project_id, user_message): state = Skill("project-sync", f"get-experiment {project_id}") if state.goal in ("", None): Skill("intent-shaping", project_id) return template = read("references/hypothesis-template.md") # fill all 5 components: change, metric, direction, audience, causal reason # ask about missing parts one at a time # falsifiability check: "under what conditions would we conclude this was wrong?" hypothesis = build_hypothesis(state.goal, template, user_message) assert Skill("project-sync", f'update-state {project_id} --hypothesis "{hypothesis.text}" --change "{hypothesis.change}" --variants "{hypothesis.control} (control)|{hypothesis.treatment} (treatment)" --primaryMetric "{hypothesis.metric} — {hypothesis.metric_rationale}" --lastAction "Hypothesis formed"').ok assert Skill("project-sync", f"set-stage {project_id} hypothesis").ok assert Skill("project-sync", f'add-activity {project_id} --type stage_update --title "Hypothesis formed"').ok Skill("reversible-exposure-control", project_id) ``` ## Signal Inference | Check | Rule | |---|---| | `goal` empty | Redirect to `intent-shaping` before doing any hypothesis work | | `hypothesis` already exists | Verify with user: refine or keep? Do not overwrite without confirmation | | Component missing: change | Ask "What specifically will be built or changed?" | | Component missing: causal reason | Ask "Why do you expect that change to move the metric?" | | Falsifiability fails | Ask "Under what conditions would you conclude the hypothesis was wrong?" | | Metric implied but unnamed | Name it explicitly — do not allow "some engagement metric" to pass | ## Reference Files - [references/hypothesis-template.md](references/hypothesis-template.md) — full template, good/bad examples, falsifiability check, what belongs here vs. in evidence-analysis
Ver en GitHub