Rules f(project) skills f(agent)

Discussions
1

Continuing on from Questions regarding Agent Skills and its relationship with .cursorrules - #2 by deanrie

I suspect quite a few people use Cursor as an enabler for a wide variety of programming tasks involving more than one language. I’ve been using Cursor for Rust and JS even though I’m more proficient in Python. So I work on more than one project, generally.

So, if Rules are “per project”, what is the best practice to tell Cursor which rules file applies to current_project ?

On the other hand, skills are “per agent”. Given rules for current_project, what are best practices to assign skills to agents ? And select model as a function of given task to said agents in order to minimize ops costs ? Like I wouldn’t want to waste Opus credits on low skills tasks ? I’m still a bit overwhelmed by multi-agent use :wink:

2

Short-term (Today):

  • Create AGENTS.md in each project with commands, structure, and guidelines

  • Use .cursor/rules/ for project-specific standards (Always Apply)

  • Create separate Agent chats for different task types

  • Switch models on task complexity

Medium-term (Once Skills are stable in Cursor):

  • Install Skills**.cursor/skills/**

  • Create custom Skills for your most frequent workflow

Best Practices:

  • Rules: “Coding standards for THIS project” (e.g., “Always use Rust 1.75+”)

  • Skills: “How to perform THIS task” (e.g., “How to write Rust unit tests”)

  • AGENTS.md: “Universal project info” (works across all tools) => Very good in context and reducing tokens btw.

  • New Chats: Start a new chat for each feature to avoid context overload

I would also suggest to play around with /commands when it comes to specific tasks. You Don’t need Opus for everything, you can plan with Opus and execute with Composer-1

1 Like