Audit Your AI Config
You've learned about rules vs skills, the alwaysApply tax, and discovery mechanics. Now what? This post provides a step-by-step audit process for cleaning up an existing AI configuration. The goal: fewer rules, faster responses, better AI behavior.
Related: This is a practical follow-up to the Configuring Your AI Assistant series.
The Audit Framework
| Phase | Time | Goal |
|---|---|---|
| Inventory | 30 min | Count and categorize |
| Evaluate | 1-2 hours | Identify what should change |
| Migrate | 2-4 hours | Execute the changes |
| Verify | 30 min | Confirm improvements |
Block an afternoon. You'll thank yourself later.
Phase 1: Inventory
Step 1.1: Count Everything
# Rules
find .cursor/rules -name "*.md" | wc -l
# Skills
find .cursor/skills -type d -mindepth 1 | wc -l
# Commands (if using)
find .cursor/commands -name "*.md" 2>/dev/null | wc -l
# Agents (if using)
find .cursor/agents -name "*.md" 2>/dev/null | wc -l
Step 1.2: Measure alwaysApply Load
# Count alwaysApply rules
grep -rl "alwaysApply: true" .cursor/rules | wc -l
# Total lines in alwaysApply rules
grep -rl "alwaysApply: true" .cursor/rules | xargs wc -l | tail -1
Benchmarks:
- Healthy: < 1,000 lines always loaded
- Concerning: 1,000-2,000 lines
- Critical: > 2,000 lines
Step 1.3: Find Oversized Rules
# List rules by size
find .cursor/rules -name "*.md" -exec wc -l {} + | sort -rn | head -20
Benchmarks:
- Good: < 100 lines
- Large: 100-200 lines
- Oversized: > 200 lines (candidate for splitting)
Step 1.4: Document Current State
Create an inventory file:
# AI Config Audit - [Date]
## Inventory
| Category | Count |
| ----------------------- | ----- |
| Rules | X |
| Skills | X |
| Commands | X |
| Agents | X |
| alwaysApply rules | X |
| Total alwaysApply lines | X |
| Oversized rules (>200) | X |
## Largest Rules
1. rule-name (X lines)
2. ...
Phase 2: Evaluate
Step 2.1: Audit Each alwaysApply Rule
For each rule with alwaysApply: true, ask:
| Question | If Yes | If No |
|---|---|---|
| Needed in EVERY conversation? | Keep alwaysApply | Convert to globs |
| Is it a workflow (step-by-step)? | Extract to skill | Keep as rule |
| Could it be glob-triggered? | Add globs, remove alwaysApply | - |
| Is it > 100 lines? | Split or extract | - |
Step 2.2: Create Migration Plan
Document what needs to change:
| Rule | Current | Action | Target |
|---|---|---|---|
| core-logging | alwaysApply, 240 lines | Add globs | Glob-triggered |
| core-diagrams | alwaysApply, 80 lines | Add globs | Glob-triggered |
| core-workflow | alwaysApply, 89 lines | Keep | alwaysApply (core) |
| content-gen | alwaysApply, 150 lines | Extract workflow | Rule + Skill |
Step 2.3: Evaluate Skills
For each skill, check:
- Description quality: Does it have rich triggers?
- Type: Is it actually a skill (workflow) or a template/reference?
- Discovery: Can you trigger it with natural language?
| Skill | Description Quality | Is Workflow? | Action |
|---|---|---|---|
| /ship | Good | Yes | Keep |
| /comic-hero | Poor | No (template) | Consider consolidating |
| /init-project | Good | Yes | Keep |
Phase 3: Migrate
Step 3.1: Convert alwaysApply to Globs
Before:
---
description: "Logging standards"
alwaysApply: true
---
After:
---
description: "Logging standards"
globs:
- "**/log*"
- "**/logger*"
- "**/*logging*"
alwaysApply: false
---
Step 3.2: Extract Workflows to Skills
If a rule has step-by-step instructions:
- Create new skill:
skills/new-skill/SKILL.md - Move workflow content to skill
- Keep only reference content in rule
- Add rule reference to skill: "See @rule-name for standards"
Before (in rule):
## How to Generate Content
1. First, check the brief
2. Then, draft the outline
3. Review against standards
4. Finalize and submit
After (split):
Rule keeps standards:
## Content Standards
- Title ≤42 characters
- Must have counterargument
- Enterprise examples required
Skill gets workflow:
# Content Generation Skill
## Instructions
1. Check brief for requirements
2. Draft outline (see @content-standards)
3. Review against standards
4. Finalize and submit
Step 3.3: Split Oversized Rules
If a rule is > 200 lines:
Option A: Extract examples to docs
rules/my-rule/RULE.md (core guidance)
rules/my-rule/examples.md (examples, referenced)
Option B: Split by concern
rules/my-rule-core/RULE.md (always needed)
rules/my-rule-advanced/RULE.md (glob-triggered)
Option C: Move detail to skill references
rules/my-rule/RULE.md (core guidance)
skills/my-skill/references/detailed-guide.md (on demand)
Step 3.4: Improve Skill Descriptions
Before:
description: "Helps with project setup"
After:
description: |
Initialize project structure. Create directories and config files.
Use when user asks to: set up project, initialize repo, create structure.
Triggers: "init project", "set up", "bootstrap", "create structure"
Step 3.5: Consolidate Redundant Skills
If you have multiple similar skills with different entry points, consider consolidating:
Before:
skills/comic-hero-prompt/
skills/social-card-prompt/
skills/icon-set-prompt/
After:
skills/image-handler/
├── SKILL.md (unified entry point)
└── templates/
├── comic-hero.md
├── social-card.md
└── icon-set.md
Phase 4: Verify
Step 4.1: Re-measure
# Count alwaysApply rules again
grep -rl "alwaysApply: true" .cursor/rules | wc -l
# Total lines again
grep -rl "alwaysApply: true" .cursor/rules | xargs wc -l | tail -1
Step 4.2: Test Key Workflows
- Start a new conversation
- Ask simple question ("what's 2+2?")
- Time the response
- Ask domain-specific question
- Verify appropriate rules/skills activate
Step 4.3: Document Results
Update your audit file:
## Results
| Metric | Before | After | Change |
| ---------------------- | ------ | ----- | ------ |
| alwaysApply rules | 22 | 8 | -64% |
| alwaysApply lines | 2,700 | 900 | -67% |
| Oversized rules | 5 | 1 | -80% |
| Response time (simple) | ~3s | ~1.5s | -50% |
Maintenance Schedule
Weekly
- Quick check: Any new alwaysApply rules added?
Monthly
- Audit new rules for appropriate activation
- Check for skill description quality
Quarterly
- Full re-audit using this process
- Review and remove unused rules/skills
Decision Trees
Should This Be alwaysApply?
Is it needed in EVERY conversation?
├── No → Use globs or skill
└── Yes
├── Is it about safety/security?
│ └── Yes → alwaysApply ✓
├── Is it about AI persona/behavior?
│ └── Yes → alwaysApply ✓
└── Is it domain-specific?
└── Yes → Use globs
Should This Be a Skill or Rule?
Does it have step-by-step instructions?
├── Yes → Skill
└── No
├── Is it reference material for editing?
│ └── Yes → Rule with globs
└── Is it universal standards?
└── Yes → Rule (maybe alwaysApply)
How to Improve Skill Discovery?
Is description > 3 lines?
├── No → Add more trigger phrases
└── Yes
├── Does it include "Use when..."?
│ └── No → Add use cases
└── Does it include "Triggers: ..."?
└── No → Add explicit triggers
Pre-Flight Checklist
Before Starting
- [ ] Block 2-3 hours
- [ ] Have terminal access
- [ ] Back up current config (
git commit)
Inventory Complete
- [ ] Counted rules, skills, agents
- [ ] Counted alwaysApply rules and lines
- [ ] Listed oversized rules
Evaluation Complete
- [ ] Reviewed each alwaysApply rule
- [ ] Checked skill descriptions
- [ ] Created migration plan
Migration Complete
- [ ] Converted alwaysApply → globs (where appropriate)
- [ ] Extracted workflows → skills
- [ ] Split oversized rules
- [ ] Improved skill descriptions
Verification Complete
- [ ] Re-measured metrics
- [ ] Tested key workflows
- [ ] Documented results
- [ ] Committed changes
Key Takeaways
-
You can't optimize what you don't measure. Start with inventory.
-
Every rule is a tax on every conversation. Be ruthless about alwaysApply.
-
The best audit finds things to remove. Smaller is better.
-
Schedule regular maintenance. Rules accumulate; performance degrades.
-
Document your changes. Future you will thank present you.
Related: Rules vs Skills | The alwaysApply Tax | How Cursor Finds Skills