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.
The description is strong in trigger coverage, completeness, and distinctiveness, clearly identifying when the skill should be used and targeting a very specific niche. Its main weakness is that the 'what' portion is somewhat thin—'configure' is a single broad verb that doesn't convey the range of specific actions the skill can perform (e.g., creating, editing, migrating, or validating rules).
Suggestions
Expand the capability description with more specific actions, e.g., 'Create, edit, migrate, and validate Cursor project rules' to improve specificity.
| 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'. What does configuring entail—creating, editing, migrating, validating? | 2 / 3 |
Completeness | Clearly answers 'what' (configure Cursor project rules using specific file formats) and 'when' (explicit 'Triggers on' clause with multiple trigger terms), satisfying both requirements. | 3 / 3 |
Trigger Term Quality | Explicitly lists multiple natural trigger terms including 'cursorrules', '.cursorrules', 'cursor rules', 'cursor config', 'cursor project settings', '.mdc rules', 'project rules'—covering common variations a user would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche—Cursor IDE project rules with distinct file extensions (.mdc, .cursorrules). Very unlikely to conflict with other skills given the specificity of the tooling. | 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 solid, highly actionable skill with excellent concrete examples covering both modern and legacy Cursor rules configuration. Its main weaknesses are moderate verbosity from extensive inline examples that could be split into referenced files, and a migration workflow that lacks explicit validation checkpoints. The content structure is logical but would benefit from offloading detailed examples to support progressive disclosure.
Suggestions
Add explicit verification steps to the migration workflow, e.g., 'After creating .mdc files, open Chat and type @Cursor Rules to confirm all rules appear before deleting .cursorrules'
Consider moving the three complete project rule examples (project-context, react-patterns, api-routes) into a separate EXAMPLES.md file and referencing it from the main skill to improve progressive disclosure and reduce token usage
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly well-structured but includes some content that could be tightened. The multiple complete project examples (project-context, react-patterns, api-routes) are extensive and somewhat redundant in demonstrating the same pattern. The legacy .cursorrules section and enterprise considerations add useful but slightly verbose content. However, it avoids explaining basic concepts Claude would know. | 2 / 3 |
Actionability | Excellent actionability with fully concrete, copy-paste-ready examples throughout. The frontmatter field table, file naming conventions, complete .mdc file examples with real-world code, migration steps, debugging instructions, and @file reference syntax are all specific and executable. Every section provides concrete guidance rather than abstract descriptions. | 3 / 3 |
Workflow Clarity | The migration workflow (steps 1-4) is clearly sequenced but lacks explicit validation checkpoints — step 4 says 'after verifying all rules load' without explaining how to verify. The debugging section is separate rather than integrated as a validation step. For a configuration skill, the workflows are adequate but the migration process could benefit from a verification feedback loop. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear headers and logical sections, but it's a long monolithic document (~180 lines of substantive content) with no bundle files to offload detail into. The three complete project rule examples could be split into a separate examples file. External resource links are provided but internal progressive disclosure is lacking — everything is inline. | 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 | |
3a2d27d
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.