switching between tools sucks because none of the config transfers. i've got .cursor/rules files tuned for how i work, and if i switch to copilot or claude code for a week, all of that context is gone. i have to re-explain my project conventions from scratch every session.
i built a linter for cursor rules partly because of this. wanted to at least know if my rules were valid before i invested time tuning them for a tool i might have to abandon next month. the whole ecosystem feels like it's one pricing change away from forcing a migration nobody's config is ready for.
Cursor deprecated rules and proposed to migrate to agent skills, putting skills to .claude/skills makes those skills discoverable by major tools. Same goes for AGENTS.md as alternative to coplot-intructions
rules aren't deprecated though. cursor's docs still have a full active page for them with four types (project rules, user rules, team rules, AGENTS.md), and the v2.4 changelog explicitly positions skills as complementary: "compared to always-on, declarative rules, skills are better for dynamic context discovery and procedural how-to instructions."
there is a /migrate-to-skills command, but from what i can tell it converts dynamic rules and slash commands into skills, not all rules. the use cases are different: rules are declarative and always-on ("use TypeScript strict mode"), skills are procedural and on-demand ("here's how to deploy to AWS").
you're right about .claude/skills/ being cross-tool discoverable though. cursor auto-discovers .claude/skills/, .codex/skills/, and .cursor/skills/. that part of the ecosystem is converging. but for the kind of stuff most people put in .cursor/rules/ (coding conventions, style enforcement, framework patterns), rules are still the right tool.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
switching between tools sucks because none of the config transfers. i've got .cursor/rules files tuned for how i work, and if i switch to copilot or claude code for a week, all of that context is gone. i have to re-explain my project conventions from scratch every session.
i built a linter for cursor rules partly because of this. wanted to at least know if my rules were valid before i invested time tuning them for a tool i might have to abandon next month. the whole ecosystem feels like it's one pricing change away from forcing a migration nobody's config is ready for.
Cursor deprecated rules and proposed to migrate to agent skills, putting skills to .claude/skills makes those skills discoverable by major tools. Same goes for AGENTS.md as alternative to coplot-intructions
rules aren't deprecated though. cursor's docs still have a full active page for them with four types (project rules, user rules, team rules, AGENTS.md), and the v2.4 changelog explicitly positions skills as complementary: "compared to always-on, declarative rules, skills are better for dynamic context discovery and procedural how-to instructions."
there is a /migrate-to-skills command, but from what i can tell it converts dynamic rules and slash commands into skills, not all rules. the use cases are different: rules are declarative and always-on ("use TypeScript strict mode"), skills are procedural and on-demand ("here's how to deploy to AWS").
you're right about .claude/skills/ being cross-tool discoverable though. cursor auto-discovers .claude/skills/, .codex/skills/, and .cursor/skills/. that part of the ecosystem is converging. but for the kind of stuff most people put in .cursor/rules/ (coding conventions, style enforcement, framework patterns), rules are still the right tool.