EddieFree tool · Eddie’s Workshop
Cursor rules generator.
Pick your stack and conventions and get a Cursor project rule, ready to save in .cursor/rules so Cursor’s agent follows your project’s way of doing things.
Free · no sign-up · updated October 2026
How Cursor project rules work
Cursor project rules live in .cursor/rules/ as .mdc files: Markdown with a small header of three fields, description, globs and alwaysApply. A rule can always apply, apply to files matching a pattern, be applied by the agent when it’s relevant, or only when you mention it.
The generator writes one always-on rule with your stack, commands, conventions and boundaries. As your project grows, split it into smaller rules per area (for example one for the frontend and one for the API) with file patterns, so each request only carries the rules it needs.
Cursor rules best practices
Be specific. “Use the existing Button component from src/components/ui” beats “write clean code”. Keep each rule focused. Short rules are followed more reliably. Show one example where a rule could be misread.
Made by Eddie
Stop checking on your agents.
Eddie shows when Cursor’s agent is working and when it’s done, so you can stop watching it.
Questions.
Where do Cursor rules go?
In your repo under .cursor/rules/, one .mdc file per rule, committed so the whole team shares them.
What is a .mdc file?
A Markdown file with a short header (description, file patterns, and whether it always applies) that Cursor reads as a project rule.
Does Cursor read AGENTS.md too?
Yes. Cursor reads AGENTS.md in your project root and subfolders as plain instructions. Project rules in .cursor/rules add more control: you can scope a rule to certain files or apply it only when relevant.