Short answer
Good Cursor rules are short and clear. Keep them in Git so the team can review them. Package a rule when several projects need it.
Words used in this guide
- AIPM: a tool that installs and updates reusable AI instructions.
- Package: a named group of files that people can install and update together.
- Repository or repo: a project folder whose changes are saved and tracked.
- Git: a tool that records file changes so people can review or undo them.
- Config: settings that tell a tool how to work.
What this means
Keep rules small
A rule should explain one behavior. Large rule files are harder to review and easier for an AI assistant to misunderstand.
Use Git review
Cursor rules can change generated code. Review rule changes like you review lint rules, tests, or build config.
Package rules that repeat
A rule may be useful in many projects. Share always-on rules through Git. If the rule is really a repeatable task, turn it into a skill that AIPM can install at a pinned version (AIPM does not install Cursor rules today).
Simple steps
- Write one rule per job.
- Name files by task or code area.
- Avoid secrets and private customer data.
- Review changes in pull requests.
- Turn shared task-style rules into skills.
Where to go next
If you want to try this in a real project, start with how to use AIPM and the command reference. If you want to share your own workflow, read the publishing guide.
FAQ
Should Cursor rules live in Git?
Yes. If a rule affects project work, the team should be able to review and change it in Git.
When should I package a Cursor rule?
Package it when the same rule is useful in more than one repo or team.