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/steipete/agent-rules/continuous-improvementgit clone --depth 1 https://github.com/steipete/agent-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.00016 | $0.01469 |
| Opus 5 | $0.00008 | $0.00734 |
| Sonnet 5 | $0.00003 | $0.00294 |
| Haiku 4.5 | $0.00002 | $0.00147 |
Grade A, and why
continuous-improvement 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- continuous-improvement — 100% identical, 4 lines differ
How it starts
The opening of the file, as written. The whole thing — 296 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Continuous Improvement Guide for AI Development Rules
This guide provides a systematic approach for continuously improving AI assistant rules based on emerging patterns, best practices, and lessons learned during development.
Rule Improvement Triggers
When to Create or Update Rules
Create New Rules When:
- A new technology/pattern is used in 3+ files
- Common bugs could be prevented by a rule
- Code reviews repeatedly mention the same feedback
- New security or performance patterns emerge
- A complex task requires consistent approach
Update Existing Rules When:
- Better examples exist in the codebase
- Additional edge cases are discovered
- Related rules have been updated
- Implementation details have changed
- User feedback indicates confusion
Analysis Process
1. Pattern Recognition
Monitor your codebase for repeated patterns:
// Example: If you see this pattern repeatedly:
const data = await prisma.user.findMany({
select: { id: true, email: true },
where: { status: 'ACTIVE' }
});
// Consider documenting:
// - Standard select fields
// - Common where conditions
// - Performance optimization patterns
2. Error Pattern Analysis
Track common mistakes and their solutions:
Common Error: "Connection timeout"
Root Cause: Missing strategic delay after service startup
Solution: Add 5-10 second delay after launching services
Rule Update: Add timing guidelines to automation rules
3. Best Practice Evolution
Document emerging best practices:
## Before (Old Pattern)
- Direct DOM manipulation
- No error handling
- Synchronous operations
## After (New Pattern)
- Use framework methods
- Comprehensive error handling
- Async/await with proper error boundaries
Rule Quality Framework
Structure Guidelines
Each rule should follow this structure:
# Rule Name
## Purpose
Brief description of what this rule achieves
## When to Apply
- Specific scenarios
- Trigger conditions
- Prerequisites
## Implementation
### Basic Pattern
```code
// Minimal working example
```
### Advanced Pattern
```code
// Complex scenarios with error handling
```
## Common Pitfalls
- Known issues
- How to avoid them
## References
- Related rules: [rule-name.md]
- External docs: [link]
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 · 296 lines · 16 tokens per session scan A cf1f5cb667b6
continuous-improvement is a cursor rule published in the GitHub repository steipete/agent-rules (5,696 stars, last pushed 4mo ago), licensed MIT. It adds 16 tokens to every session and 1,469 once invoked, about $0.0001 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-30.
Other cursor rules, from other repositories
code-optimization
Guidelines for optimizing duplicate and poorly structured code.
paperfit
PaperFit project rule for LaTeX visual typesetting optimization.
read-xlsx
Reading, writing, diffing, and repairing spreadsheets (.xlsx) for AI agents via the xfa MCP server.
coding-standards-demo.crux
Team coding standards and best practices.
testing
Always use vitest for testing. Use describe/it blocks.
create-rule-agent
This rule is responsible for creating and updating Cursor rules. Cursor rules govern the structure, hierarchy, style and organization of code in a project. This rule should be invoked in Agent mode when: 1. a user wants to create a new cursor rule, 2. a user wants to update or change an existing rule, 3. user wants…