Configure Cursor project rules using .cursor/rules/*.mdc files and legacy .cursorrules. Triggers on "cursorrules", ".cursorrules", "cursor rules", "cursor config", "cursor project settings", ".mdc rules", "project rules".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/cursor-pack/skills/cursor-rules-config/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid skill description with excellent trigger term coverage and clear distinctiveness. Its main weakness is the lack of specific action verbs beyond 'configure' — listing concrete capabilities like creating, editing, migrating, or validating rules would strengthen it. The explicit trigger list is a strong pattern that aids skill selection.
Suggestions
Expand the 'what' portion with more specific actions, e.g., 'Creates, edits, migrates, and validates Cursor project rules' instead of just 'Configure'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Cursor project rules) and mentions specific file paths (.cursor/rules/*.mdc, .cursorrules), but doesn't list multiple concrete actions beyond 'configure'. It lacks detail on what configuring entails (e.g., creating, editing, validating, migrating). | 2 / 3 |
Completeness | Clearly answers both 'what' (configure Cursor project rules using specific file formats) and 'when' (explicit trigger terms listed). The 'Triggers on' clause serves as an explicit 'Use when' equivalent. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including variations like 'cursorrules', '.cursorrules', 'cursor rules', 'cursor config', 'cursor project settings', '.mdc rules', and 'project rules'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — Cursor rules configuration is a very specific niche. The trigger terms are unique to this tool and unlikely to conflict with other skills. The mention of .mdc files and .cursorrules makes it unmistakable. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive and highly actionable skill for configuring Cursor project rules, with excellent concrete examples and clear table-based reference material. Its main weaknesses are verbosity (multiple full project examples inflate the token cost) and a migration workflow that lacks explicit validation checkpoints. The content would benefit from trimming redundant examples and integrating verification steps into multi-step processes.
Suggestions
Reduce the complete project rules examples from three to one representative example, and move additional examples to a separate EXAMPLES.md file with a clear reference link.
Add explicit validation steps to the migration workflow, e.g., 'Open Chat, type @Cursor Rules, and confirm all migrated rules appear in the list before deleting .cursorrules'.
Consider moving the Enterprise Considerations and Legacy .cursorrules sections to separate referenced files to keep the main skill lean and focused on the modern .mdc approach.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good use of tables and code examples, but it's quite lengthy for what is essentially a configuration reference. The multiple complete project examples (project-context, react-patterns, api-routes) are verbose and could be condensed to one representative example. The legacy .cursorrules section also includes a full example that adds bulk. | 2 / 3 |
Actionability | Highly actionable with complete, copy-paste ready .mdc file examples including proper frontmatter, glob patterns, and markdown content. The tables clearly define field behavior, file naming conventions are concrete, and the migration steps are specific. Code examples are fully executable and realistic. | 3 / 3 |
Workflow Clarity | The migration workflow (steps 1-4) is clear but lacks a validation checkpoint — step 4 says 'after verifying all rules load' without explaining how to verify. The debugging section helps but is separate from the migration workflow. For a configuration task that could break AI behavior, explicit verification steps should be integrated into the workflow. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's monolithic — all content is inline in a single file with no references to separate detailed documents. The three complete project rule examples could be split into a separate examples file, and the enterprise considerations could be a separate reference. External links at the end are good but the main body is heavy. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3e83543
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.