Research method write-up
Produce one METHOD.md that another researcher, or another agent, can follow without access to the conversation that produced the method.
Steps
- Draw the boundary. State what question the method answers, what it takes in, and what it produces. If the conversation contains several methods, write one file per method.
- Collect provenance first. Who derived it (a person, an agent, or both), which tool and model, which skill or prompt, and on what date. Ask for anything missing instead of guessing.
- Write
METHOD.mdfrom the template below. If the target repository hasmethods/_template/METHOD.md, use that instead, since it may be newer. - Make the procedure executable. Numbered steps, exact commands or equations, parameter defaults, and expected runtime.
- Make validation concrete. Name the test, dataset, or sanity check that shows the method works, and record the numbers actually observed.
- Record limitations and the failure modes seen while developing it.
- Set
statushonestly.draftuntil validation has observed results,validatedonce the checks pass,publishedonce it is cited in a paper.
Rules
- Record only what was actually run or derived. Mark anything untested as untested.
- Keep the file self-contained. Link to code rather than pasting large blocks.
- Prefer plain language. The reader may not share the jargon of the project the method came from.
- Do not invent provenance. An unknown model or date is written as
unknown.
Template
---
name: <folder-name>
description: <one sentence: what it does and when to use it>
status: draft
origin: human | agent | mixed
agent: claude-code | codex | none
model: <model id or unknown>
skill: <link to the SKILL.md used, or empty>
derived: YYYY-MM-DD
---
# <Method name>
## Summary
## Problem
## Inputs and outputs
## Procedure
## Validation
## Limitations and failure modes
## Provenance
## Used in
## References