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/nvidia/physicsnemo/mod-004-model-code-is-not-self-containedgit clone --depth 1 https://github.com/NVIDIA/physicsnemoWhat 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.00031 | $0.00700 |
| Opus 5 | $0.00015 | $0.00350 |
| Sonnet 5 | $0.00006 | $0.00140 |
| Haiku 4.5 | $0.00003 | $0.00070 |
Grade A, and why
mod-004-model-code-is-not-self-contained 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.
What it actually says
When organizing model code, rule MOD-004 must be followed. Explicitly reference "Following rule MOD-004, which states that all utility functions for a model class should be contained in the same module file as the model class itself..." when deciding where to place utility functions.
MOD-004: Model code is not self-contained
Description:
All utility functions for a model class should be organized together with the model class in a clear and logical structure. Acceptable patterns include:
- A single self-contained file:
physicsnemo/<models or nn>/model_name.py - A subdirectory:
physicsnemo/<models or nn>/model_name/containing:model_name.pywith the main model class- Additional modules for utility functions specific to this model
What should be avoided is a flat organization where model files and their
utility files are all mixed together in physicsnemo/<models or nn>/, making it
unclear which utilities belong to which models.
The only exception is when a utility function is used across multiple models. In that case, the shared utility should be placed in an appropriate shared module.
Rationale:
Self-contained modules are easier to understand, maintain, and navigate. Having all model-specific code in one place reduces cognitive load and makes it clear which utilities are model-specific versus shared. This also simplifies code reviews and reduces the likelihood of orphaned utility files when models are refactored or removed.
Example:
# Good Pattern 1: Single self-contained file
# File: physicsnemo/models/my_simple_model.py
def _compute_attention_mask(seq_length: int) -> torch.Tensor:
"""Helper function specific to MySimpleModel."""
mask = torch.triu(torch.ones(seq_length, seq_length), diagonal=1)
return mask.masked_fill(mask == 1, float('-inf'))
class MySimpleModel(Module):
"""A simple model with utilities in same file."""
def forward(self, x: torch.Tensor) -> torch.Tensor:
mask = _compute_attention_mask(x.shape[1])
return self._apply_attention(x, mask)
# Good Pattern 2: Subdirectory organization
# File: physicsnemo/models/my_complex_model/my_complex_model.py
from physicsnemo.models.my_complex_model.utils import helper_function
class MyComplexModel(Module):
"""A complex model with utilities in subdirectory."""
pass
# File: physicsnemo/models/my_complex_model/utils.py
def helper_function(x):
"""Utility specific to MyComplexModel."""
pass
Anti-pattern:
# WRONG: Flat organization with utilities mixed in main directory
# File: physicsnemo/models/my_transformer.py
from physicsnemo.models.my_transformer_utils import _compute_mask # WRONG
class MyTransformer(Module):
pass
# File: physicsnemo/models/my_transformer_utils.py (WRONG: mixed with other models)
# File: physicsnemo/models/other_model.py
# File: physicsnemo/models/other_model_utils.py (WRONG: utilities scattered)
# All mixed together in flat structure - unclear organization!
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 · 81 lines · 31 tokens per session scan A bbdb61b6ef50
mod-004-model-code-is-not-self-contained is a cursor rule published in the GitHub repository NVIDIA/physicsnemo (3,211 stars, last pushed today), licensed Apache-2.0. It adds 31 tokens to every session and 700 once invoked, about $0.0002 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-30.
Other cursor rules, from other repositories
typescript
Changes to these high-fan-out internals can affect every message, delta, element, or rerun. Keep work in them minimal, and benchmark changes with representative stress-test apps.
python_lib
Tips and guidelines specific to the development of the Streamlit Python library, not applicable to scripts and e2e tests.
specs
This directory contains product and tech specs for Streamlit features.
workflows
This folder contains all GitHub Actions workflows for the Streamlit repository. Workflows automate CI/CD, testing, releases, and maintenance tasks.
python_tests
We use the unit tests to cover internal behavior that can work without the web / backend counterpart. We aim for 95%+ unit test coverage of our Python code in lib/streamlit.
skills
This file provides guidance to AI coding agents (Claude Code, Cursor, Copilot, etc.) when working with skills in this repository.