Research source code
Skill mriffle/findings-ai-collab-workflow/skills/research-source-code
How to ground a methodological claim in what a tool ACTUALLY computes by reading its source code and documentation, rather than trusting a methods-section description. Use for claims about how software like DIA-NN, limma, MSstats, or a search engine processes data. Output feeds a research-finding.From its SKILL.md
npx -y skills add mriffle/findings-ai-collab-workflow --skill research-source-codeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.1 KB, as published. Nobody here has run it
Researching what a tool actually computes
Methods sections — and prompts, and memory — routinely misdescribe what software actually does. This procedure grounds methodological claims in the source and official documentation, which is independently valuable: a finding's interpretation often hinges on what a tool's number really means.
Procedure
- Identify the exact tool and version. Behavior changes across versions; pin the version (from the locked environment where the tool is part of the pipeline).
- Go to the source/docs of record. The official repository, release docs, and the function/module implementing the step in question. Prefer reading the implementation over secondary descriptions.
- Trace the specific computation. What transformation/normalization/model does it apply? What are the defaults? What does a given output column actually represent (e.g. what "intensity", "q-value", "LFQ", or a moderated statistic means in this tool)? What is silently filtered or imputed?
- Note defaults and silent behavior. Defaults that change results, silent filtering/imputation, and assumptions baked into the tool are exactly what gets misreported — capture them.
- Verify by citation to source. Cite the specific file/function/release-doc (a URL or repo path + version), not a general "the tool does X."
Output
A research-finding (templates/research-finding.md) stating what the tool computes for the step in question, with defaults and caveats, each claim cited to the source/docs (and the version). Software references use type: software with the version. It goes to the research-reviewer, which verifies the sources resolve and support the claims. If you cannot confirm a behavior from the source/docs, record it as unverified rather than asserting it.