shinpr/nautilus · Archived

hypothesis-discipline

Manages hypothesis lifecycle, enforces validation criteria, time budgets, and confidence scoring rules. Use when creating hypotheses, updating confidence scores, setting validation criteria, handling timeouts, or recording validation results.

First seen Jul 22, 2026

Installation

$ npx skills add shinpr/nautilus --skill hypothesis-discipline

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from shinpr/nautilus · top by installs.

npx skills add shinpr/nautilus

Browse all from shinpr/nautilus

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,859 B
  • docs SUMMARY.md 271 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Hypothesis Discipline

Core Principle

A hypothesis is not a guess. A hypothesis selected for validation needs a clear decision, evidence criteria, and a stopping condition.

Hypothesis Characteristics

  • Hypotheses exist at every level of the OST hierarchy (see product-principles skill)
  • Each hypothesis has a target level attribute indicating which OST level it addresses
  • Hypotheses follow an ADR-style lifecycle — a single file tracks the full journey from draft to conclusion
  • Preserve rejected and invalidated hypotheses as learning assets

Hypothesis Lifecycle

draft → testing → validated → adopted
                            → rejected (validated but not adopted)
              → invalidated (disproven by evidence)
              → inconclusive (evidence gathered but insufficient to confirm or deny)
              → timeout (deadline passed, decision needed: continue or stop)

Hypothesis File Schema

The authoritative schema is defined in references/hypothesis-template.md. Key fields:

  • id: HYPO-NNN
  • level: outcome / opportunity / solution / assumption
  • status: draft / testing / validated / invalidated / inconclusive / adopted / rejected / timeout
  • confidence: scores for the risk dimensions that can change the hypothesis decision, on the product-principles 0-10 scale
  • time-budget and deadline: include when time or calendar limits affect the validation decision

Validation Criteria Requirements

A hypothesis entering validation defines:

  1. We believe that — the hypothesis statement
  2. We'll know we're right when — measurable success criteria
  3. We'll know we're wrong when — measurable failure criteria
  4. Validation method — how we will test (prototype, data analysis, interview, code spike, market research)
  5. Stopping condition — the evidence, time limit, or cost limit that ends this validation

Time Budget and Cutoff

  • Give a validation a time budget when exploration or evidence collection can expand
  • Add a deadline when a calendar cutoff changes the decision
  • When deadline passes without conclusion → status becomes timeout
  • Timeout forces a decision: extend (with justification), pivot, or abandon
  • End validation at its evidence, time, or cost boundary

Confidence Update Rules

  • Confidence scores are updated only when new evidence is gathered
  • Record the evidence that justified each score change
  • Confidence can go down as well as up — negative evidence is valid evidence
  • Different risk dimensions can have different confidence levels

Result Recording

When a hypothesis reaches a conclusion, record the result, changed confidence dimensions, and evidence in the hypothesis file. Carry a learning or parent-Opportunity update into reflection only when the result can change a later decision.

Key Disciplines

  • Separate creation from evaluation: Generate candidates before applying evaluation criteria
  • Seek disconfirming evidence: Actively look for reasons the hypothesis might be wrong
  • One decision per validation: Combine hypotheses when the same evidence resolves the same decision; separate them when bundling would make the result uninterpretable
  • Record decision-relevant evidence: Preserve the evidence and reasoning needed to understand or reuse the conclusion
  • Rejected ≠ worthless: A rejected hypothesis teaches what doesn't work and why
  • Inconclusive is honest: When evidence is insufficient, say so instead of forcing a verdict