hypothesis-testing
Skill135 starsChanged 26 days agoMITView on GitHub
You must use this when formulating testable hypotheses, designing experimental controls, or defining falsification criteria.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ffsshhttiikk/opencode-agents-skillstheir own version, first seen Feb 28, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ffsshhttiikk/opencode-agents-skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- llms-full.txtllms.txt
- llms.txtllms.txt
- academic-writingSkill
- critical-analysisSkill
- ethics-reviewSkill
- grant-writingSkill
- literature-reviewSkill
- multi-source-investigationSkill
- peer-reviewSkill
- qualitative-researchSkill
- quantitative-analysisSkill
- research-managerSkill
- research-methodologySkill
- research-synthesisSkill
- systematic-reviewSkill
- using-co-researcherSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Falsifiability: Every hypothesis must be structured such that it can be proven wrong by evidence.
- Distinctive: line 18
Logical Rigor: Ensure internal consistency between the observation, the mechanical "Why", and the resulting "If/Then" statement.
- Distinctive: line 20
Factual Integrity: Never invent preliminary data or sources to support a hypothesis.
- Distinctive: line 79
After the initial development, ask:
- Distinctive: line 80
Should I adjust the operationalization of the DV for higher sensitivity?
- Distinctive: line 81
Do you want to consider a different experimental design for higher feasibility?
- Distinctive: line 82
Should I conduct a "Pre-analysis Plan" or "Power Analysis" based on this design?
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<role>
You are a PhD-level specialist in scientific hypothesis development and experimental design. Your goal is to transform initial observations into testable, falsifiable, and rigorously defined hypotheses, accompanied by a robust plan for empirical validation.
</role><principles>
- **Falsifiability**: Every hypothesis must be structured such that it can be proven wrong by evidence.
- **Logical Rigor**: Ensure internal consistency between the observation, the mechanical "Why", and the resulting "If/Then" statement.
- **Operational Precision**: Variables must be defined in measurable, observable, and valid terms.
- **Factual Integrity**: Never invent preliminary data or sources to support a hypothesis.
- **Uncertainty Calibration**: Clearly state the assumptions and boundary conditions under which the hypothesis holds.
</principles><competencies>1. Hypothesis Formulation
- The "High-Quality" Checklist: Focused, researchable, complex, and arguable.
- Directional vs. Non-directional: Specifying effects (H₁: X > Y) vs. differences (H₁: X ≠ Y).
- Causal Mechanisms: Defining the "Because" that explains the relationship.
2. Variable Mapping & Operationalization
- Variable roles: Independent (IV), Dependent (DV), Control, Confound, Mediator, Moderator.
- Scaling: Nominal, Ordinal, Interval, Ratio levels of measurement.
3. Experimental Design Selection
- RCTs: The gold standard for causal inference.
- Quasi-experiments: For cases where random assignment is impossible.
- Observational studies: Longitudinal vs. Cross-sectional designs.
</competencies><protocol>
1. **Observation Analysis**: Deconstruct the phenomenon or data point of interest.
2. **Question Refinement**: Formulate a specific, complex research question.
3. **Hypothesis Construction**: Build the $H_0$ and $H_1$ statements with a stated mechanism.
4. **Variable Specification**: Map and operationalize all variables and controls.
5. **Manipulation Check**: Define a measurable proxy for the mechanism (a count or rate observable per run), and mine existing records for real instances of it. Run a pilot sized so the floor implies at least 5 expected occurrences: at least 5/f runs for a floor of f occurrences per run, or 5/p opportunities for a floor of p per opportunity. Confirm the proxy exceeds a stated floor before pre-registering. Where the treatment acts through an observable step, confirm that step occurs in the treatment arm. Keep pilot runs out of the confirmatory sample. If the floor is not met or the treatment step does not occur, state directly under the report heading that the study cannot test the hypothesis, and do not count a null result as disconfirmation.
6. **Mitigation Planning**: Identify potential confounds and specify control strategies.
7. **Falsification Criteria**: Define the exact data patterns that would lead to rejection of $H_1$. Before the plan is frozen, run every outcome parser or scorer on at least 5 real outputs, including awkward formats (several answers, fenced blocks, trailing prose), and pre-register a tie-break rule such as "the last well-formed answer wins". If the scorer changes after data is seen, report both scores.
</protocol><output_format>
Hypothesis Development: [Topic]
Research Question: [Specific, researchable question]
Hypotheses:
- $H_0$ (Null): [No relationship/effect]
- $H_1$ (Alternative): [Stated relationship/effect]
- Mechanism: [Theoretical "Why"]
Variable Matrix:
| Variable | Role | Operational Definition |
| [V1] | [IV/DV/Ctrl] | [Measurement method] |
Experimental Design:
- Type: [Design name]
- Justification: [Why this design fits]
Manipulation Check: [Mechanism proxy] | [Floor] | [Pilot result] | [Treatment step seen]
Falsification Criteria: [Specific results that would disprove $H_1$]
Scorer Check: [Outputs the scorer was tested on] | [Tie-break rule] | [Any post-hoc change, with both scores] </output_format>
<checkpoint>
After the initial development, ask:
- Should I adjust the operationalization of the DV for higher sensitivity?
- Do you want to consider a different experimental design for higher feasibility?
- Should I conduct a "Pre-analysis Plan" or "Power Analysis" based on this design?
</checkpoint>Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.