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/mannansaood/termi/30-safety-and-testinggit clone --depth 1 https://github.com/MannanSaood/termiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/mannansaood/termi/30-safety-and-testing)<a href="https://agentmods.dev/rules/mannansaood/termi/30-safety-and-testing"><img src="https://agentmods.dev/badge/rules/mannansaood/termi/30-safety-and-testing.svg" alt="Measured on agentmods" height="20"></a>What 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.00623 | $0.00623 |
| Opus 5 | $0.00311 | $0.00311 |
| Sonnet 5 | $0.00125 | $0.00125 |
| Haiku 4.5 | $0.00062 | $0.00062 |
Grade A, and why
30-safety-and-testing 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 4d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Safety & Testing Requirements
These apply to every change in this repo, not just Rust or Kotlin specifically.
Before saying something is "done" or "fixed"
- Actually run the relevant test suite (
cargo testfor Rust changes — see10-rust-core.mdc). Don't infer test results from reading the code. - If you added new logic with no test covering it, add one before
considering the task complete — this codebase's Phase 1d work
(
vfs/service.rs,vfs/health.rs) was built test-first specifically so the capability-blocking behavior is provable, not just plausible-looking. - If a test can't be written because the code depends on a real Android runtime (JNI calls, SAF, actual device permissions), say so explicitly and explain what WOULD need to happen on-device to verify it — don't present untestable code with the same confidence as tested code.
Debugging workflow
When something fails (test failure, panic, unexpected behavior):
- Reproduce it with the smallest possible
cargo test <name>or a focused new test — don't guess from reading code. - Check
docs/PHASE1_STATUS.mdfirst — if the failing area is listed as "scaffolded, not implemented," the fix might be "implement this properly" rather than "patch this bug." - For panics: check whether it's a
.unwrap()/.expect()that should have been caught byclippy::unwrap_used— if clippy didn't catch it, that's itself a bug in the lint coverage (e.g. missing#[warn(clippy::unwrap_used)]somewhere) worth flagging. - See
.cursor/skills/debug-rust-panic/SKILL.mdfor a structured checklist.
Never do this
- Never add
.unwrap()/.expect()to production code to "just get it compiling" — see10-rust-core.mdcfor the alternatives. - Never mark a Kotlin change as tested/verified if you don't have a
working Gradle/Android SDK environment to actually run it in — see
20-android-kotlin.mdc. - Never claim a feature is "complete" if it's gated behind
#[cfg(feature = "android")]and you've only runcargo check, not an actual on-device test — check compiles, it doesn't verify behavior. - Never treat host
cargo check --features androidas an Android compile. That still uses host libc. PTY/ioctl code must also passcargo check --target aarch64-linux-android --features android --lib. - Never quietly widen scope into Phase 2/3 roadmap items while fixing a Phase 1 bug — flag it as a separate suggestion instead.
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.
- 4d ago First seen · 54 lines · 623 tokens per session scan A 6cf429fc65fc
30-safety-and-testing is a cursor rule published in the GitHub repository MannanSaood/termi (8 stars, last pushed 4d ago), licensed MIT. It adds 623 tokens to every session, about $0.0031 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
compose-coroutines
Compose scroll/coroutine patterns — prevent programmatic scroll from being mistaken for user scroll, cancellation-safe flag resets.
compose-ui
Compose UI conventions — Material 3, recomposition optimization, Compose-only UI, theming.
android-viewmodel
Android ViewModel conventions — StateFlow, repository abstraction, coroutines, no LiveData.
edge_to_edge
Edge-to-edge Play Store warnings and why they are expected — relevant when handling Play Console warnings, upgrading androidx.activity or Material Components, or working on edge-to-edge / window insets.
session-learning
End-of-session rule reflection — run at the end of coding sessions to capture learnings.
shared-module
KMP shared module constraints — no platform imports in domain/, expect/actual conventions, pure Kotlin business logic.