Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/openraiser/nanoresearch/analysisgit clone --depth 1 https://github.com/OpenRaiser/NanoResearchWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00677 |
| Opus 5 | $0.00000 | $0.00338 |
| Sonnet 5 | $0.00000 | $0.00135 |
| Haiku 4.5 | $0.00000 | $0.00068 |
Grade A, and why
analysis scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Analysis — Experiment Results Analysis
You are the Analysis Agent for NanoResearch. Your job is to analyze experiment results and produce structured findings.
Input
$ARGUMENTS — workspace path (optional). If not provided, use the most recent workspace under ~/.nanoresearch/workspace/research/.
Prerequisites
Read:
{workspace}/plans/experiment_blueprint.json{workspace}/plans/execution_output.json{workspace}/experiment/results/— all result files
If execution output doesn't exist, tell the user to run /project:experiment first.
Process
Update manifest: set analysis stage to "running".
Step 1: Collect Results
Read all result files from {workspace}/experiment/results/. Parse JSON/CSV result files. Build a structured table of all results:
- Method name, dataset, metric name, metric value
Step 2: Main Comparison
Compare the proposed method against all baselines:
- For each metric: which method wins? By how much?
- Statistical significance if multiple runs exist
- Create a comparison matrix (method × metric)
Step 3: Ablation Analysis
Analyze ablation results:
- For each ablation variant: what's the performance delta?
- Which component contributes most?
- Are results consistent across datasets?
Step 4: Training Dynamics (if available)
If training logs exist:
- Convergence speed comparison
- Overfitting analysis (train vs val curves)
- Learning rate sensitivity
Step 5: Key Findings
Synthesize the analysis into 3-5 key findings:
- Main result: Does the proposed method outperform baselines?
- Ablation insight: Which components are most important?
- Surprising findings: Anything unexpected?
Step 6: Limitations
Identify limitations of the results:
- Small dataset size?
- Missing baselines?
- Computational constraints?
Output
Write to {workspace}/plans/analysis_output.json:
{
"comparison_matrix": {
"methods": ["Proposed", "Baseline1", "Baseline2"],
"datasets": ["Dataset1"],
"results": {
"Dataset1": {
"Proposed": {"accuracy": 0.92, "f1": 0.91},
"Baseline1": {"accuracy": 0.87, "f1": 0.85}
}
}
},
"ablation_results": {
"variants": [
{"name": "w/o ComponentA", "accuracy": 0.89, "delta": -0.03}
]
},
"key_findings": [
"Finding 1: ...",
"Finding 2: ..."
],
"limitations": ["..."],
"tables": [
{
"caption": "Main comparison results",
"headers": ["Method", "Accuracy", "F1"],
"rows": [["Proposed", "92.0", "91.0"]]
}
]
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 97 lines · 0 tokens per session scan A 99d638ff003d
analysis is a command published in the GitHub repository OpenRaiser/NanoResearch (1,361 stars, last pushed 8d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 677 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
potpie-feature
Use Potpie context before feature work. Load potpie-project-preferences first, and load potpie-infra-architecture when the change touches services, deployment, adapters, or runtime behavior.
compare
Side-by-side comparison of N items (drugs, targets, diseases, variants, trials, etc.) with a domain-appropriate column set, structured tabular output, and per-cell source citation. Use when the user wants to evaluate alternatives, not when they want a profile of a single item. Enforces the comparison structure that…
cross-validate
Take a specific scientific claim and confirm or refute it across 3+ independent databases, then report concordance. Use before publishing, citing, or acting on a fact when you want to know how strongly it's supported. Forces multi-source verification that the agent doesn't naturally enforce.
agent
Agent hub - create, manage, and invoke specialized agents.
lit-deep
Run deep literature workflow (discovery, acquisition, then PaperQA synthesis).
git
Git operations with intelligent commit messages and workflow optimization.