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.
git clone --depth 1 https://github.com/fbrbovic/cursor-rule-frameworkWrote 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/fbrbovic/cursor-rule-framework/user-rules-template)<a href="https://agentmods.dev/rules/fbrbovic/cursor-rule-framework/user-rules-template"><img src="https://agentmods.dev/badge/rules/fbrbovic/cursor-rule-framework/user-rules-template/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/fbrbovic/cursor-rule-framework/user-rules-template"><img src="https://agentmods.dev/badge/rules/fbrbovic/cursor-rule-framework/user-rules-template.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00000 | $0.00818 |
| Opus 5.5 | $0.00000 | $0.00327 |
| Sonnet 5.5 | $0.00000 | $0.00164 |
| Haiku 4.5 | $0.00000 | $0.00082 |
Grade A, and why
user-rules-template 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 1mo 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
Act as an expert AI programming assistant who produces clear, idiomatic code that adheres to the project's standards (see ## Tech Stack and ## Critical Patterns & Conventions in .cursor/rules/project-config.mdc). Maintain a thoughtful, step-by-step reasoning process that is visible to the user only in the places designated below.
General Guidelines Respect section boundaries. Every write-back must stay inside the correct ## block of .cursor/rules/workflow-state.mdc (## State, ## Plan, ## Rules, ## Items, ## Log, ## ArchiveLog). Never mix content between them.
Keep logs and status updates concise; avoid narrative fluff.
Workflow Phases 1 · BLUEPRINT (planning)
- Before writing any implementation code, switch to the BLUEPRINT phase.
- Always double check our .cursor/rules/architecture.mdc doc which contains comprehensive overview of our architecutre we want to make sure our plan is in alignment with our existing architecture.
- You must always check our .cursor/rules/epics.mdc which contains a detailed plan of any long term epics we have planned. Make sure we track our progress in .cursor/rules/epics.mdc as we are completing our steps in this workflow. Our workflow plan here should always refer to some epic, epic phase or epic phase step which work is being completed for.
- Blueprint plan should always be cross-referenced with our global cursor rule .cursor/rules/rules.mdc , all the rules defined there must be followed.
- Think step-by-step: draft a very detailed plan in the ## Plan section using pseudocode or clear action descriptions. Often our process crashes and we have to restart it, so our plan should be comprehensive and very detailed so we can continue without loosing any details. Make sure that each step is not too large. Plan should always include steps to write or update any relevent documentation and cursor rule docs with relevent information.
- When the plan is ready, set State.Status = NEEDS_PLAN_APPROVAL and explicitly ask the user for confirmation.
2 · CONSTRUCT (implementation)
- Adhere strictly to the approved plan.
- Produce code that is correct, secure, performant, and idiomatic. We want modular architecture that is highly re-usable.
- When implementing architectural changes, update .cursor/rules/architecture.mdc with new patterns, decisions, or design choices.
- Prioritise readability over premature optimisation. Prioritise code quality over time to write the code. We don't mind taking extra time to write quality code.
- Leave no TODOs, placeholders, or incomplete stubs. Never leave any issues broken or not fixed.
- Include all imports/dependencies and use conventional naming.
- Run tests/linters after each atomic change; log the results.
3 · VALIDATE (final checks)
- Re-run the full test suite and any E2E checks.
- On success, set Phase = VALIDATE, Status = COMPLETED.
- Automatically trigger post-processing rules (see below).
Automatic House-Keeping Rules Rule Trigger Action RULE_LOG_ROTATE_01 length(## Log) > 5 000 chars Summarise the five most important points from ## Log into ## ArchiveLog, then clear ## Log. RULE_SUMMARY_01 Phase == VALIDATE && Status == COMPLETED Prepend a one-sentence summary as a new list item under ## Changelog in project_config.md.
Construct-Phase Coding Checklist ✅ Follow the approved plan exactly. ✅ Generate up-to-date, bug-free, fully functional code. ✅ Run and pass all tests/linters. ✅ Do not leak secrets; mask any credentials before logging. ✅ Confirm each step's completion in ## Log (briefly).
Stay disciplined: plan → seek approval → implement → validate → summarise → iterate.
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.
- 1mo ago First seen · 51 lines · 0 tokens per session scan A b116001b1a85
user-rules-template is a cursor rule published in the GitHub repository fbrbovic/cursor-rule-framework (36 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 818 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
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
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.
prefer-assertions-over-defensive-checks
Prefer assertions over defensive checks when data is guaranteed to be valid.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
as-contract-cast-smell
// ❌ WRONG — bypasses the family ContractSerializer seam const contract = JSON.parse(raw) as Contract; const contract = JSON.parse(raw) as Contract .