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/homenshum/nodebenchai/analyst_diagnosticgit clone --depth 1 https://github.com/HomenShum/NodeBenchAIWhat 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.00748 |
| Opus 5 | $0.00000 | $0.00374 |
| Sonnet 5 | $0.00000 | $0.00150 |
| Haiku 4.5 | $0.00000 | $0.00075 |
Grade A, and why
analyst_diagnostic 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Analyst Diagnostic
Guide yourself like an analyst diagnosing the root cause, not a junior dev slapping on a bandaid.
When to trigger
- Before writing ANY fix — investigate why the bug exists, not just what it looks like
- When an error appears — trace it upstream to the source, don't just suppress it
- When a test fails — understand the system state that caused it, not just make the assertion pass
- When something "works but feels wrong" — name the smell, don't ignore it
The diagnostic process
- Reproduce: Confirm the exact failure mode. What triggers it? What's the expected vs actual?
- Trace upstream: Walk from symptom → intermediate state → root cause. Follow the data, not assumptions.
- Ask "why" 5 times: Each answer should go one level deeper. Stop when you reach a design decision, missing constraint, or wrong assumption.
- Fix the cause, not the symptom: The right fix makes the symptom impossible, not just invisible.
- Verify the fix didn't shift the problem: Bandaids often move bugs sideways. Check adjacent behavior.
Red flags you're bandaiding
- Adding
try/catchthat swallows errors without understanding them - Adding
?.optional chaining to maskundefinedinstead of finding why it's undefined - Adding
as anyto silence type errors instead of fixing the type mismatch - Adding timeouts/retries to paper over race conditions
- Deleting a failing test instead of fixing the code it tests
- "It works now" without understanding why it didn't before
What analysts do differently
- They form a hypothesis BEFORE trying a fix
- They check if the "fix" actually addresses their hypothesis
- They look for other places the same root cause could cause problems
- They document what they found so the next person doesn't re-discover it
- They ask: "What system condition allowed this bug to exist?"
UI-specific diagnostic
When fixing a UI issue, the analyst approach demands:
- Which component actually renders? Trace sidebar label → view key → MainLayout switch → component import. Grep alone can find the wrong file.
- What layer owns the data? Convex backend, React frontend, or stored DB records? Each requires a different deployment path.
- Is this a cold-start problem? Empty states for new users often point to missing bootstrap/onboarding data, not just bad copy. Fixing text is a bandaid; showing fallback content (trending, sample, public data) is structural.
- Would hiding the problem make it invisible or actually solve it? Changing "0/7 healthy" to "7 scheduled" hides a monitoring signal. The structural question is: should this panel even render when the system isn't configured?
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 · 54 lines · 0 tokens per session scan A 0ee678c9d0ba
analyst_diagnostic is a cursor rule published in the GitHub repository HomenShum/NodeBenchAI (14 stars, last pushed 18d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 748 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 cursor rules, from other repositories
api-property-optionality-hygiene
Fix ApiProperty/ApiPropertyOptional optionality mismatches in DTO files; use for scheduled batch fixes or DTO edits.
java-springboot-jpa-cursorrules-prompt-file
description: "Cursor rules for Java development with Springboot and JPA integration." globs: / alwaysApply: false.
conservative-file-creation
Check for existing files before creating. Be conservative about new files and code.
secure-dev-rust
These rules apply to all Rust code in the repository and aim to prevent common security risks through disciplined use of memory safety, input validation, error handling, and safe APIs.
design-patterns
Design patterns (GoF) and file size conventions for sweagent TypeScript codebase.
cursorrules
ALWAYS start your session by reading AGENTS.md and .memory/wiki/hot.md to get project context before suggesting code or answering questions.