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/hamzaamjad/cursor-rules/428-pre-task-rule-reviewgit clone --depth 1 https://github.com/hamzaamjad/cursor-rulesWrote 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/hamzaamjad/cursor-rules/428-pre-task-rule-review)<a href="https://agentmods.dev/rules/hamzaamjad/cursor-rules/428-pre-task-rule-review"><img src="https://agentmods.dev/badge/rules/hamzaamjad/cursor-rules/428-pre-task-rule-review.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.00000 | $0.01317 |
| Opus 5 | $0.00000 | $0.00659 |
| Sonnet 5 | $0.00000 | $0.00263 |
| Haiku 4.5 | $0.00000 | $0.00132 |
Grade A, and why
428-pre-task-rule-review 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 — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
alwaysApply: true
pre-task-rule-review.mdc
-
Purpose: To ensure AI agents proactively review and apply relevant Cursor rules before beginning any task, preventing mid-task course corrections and ensuring consistent quality from project initiation. Empirical Impact: Pre-task rule application reduces rework by 60-75% and improves first-pass quality by 40%. Enhancement: Documentation discovery phase reduces context-gathering time by 70% for complex projects.
-
Requirements:
- Documentation Discovery Phase (Complex Projects Only):
- Trigger: Projects with scattered context (>5 directories, multiple phases, or fragmented documentation)
- Process: Execute systematic documentation mapping using parallel file reading
- Identify: README files, methodology documents, architectural decisions, phase summaries
- Map: Cross-references between documentation systems and implementation files
- Catalog: Available context sources with relevance scoring
- Output: Comprehensive context map for informed rule selection
- Rule Discovery Phase: At task initiation, identify 3-5 potentially relevant rules based on:
- Task domain (analytics, engineering, integration, etc.)
- Task type (refactoring, new development, debugging, etc.)
- Technologies involved (Python, SQL, APIs, databases, etc.)
- Complexity level (simple, moderate, complex)
- Documentation context (from Phase 1 for complex projects)
- Rule Review Process:
- Use
fetch_rulestool to retrieve identified rule content - Extract key requirements, patterns, and validation criteria
- Note any conflicts or overlaps between rules
- Identify domain-specific guidelines (e.g., SQL best practices, API design)
- Use
- Application Strategy:
- Integrate rule requirements into task planning phase
- Reference specific rule sections when making design decisions
- Use rule validation criteria as checkpoints during execution
- Apply rule patterns proactively rather than reactively
- Rule Integration Examples:
- Database work → Review
sql-correctness.mdc,sql-performance.mdc - Python development → Apply
python-clean-code.mdc,code-generation-patterns.mdc - API integration → Follow
api-design-guidelines.mdc,backend-security.mdc - Complex tasks → Apply
stepwise-autonomy.mdc,80-20-prioritization.mdc - Complex projects → Execute documentation discovery before rule selection
- Database work → Review
- Documentation Discovery Phase (Complex Projects Only):
-
Validation:
- Check: Were relevant rules identified before task execution began?
- Check: Are rule requirements integrated into the task plan?
- Check: Do implementation decisions reference specific rule guidance?
- Check: Are rule validation criteria applied as checkpoints?
- Complex projects: Was documentation discovery completed before rule selection?
-
Examples:
-
Scenario: Database optimization task
- Rule Review: Fetch
sql-performance.mdc,sql-correctness.mdc,stepwise-autonomy.mdc - Integration: Apply performance patterns, include verification steps, use 80/20 prioritization
- Execution: Reference rule requirements when designing queries, validate against rule criteria
- Rule Review: Fetch
-
Scenario: API integration project
- Rule Review: Fetch
api-design-guidelines.mdc,backend-security.mdc,dependency-management.mdc - Integration: Follow security patterns, apply consistent API design, manage dependencies properly
- Execution: Use rule patterns for authentication, error handling, and testing
- Rule Review: Fetch
-
Scenario: Complex multi-phase project continuation
- Documentation Discovery: Map scattered documentation across 6+ systems using parallel reading
- Context Synthesis: Identify methodology documents, architectural decisions, phase summaries
- Rule Selection: Choose rules based on comprehensive context understanding
- Execution: Apply framework integration patterns with full project context
-
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 · 105 lines · 0 tokens per session scan A 620e513db730
428-pre-task-rule-review is a cursor rule published in the GitHub repository hamzaamjad/cursor-rules (2 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,317 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-31.
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.
cli-error-handling
CLI command error handling patterns.
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.
control-plane-descriptors
Control plane descriptor and instance implementation patterns.
family-instance-domain-actions
Family instance domain action implementation patterns.