1 min lesson
Keep rules reactive, not preventive
Use "Build rules reactively: add a directive only after the model makes the same mistake more than a few times" to say what you would do next.
Step 1 of 2
Skills are the sibling primitive for the recurring multi-step jobs - run the test suite, fix compile errors, open a PR, spin up local servers, commit-and-push. Each one is a SKILL.md in .cursor/skills/<name>/; add disable-model-invocation: true to the frontmatter when only a human should fire it from the slash menu. That human-only shape is exactly what the retired commands format was: .cursor/commands/*.md files still load, but the docs page is gone and the built-in /migrate-to-skills skill converts them. A best-practice touch: tell the skill how to respond (e.g. 'print the local URL and confirm the server is responding') to cut verbose replies.
Cramming directives into an always-apply rule degrades output - the model does best with the least to attend to, and a 300-line always-apply rule silently appends 'also do these 300 other things' to every prompt.
Build rules reactively: add a directive only after the model makes the same mistake more than a few times. Don't write 'just in case' rules and don't replace your linter with a rule (that just burns tokens injecting rule content into every call). For very large style guides, prefer a manual @-invoked rule run as a recurring audit over an always-on one.