Obsidian Research Maintainer

---
name: obsidian-research-maintainer
description: Maintain a project's Research layer in an Obsidian vault — scaffold a research note from a question, spawn experiment tasks with backlinks, roll experiment findings up into the research note, sync open questions, and on conclusion graduate durable findings into Topics. Use when the user wants to start a piece of research, add an experiment to a research question, update a research note from its experiments, review open questions, or conclude a research question. Sibling of obsidian-topic-maintainer; assumes projects under the vault have Research/, Tasks/, Topics/ (and usually Events/) sub-folders.
---

# Obsidian Research Maintainer

Maintains the **Research** layer of an Obsidian project. A research note holds one research question end to end: problem, hypotheses, links to experiments, a rolling summary of findings, and open questions. Experiments are ordinary **Tasks** (`task-type: experiment`) that link back to their research note — no separate experiment structure exists or should be invented. Supporting documents are captured in **Events** and linked from the research note.

This skill is **propose-then-apply** for anything that rewrites existing notes: show what would change and get the user's go-ahead. Creating a fresh research note or experiment task on request needs no confirmation loop.

## Vault model & conventions

- Vault root is typically `~/Documents/Notes`; projects live under `Projects/<Name>/` with `Research/`, `Tasks/`, `Topics/`, and usually `Events/`.
- `Research/Research.md` is the index hub for a project's research notes; the project note links it in its footer line.
- **Every note's H1 is a self wikilink** (`# [[Note Title]]`) followed by a parent link line — `[[Research]]` for research notes.
- British spelling. Generate any timestamp with the shell `date` command, never a guess.
- **Research note** shape (template: `Vault Metadata/Templates/Inputs/research.md`) — no date prefix in the filename; named by a short form of the question:

  ```
  ---
  status: open            # open | concluded
  projects:
    - "[[<Project>]]"
  dateCreated: <ISO8601>
  dateModified: <ISO8601>
  tags:
    - research
  ---
  # [[<Title>]]
  [[Research]]
  ## Problem / ## Hypotheses / ## Experiments / ## Findings / ## Open Questions / ## Documents
  ```

- **Experiment task** = a normal Task note (dated filename, task frontmatter) plus:

  ```
  task-type: experiment
  research:
    - "[[<Research Note>]]"
  ```

and a `[[<Research Note>]]` backlink line under its H1. The task keeps its own Current State, method, Results, Decision Log; links are one-way in prose (task → research), while the research note's **Experiments** section lists its experiment tasks with a one-line description each.

## Division of content — the important rule

- **Experiment task**: everything specific to that run — setup, protocol, raw results, per-experiment decisions, next-session notes.
- **Research note**: only what spans experiments — the question, hypotheses, distilled findings, research-level open questions.
- When in doubt, leave detail in the task and link it. A research note that duplicates a results table has gone wrong.

## Workflows

### Start a research question

1. Ask for the question if not given; agree a short title (the filename).
2. Create `Research/<Title>.md` from the template shape above (shell `date` for timestamps). Write the Problem section from the user's phrasing; draft 2–4 falsifiable Hypotheses and confirm them with the user.
3. Add the note to `Research/Research.md`'s list. Create `Research/` and `Research.md` first if the project lacks them, and add the footer link to the project note.

### Add an experiment

1. Create a Task note (dated filename, matching the project's task conventions) with `task-type: experiment` and the `research:` frontmatter + H1 backlink.
2. List it under the research note's **Experiments** section with a one-line description. Bump `dateModified`.

### Roll up findings

1. Read each linked experiment task's Current State / Results / Decision Log.
2. Propose an updated **Findings** section: short bolded claims, each attributable to an experiment, with an `*Updated: [[<date>]]*` line. Propose which experiment-level open questions have become research-level (move up) and which research questions an experiment has answered (mark or remove, noting the answer in Findings).
3. On approval, apply and bump `dateModified`. Never edit the experiment tasks during roll-up except to fix a missing backlink.

### Conclude a research question

1. Confirm with the user that the question is answered or abandoned; set `status: concluded` and add a dated **Conclusion** section summarising the answer.
2. **Graduate durable findings into Topics**: propose one or more Topic hubs (new or existing) that should carry the evergreen knowledge, in topic-hub voice — concept prose, no experiment enumeration, `## See also` links. Defer to the obsidian-topic-maintainer skill's conventions for hub shape and any promotion to a domain folder.
3. The research note stays in `Research/` as the archived record; the Topic carries the knowledge forward.

### Audit

On request, check across a project: every `task-type: experiment` task has a resolving `research:` link and H1 backlink; every research note's Experiments list matches the tasks that claim it; every open research note has been updated since its newest experiment activity (flag stale ones); `Research.md` lists every research note. Report, then fix approved items.

## Notes

- Do not create per-research sub-folders, an Experiments/ folder, or any structure beyond `Research/` — experiments are Tasks, documents are Events.
- Generalises across projects: point it at any `Projects/<Name>/` and offer to scaffold `Research/` if absent.