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/omril321/automated-notebooklm/code-guidelinesgit clone --depth 1 https://github.com/omril321/automated-notebooklmWhat 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.00558 | $0.00558 |
| Opus 5 | $0.00279 | $0.00279 |
| Sonnet 5 | $0.00112 | $0.00112 |
| Haiku 4.5 | $0.00056 | $0.00056 |
Grade A, and why
code-guidelines 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.
This is a copy
91% identical to code-guidelines-cursorrules-prompt-file — 7 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
What it actually says
-
Verify Information: Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
-
File-by-File Changes: Make changes file by file and give me a chance to spot mistakes.
-
No Apologies: Never use apologies.
-
No Understanding Feedback: Avoid giving feedback about understanding in comments or documentation.
-
No Whitespace Suggestions: Don't suggest whitespace changes.
-
No Summaries: Don't summarize changes made.
-
No Inventions: Don't invent changes other than what's explicitly requested.
-
No Unnecessary Confirmations: Don't ask for confirmation of information already provided in the context.
-
Preserve Existing Code: Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
-
Single Chunk Edits: Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
-
No Implementation Checks: Don't ask the user to verify implementations that are visible in the provided context.
-
No Unnecessary Updates: Don't suggest updates or changes to files when there are no actual modifications needed.
-
Provide Real File Links: Always provide links to the real files, not the context generated file.
-
No Current Implementation: Don't show or discuss the current implementation unless specifically requested.
-
Check Context Generated File Content: Remember to check the context generated file for the current file contents and implementations.
-
Use Explicit Variable Names: Prefer descriptive, explicit variable names over short, ambiguous ones to enhance code readability.
-
Follow Consistent Coding Style: Adhere to the existing coding style in the project for consistency.
-
Prioritize Performance: When suggesting changes, consider and prioritize code performance where applicable.
-
Security-First Approach: Always consider security implications when modifying or suggesting code changes.
-
Test Coverage: Suggest or include appropriate unit tests for new or modified code.
-
Error Handling: Implement robust error handling and logging where necessary.
-
Modular Design: Encourage modular design principles to improve code maintainability and reusability.
-
Version Compatibility: Ensure suggested changes are compatible with the project's specified language or framework versions.
-
Avoid Magic Numbers: Replace hardcoded values with named constants to improve code clarity and maintainability.
-
Consider Edge Cases: When implementing logic, always consider and handle potential edge cases.
-
Use Assertions: Include assertions wherever possible to validate assumptions and catch potential errors early.
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 · 58 lines · 558 tokens per session scan A 5b47014ddca2
code-guidelines is a cursor rule published in the GitHub repository omril321/automated-notebooklm (15 stars, last pushed 6mo ago), licensed Apache-2.0. It adds 558 tokens to every session, about $0.0028 per session on Opus 5. A static security scan graded it A with 0 findings. It is 91% identical to code-guidelines-cursorrules-prompt-file, differing in 7 lines, and is treated as a copy.
Other cursor rules, from other repositories
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
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.
coolify-ai-docs
Master reference to all Coolify AI documentation in .ai/ directory.
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.