hypothesis-forge

hypothesis-forge

Hypothesis generation from vault-internal evidence. This skill surfaces the intellectual tension already sitting in the vault — in concept notes, atomic notes, and idea notes — and turns it into draft hypothesis notes ready to file.

Vault-internal only. No web search, no external literature lookup. Every citekey in the output must already exist in the vault.

---

Why this skill exists

Hypotheses don't usually arrive as revelations — they accumulate as unresolved tensions across many papers. A concept note's "Tensions / unresolved" section captures exactly this: places where the evidence pulls in different directions. Atomic notes' Counter-claims fields record where a paper pushes back on the vault's emerging views. Papers marked changed_my_thinking: yes signal that the evidence forced a revision of priors. Recent idea notes capture half-formed hunches that deserve formalisation.

This skill collects all four signals, synthesises them into candidate hypotheses, and formats each one as a ready-to-file hypothesis note stub (using Templates/Hypothesis Note Template.md). AG then reviews the candidates and decides which to promote by saving the file to Ideas/.

---

Step 1 — Harvest vault evidence

Use the Glob and Read tools (or bash if faster for large sets) to collect four evidence streams. Do all four in parallel.

A. Concept-note tensions and open questions

Find all concept notes: type: concept-note in frontmatter, living in Ideas/. For each concept note, extract:

• The "Current position" paragraph (the claim being defended)
• Each bullet in "Tensions / unresolved" — these are the highest-value raw material
• Each item in "Open questions"
• The list of "Papers using this concept" (wikilinks — these are the supporting papers)

B. Counter-claims in atomic notes

Grep for Counter-claims: across all atomic notes (exclude Ideas/, Zotero_import/, Templates/, skills/, planning docs). Keep only entries where the Counter-claims field is non-empty (not — and not blank). For each non-empty Counter-claims entry, record:

• The citekey of the note (derive from the filename: the part before —)
• The text of the counter-claim
• The wikilinks mentioned (these are the contradicting papers)

C. Papers marked changed_my_thinking: yes

Grep for changed_my_thinking: yes across all atomic notes. For each, read the note's "What this changes for me" section and "Main findings" — these notes contain the vault's revised priors and are the richest source of hypothesis seeds.

D. Recent idea notes

Find all notes with type: idea in Ideas/. Read each one fully. A recent idea note (created in the last 30 days, or whichever exist if the vault is young) is especially valuable — it may contain an incipient falsifiable claim that just needs formalisation.

---

Step 2 — Synthesise candidate hypotheses

With the four evidence streams in hand, reason across them to identify 2–5 hypotheses that:

1. Are genuinely falsifiable — not "X matters" but "X produces Y under condition Z, which can be tested by comparison W."
2. Have at least one supporting AND one challenging paper already in the vault — otherwise the candidate is an open question, not a hypothesis.
3. Connect across streams — the best candidates arise when a concept-note tension overlaps with a changed_my_thinking paper or a Counter-claims entry. This cross-stream overlap is what makes them hypothesis-worthy rather than merely noted.
4. Differ from existing hypothesis notes — check Ideas/ for existing Hypothesis - *.md files. If a candidate duplicates an existing note, skip it or propose it as a refinement rather than a new file.

Prioritise quality over quantity. Three strong candidates beat five weak ones. A strong candidate has:

• A single, clean falsifiable sentence
• ≥2 vault papers on the supporting side
• ≥1 vault paper providing genuine challenge
• A clear prediction that could be tested with data AG plausibly has access to

---

Step 3 — Format and present candidates

Present the candidates in the conversation before writing any files. For each candidate:

### Candidate N — [Short claim]

**Claim:** [One falsifiable sentence]

**Supporting papers:** [citekey1], [citekey2] — one line on why each supports
**Challenging papers:** [citekey3] — one line on the challenge
**Linked concepts:** [[Concept note name]] (from Ideas/)
**Drawn from:** [which evidence stream: tension in concept-note X / counter-claim in citekey Y / changed_my_thinking: citekey Z / idea note: "Idea - ..."]

**Prediction:** [What observable outcome would distinguish this hypothesis from the null?]

**Rough next step:** [Most immediate testable action — dataset, analysis, or literature gap to fill]

Citekey accuracy: Every citekey must be derived from the actual filename of an existing vault note (the part before —). Never construct a citekey from scratch. If uncertain, state the full note title instead.

After presenting all candidates, ask: "Which of these would you like to save as a hypothesis note? I can write any of them to Ideas/ now."

---

Step 4 — Write hypothesis notes on request

If AG confirms one or more candidates, write each as a hypothesis note file using the template structure:

File location: Ideas/ File name: Hypothesis - <short claim in sentence case>.md — 4–6 word claim, no full stop Frontmatter fields:

type: hypothesis
status: candidate
confidence: low        # start low; AG upgrades as evidence accumulates
created: YYYY-MM-DD    # today's date
linked_concepts:       # wikilinks to concept notes that ground the hypothesis
  - "[[Concept name]]"
supporting_papers:     # citekeys (verbatim from vault filenames)
  - citekey1
contradicting_papers:
  - citekey3
linked_project: ""     # leave blank; AG fills in
linked_grant: ""       # leave blank; AG fills in
tags: [hypothesis, topic-tag1, topic-tag2]   # topic tags from Vocabulary.md only

Body sections (follow the Hypothesis Note Template exactly):

• Claim — the single falsifiable sentence
• Evidence for — one bullet per supporting paper; cite the vault note with [[wikilink]] and state why it supports
• Evidence against — one bullet per challenging paper; be honest about the scope of the challenge
• Prediction / test — what observable outcome, what comparison or analysis
• Data or analysis needed — specific datasets or methods; reference AG's existing projects where relevant
• Next step — one concrete action

Tags: Always hypothesis first, then 1–2 topic tags from Vocabulary.md. Do not add the year. Do not invent tags.

---

Step 5 — Update index.md

After writing any hypothesis note, update index.md:

1. Add the new entry to the "Hypotheses (Ideas/)" section with a one-line summary.
2. Increment note_count in the frontmatter.
3. Update the updated date.

---

Scope and limits

• Vault-internal only. Do not call Zotero MCP, do not search external literature. Every claim must trace to a vault note.
• Do not overwrite existing hypothesis notes. If a file with the same name exists, report it and ask before overwriting.
• No invented citekeys. If a paper is mentioned in a concept note but has no atomic note in the vault, cite it by title only, not as a wikilink.
• Trust the Counter-claims field as written — do not reinterpret it; quote or paraphrase faithfully.
• Single vault root. The vault base path is C:\Users\agre6595\OneDrive - The University of Sydney (Staff)\Obsidian\Ecology\.

---

Trigger phrases

Invoke this skill when the user says any of the following:

• "forge hypotheses" / "run hypothesis-forge"
• "generate candidate hypotheses from my vault"
• "what hypotheses can I build from what I've read?"
• "find connections for my recent idea notes"
• "what tensions in my concept notes could become hypotheses?"
• "turn my vault tensions into hypotheses"
• "what could I test from my current reading?"
• "promote tensions to hypotheses"