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/pekral/cursor-rules/optimalizegit clone --depth 1 https://github.com/pekral/cursor-rulesWhat 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.07339 | $0.07339 |
| Opus 5 | $0.03669 | $0.03669 |
| Sonnet 5 | $0.01468 | $0.01468 |
| Haiku 4.5 | $0.00734 | $0.00734 |
Grade A, and why
optimalize 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 yesterday.
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 — 332 lines — stays where its author put it; the contents beside it link to each section on GitHub.
General
- No N+1: use
with(),load(), or JOINs - SARGable WHERE clauses (no functions on indexed columns)
- Seek pagination over OFFSET
- Never
SELECT *; fetch only needed columns - Use EXPLAIN for new or changed queries: avoid type ALL, high rows, Using filesort, Using temporary
- Prepared statements with bound parameters; never concatenate user input into SQL
- Push filtering, sorting, aggregation into SQL; avoid doing it in application code
- Refactor or split very complex joins when EXPLAIN shows poor plans; when profiling use slow query log and prioritize frequent or longest queries
- Indexes: index columns used in WHERE, JOIN, ORDER BY, GROUP BY; composite index order must match query filter/sort; avoid low-cardinality-only indexes; use covering indexes when a query can be satisfied from the index; drop unused or redundant indexes when changing schema; aim for 3–5 well-chosen indexes per table; prefer parallel index creation on large tables
- Transactions: keep transactions short; avoid holding locks during app logic; batch writes in single transactions where appropriate; reduce lock contention via batching and suitable isolation levels; use
SHOW ENGINE INNODB STATUSto diagnose lock waits when investigating issues - Index JOIN columns on both tables; composite index order matters (left-to-right)
Query Analysis
- Run
EXPLAINon every new or modified query. - Flag: type
ALL, highrows,Using filesort,Using temporary. - Use
EXPLAIN ANALYZEfor actual vs estimated row counts. - Check slow query log — prioritize frequent or longest-running queries.
- Apply one optimization at a time; measure before and after.
Performance Non-Regression on Query Changes
Whenever a query is refactored or changed (Eloquent / query-builder rewrite, raw-SQL edit, added / removed JOIN / WHERE / ORDER BY / GROUP BY / subquery / eager load, pagination change, index-driven rewrite, or a refactor that moves the query into another layer), the changed query must be at least as fast as the original — ideally faster. Never ship a query change that is slower without a documented justification.
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.
- yesterday First seen · 332 lines · 7,339 tokens per session scan A a80d99fef509
optimalize is a cursor rule published in the GitHub repository pekral/cursor-rules (6 stars, last pushed 6d ago), licensed MIT. It adds 7,339 tokens to every session, about $0.0367 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
owl-admin
🎈 Owl Admin : 基于 laravel 和 amis 开发的后台框架, 友好的组件使用体验, 可轻松实现复杂页面, 内置代码生成器, 让开发者快速搭建后台管理系统.
16-wechat-sdk
微信 SDK 接入规范（EasyWeChat / WechatManager）.
15-config-center
动态配置中心读取规范（ConfigCenter / configcenter）.
lean
Answer densely. Cut filler, keep all technical signal.
00-project
基于 Laravel + Blade + Vue3 + Element Plus 的轻量级后台管理系统.
99-guard
Cursor rule "99-guard" from neoshopcn/neo-admin, covering 🔒 protected directories（禁止修改）, ⚠️ conditional（仅在明确要求时允许） and 🚫 dangerous operations（禁止主动执行）.