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 rules/nceas-ai/coding-agent-rules-for-data-science/data-science-rulesgit clone --depth 1 https://github.com/NCEAS-AI/Coding-Agent-Rules-for-Data-ScienceWhat 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.03654 | $0.03654 |
| Opus 5 | $0.01827 | $0.01827 |
| Sonnet 5 | $0.00731 | $0.00731 |
| Haiku 4.5 | $0.00365 | $0.00365 |
Grade A, and why
data-science-rules 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 — 368 lines — stays where its author put it; the contents beside it link to each section on GitHub.
🧭 Data-Science Conventions (R & Python)
Reproducible R and Python data-science work — environmental, ecological, geospatial. These are conventions for reproducible analysis, not a software product.
🎯 Priorities
Optimize for code that reads top-to-bottom and reruns cleanly — not for abstraction, generality, or "production" polish. This is reproducible analysis, not a software product.
🚫 Real data only — never fabricate or insert demo data
- Use real, actual data. Never invent, mock, or insert demo / sample / placeholder / synthetic data to make code run or an analysis complete. This is a hard line.
- If real data is missing, unavailable, or unclear, STOP and say so, then ask for it — don't substitute stand-in values and keep going.
- No silent gap-filling: no made-up rows, columns, values, default fallbacks, or dummy files slipped into a pipeline. If sample data is ever genuinely needed (e.g. to test structure), label it unmistakably as fake and keep it out of any analysis path.
- Flag it loudly wherever data looks fabricated, hardcoded, or placeholder-like in the code or inputs.
🖥️ System / environment
- Primary host: Aurora (aurora.nceas.ucsb.edu) — a shared, multi-user NCEAS research server reached over SSH. Many people use it at once, so resource discipline matters (see Parallel & multiprocessing).
- CPU: 2x AMD EPYC 9634 -> 168 physical cores / 336 logical (2 threads/core).
- RAM: ~2.2 TiB.
- Work may also run on local machines; the shared-server utilization caps below apply specifically when on a shared server like Aurora.
💬 Communication
- Be concise and scannable; lead with the answer; don't restate code back.
- When directions are unclear, ask clarifying questions — and note how the request could have been phrased more clearly.
🧰 Working with code (general)
- Make only changes that were requested or are clearly understood and directly related to the task. Don't touch unrelated code.
- Strongly prefer common, well-documented, standard packages and techniques.
- Don't assume a package or function exists from memory. Confirm it's installed in the active environment before importing, and verify the specific function/argument exists in the installed version rather than guessing.
- Never fabricate data, results, statistics, or citations. When inferring something rather than knowing it, say so.
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 · 368 lines · 3,654 tokens per session scan A 6f3f507e6105
data-science-rules is a cursor rule published in the GitHub repository NCEAS-AI/Coding-Agent-Rules-for-Data-Science (3 stars, last pushed 8d ago), licensed CC0-1.0. It adds 3,654 tokens to every session, about $0.0183 per session on Opus 5. 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-31.
Other cursor rules, from other repositories
kumo-coding-agent
Kumo Coding Agent — ML predictions on relational data using KumoRFM.
data-science
Rules for data science, ML, and Jupyter notebook work.
cursorrules
🧠 Fast, zero-dependency structured knowledge base (.agent-kb/) with 2D neural graph visualizer │ & MCP server for Claude, Codex, PI, Cursor, Windsurf, Zed & Other AI coding agents.
prompt-routing
Route tasks to the correct Universal AI Engineering Prompt.
avos-agent-workflow
Avos memory workflow for AI coding agents. Guides codebase search and history lookup.
ai-security
Security best practices for LLM/AI applications - prompt injection defense, rate limiting, PII protection.