Obsidian Experiment Log
- 1 installs
- 3.2k repo stars
- Updated August 4, 2026
- brycewang-stanford/awesome-agent-skills-for-empirical-research
obsidian-experiment-log is a skill that maintains canonical experiment and result notes in an Obsidian research vault as experimental state changes.
About
This skill maintains canonical experiment and result notes in an Obsidian research vault. A developer or researcher uses it when a training run, ablation, evaluation, or finding changes the experimental state, updating existing notes rather than creating sprawl. It matters for keeping empirical-research records structured and linked from papers through to writing.
- Maintains canonical experiment and result notes in an Obsidian vault
- Defines minimum sections for experiment and result notes
- Bridges paper-derived hypotheses to durable results
Obsidian Experiment Log by the numbers
- 1 all-time installs (skills.sh)
- Ranked #1,366 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
obsidian-experiment-log capabilities & compatibility
- Capabilities
- experiment tracking · research notes
- Works with
- obsidian
- Use cases
- documentation · research
- Pricing
- Free
What obsidian-experiment-log says it does
Use this skill whenever project work changes the experimental state.
A result note should exist only when the outcome is stable enough to reference later.
npx skills add https://github.com/brycewang-stanford/awesome-agent-skills-for-empirical-research --skill obsidian-experiment-logAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 3.2k |
| Last updated | August 4, 2026 |
| Repository | brycewang-stanford/awesome-agent-skills-for-empirical-research ↗ |
What it does
Log experiments, ablations, metrics, and durable results into canonical Obsidian experiment and result notes.
Who is it for?
Recording experiment design, runs, metrics, and durable findings as structured Obsidian notes.
Skip if: Storing raw metric dumps or temporary analysis fragments as permanent notes.
When should I use this skill?
When work involves experiment design, ablations, training runs, evaluation, baselines, metrics, failures, or result interpretation.
What you get
Updated canonical experiment and result notes linked into the vault.
- Canonical Experiments/ note
- Canonical Results/ note when a durable finding exists
By the numbers
- 7-section minimum experiment note
- 6-section minimum result note
Files
Obsidian Experiment Log
Use this skill whenever project work changes the experimental state.
Role in the workflow
This is a supporting skill under obsidian-project-memory.
It should help maintain canonical experiment and result notes, not create note sprawl.
Default outputs
- the relevant canonical note in
Experiments/ - the relevant canonical note in
Results/, if a durable finding exists - links from today's
Daily/note - relevant hub or plan references only when project state materially changes
Main rules
- Prefer updating an existing experiment note over creating a sibling note for the same experiment line.
- Prefer updating an existing result note over creating a parallel result page for the same durable finding.
- Raw logs, metric dumps, and temporary analysis fragments should usually stay in
Daily/until they are interpreted. - A result note should exist only when the outcome is stable enough to reference later.
Minimum experiment sections
- Goal / hypothesis
- Code or config entrypoint
- Dataset / split
- Metrics
- Status (
planned,running,done,failed) - Findings / notes
- Next step
Minimum result sections
- Linked experiment
- Main observation
- Key numbers
- Evidence
- Interpretation
- Decision: keep / iterate / discard
Linking rule
Link experiments and results directly to each other, and link both back to 00-Hub.md, 01-Plan.md, or Daily/ only when those references improve the main working surface.
Research path handoff
Treat experiment notes as the bridge between Papers/ and Results/:
- paper-derived hypotheses, baselines, and ablations should land here,
- stable findings should be promoted from here into
Results/, - when a result becomes claim-worthy, update
Writing/rather than leaving the chain unfinished.
Related skills
Lark MarkdownInstantly turn any markdown file into clean, formatted Lark/Figma-compatible documents without manual reformatting.488k
Lark DocCreate, read, update, summarize, rewrite and manage Feishu/Lark cloud documents directly from agent workflows.401k16.1kLark WikiCreate, organize, query, and manage documents, spaces, and members inside Lark (Feishu) knowledge bases directly from AI agent workflows.397k16.1k
Domain ModelingBuild and sharpen a project's domain model: pin down domain terminology in a glossary and record architectural decisions as ADRs.318k202k
Opensource Guide CoachGet expert, attribution-safe guidance on launching and sustaining an open-source project.270k71Readme I18nMaintain consistent, updatable language selector blocks across every README variant in a multilingual repository.270k71FAQ
When should a result note exist?
Only when the outcome is stable enough to reference later.
What sections does an experiment note need?
Goal/hypothesis, code or config entrypoint, dataset/split, metrics, status, findings, and next step.