hypotheses
GitHub管理项目可测试假设，支持创建、细化、状态更新及归档。基于证据评估假设健康度，触发网络研究以收集市场信号，并生成验证行动建议。适用于涉及假设、风险或验证策略的对话场景。
Trigger Scenarios
Install
npx skills add davepoon/buildwithclaude --skill hypotheses -g -y
SKILL.md
Frontmatter
{
"name": "hypotheses",
"description": "Manages the project's testable hypotheses — surfacing new ones, refining existing ones, updating status, reviewing the full set, and assessing hypothesis state based on evidence gathered so far. Use when the conversation touches assumptions, risks, what to validate, hypotheses, interview prep, assessing which hypotheses are confirmed or invalidated, reviewing overall hypothesis health, or when the user questions whether something about their idea is true."
}
Hypotheses
Helps the user surface, refine, and manage testable assumptions about their idea. These hypotheses are the foundation for interview scripts, surveys, and validation experiments.
Before you start
Read startup/core.md to load project context (name, seed description, and all fields under ## Core).
Check if startup/hypotheses/ contains any .md files.
When hypotheses already exist
Load and understand them for context. Infer intent from the conversation — don't mechanically ask "what do you want to do?" If the user is:
- Talking about a specific assumption — help them refine or update the matching hypothesis
- Questioning new assumptions — help shape new hypotheses following the conventions below
- Reviewing the full set — summarize what exists, grouped by tag type, with status
- Updating status — read the file, propose the status change, get confirmation, write it back
- Archiving — when a hypothesis is no longer relevant (e.g., after a pivot), set
status: archivedand addarchived_reasonto frontmatter with a one-line explanation. Archived hypotheses stay in place — they can be restored by flipping the status back - Wanting web research on a hypothesis — dispatch the
web-researcheragent (fast model) with a focused prompt: include the hypothesis statement, the problem space fromcore.md, and ask for community signals (Reddit, forums), existing workarounds, and willingness-to-pay evidence. Incorporate key findings into the hypothesis## Notessection. Save the full web-researcher output tostartup/research/{YYYY-MM-DD}-{hypothesis-slug}-research.mdwith frontmatterdate,topic, andsource_skill: hypotheses
When adding or updating hypotheses, follow the file conventions:
- YAML frontmatter with
status(untested,confirmed,invalidated, orarchived) - Optional
last_assessedISO date (YYYY-MM-DD) — set by assessments, not on creation - H1 heading: the hypothesis as a testable statement
- Obsidian tag on the next line:
#problem,#solution,#willingness_to_pay,#urgency, or#other - Description: what the assumption is, why it matters, what changes if it's wrong
- Optional
## Notessection - Optional
## Next Actionsection — the smallest observable next validation move. Advisory and generated by assessments (see below), not authored by hand. No required internal structure: a tight one-sentence directive is the norm. It is overwritten on each assessment, always reflecting the latest reasoning — not an append-only log.
Slug convention: lowercase the title, replace spaces and non-alphanumeric characters with hyphens, collapse multiple hyphens.
Read before writing, propose before saving, get confirmation.
When no hypotheses exist
Check if startup/core.md has at minimum Audience and Problem defined under ## Core.
- If not: Mention that fleshing out the core idea first would help — strongly suggest to do it first, and if the user agrees, invoke the
whats-nextskill to initialize the project, and then you can come back to hypotheses. But do not block: if the user insists to work on hypotheses now, proceed. - If yes (or user insists): Load the reference file for the guided first-time conversation:
.claude/skills/hypotheses/references/initial-hypotheses.md
The reference file's instructions take over from this point.
Assessing hypothesis state
State assessment is one of this skill's core capabilities. When hypothesis state is in question, dispatch the hypotheses-manager subagent rather than evaluating evidence inline — it's bias-isolated, reads across interview evidence independently, and returns structured recommendations.
When to dispatch:
- The user asks directly about hypothesis health ("how are my hypotheses looking?", "what do we know so far?", "any hypothesis ready to confirm?", "which of these are we still guessing on?")
- Right after an interview has been analyzed and new
[[slug]]backlinks have arrived (this is wired in automatically by theinterviewsskill's post-transcript flow — you'll see that path in the interviews skill) - You're orienting the user on what to do next and hypothesis state is material to the decision
- The user questions whether a specific hypothesis still holds, or whether a cross-interview pattern deserves a new hypothesis
What to pass:
slugs: the keywordall(or a specific list if the conversation is about particular hypotheses)scope: include instruction to also synthesize candidate new hypotheses from unlinked statements across interview files
What comes back: a structured block of state recommendations — each with a What changed line, reasoning, evidence pointers, and a Next action — plus a single cross-hypothesis Top pick and any candidate new hypotheses. The subagent never edits files.
What to do with the result:
- First (no user confirmation needed) — eager bookkeeping: for every hypothesis the subagent actually evaluated, update two things in its file:
- Its
last_assessedfrontmatter to today's date. - Its
## Next Actionsection to the subagent's suggested next action (create the section if absent, overwrite it if present). Both are mechanical, advisory bookkeeping — a factual record of what the subagent recommended against current evidence. Neither changesstatusor the hypothesis body, so neither needs per-item approval. Writing the next action eagerly keeps hypothesis files a live dashboard (thewhats-nextskill reads these sections) and keeps the stability anchor accurate even if the user nods and closes the chat, or if the assessment ran as a byproduct of another flow. (Read the file before writing, so you only touch frontmatter and the## Next Actionsection.)
- Its
- Then surface the state recommendations conversationally — lead each touched hypothesis with what changed → the next action, not just a status. Surface the
Top pickas the single most pressing move. Then any candidate new hypotheses. - For each recommended status change, use this skill's normal propose-before-writing flow — confirm per-item before flipping
status. - For each candidate new hypothesis, get the user's go-ahead before creating a file following the conventions above.
- Do not flip statuses or create new hypothesis files without explicit per-item confirmation.
This is the same subagent dispatched by the interviews skill after a transcript is analyzed — so state assessment is centralized here regardless of which entry point triggers it.
Ad-hoc web search vs. dispatching web-researcher
Not every web question needs a subagent:
- Inline
WebSearch/WebFetch(you, the main agent): single-fact lookups ("is this Reddit thread still active?", "what's the latest on X pricing model?"), quick verification of a claim, one data point asked about in flow. Stays in conversation, no persistence needed. - Dispatch
web-researcher: multi-source validation passes for a specific hypothesis (scanning community signals across Reddit/HN/forums, surveying workarounds, gathering willingness-to-pay evidence). Output is structured and gets saved tostartup/research/{YYYY-MM-DD}-{hypothesis-slug}-research.mdfor later reference — and the findings feed into the hypothesis's## Notessection.
Rough rule: one fact in flow → inline. Multi-source or results-should-persist → dispatch.
Version History
- 502fc01 Current 2026-07-05 15:17
