eslint-plugin-custom-rule
USE THIS when asked to create a new eslint plugin rule for the eslint-plugin-cds package
76
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/eslint-plugin-custom-rule/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 well-targeted with a clear 'Use when' clause and highly specific trigger terms that make it easy to distinguish from other skills. Its main weakness is a lack of detail about the concrete actions involved in creating an eslint plugin rule (e.g., scaffolding, testing, AST patterns). Overall it is functional and effective for skill selection despite being light on capability details.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Scaffolds rule files, writes AST visitors, adds unit tests, and registers the rule in the plugin index.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (eslint plugin rule) and the specific package (eslint-plugin-cds), but doesn't describe concrete actions beyond 'create a new eslint plugin rule' — no details about what the creation entails (e.g., writing AST visitors, adding tests, registering the rule). | 2 / 3 |
Completeness | It explicitly answers both 'what' (create a new eslint plugin rule for eslint-plugin-cds) and 'when' (opens with 'USE THIS when asked to...'), providing a clear trigger condition. | 3 / 3 |
Trigger Term Quality | Includes highly specific natural trigger terms: 'eslint plugin rule', 'eslint-plugin-cds', and 'create a new'. A user asking for this exact task would naturally use these terms, and the specificity of 'eslint-plugin-cds' makes false matches unlikely. | 3 / 3 |
Distinctiveness Conflict Risk | The description targets a very specific niche — creating rules for the eslint-plugin-cds package specifically — making it highly unlikely to conflict with other skills, even other ESLint-related ones. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable process-oriented guide for creating ESLint plugin rules with clear sequencing and useful file references. However, it lacks executable code examples (no AST visitor patterns, no test case templates), has no validation/verification steps after implementation, and could be more concise by trimming repeated cautionary language about not making assumptions.
Suggestions
Add a concrete code example showing a minimal create() function with an AST visitor method and a corresponding test case, so Claude has a copy-paste-ready template rather than needing to read referenced files.
Add a validation step at the end of the workflow: e.g., 'Run `npm test -- --filter=<rule-name>` to verify all test cases pass. If tests fail, review the rule logic and fix before proceeding.'
Trim the repeated cautionary language in steps 2-3 ('Do not make assumptions', 'ask for clarification') into a single concise note at the top, freeing tokens for more actionable content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary verbosity, particularly in steps 2-3 where it repeatedly emphasizes asking for clarification and not making assumptions. Some sentences could be tightened (e.g., 'The script should be used every time a new rule is created' is redundant given the process already says to run it). | 2 / 3 |
Actionability | The skill provides concrete file paths and references to existing rules as examples, which is helpful. However, it lacks executable code snippets—there's no example of what a create() function looks like, no example AST visitor pattern, and no example test case structure. The guidance is specific in terms of process but incomplete in terms of implementation details. | 2 / 3 |
Workflow Clarity | The 5-step process is clearly sequenced and logically ordered, with explicit gates (e.g., 'Do not proceed until...'). However, there are no validation checkpoints—no step to verify the rule works, no linting test command, no feedback loop for fixing issues after writing the rule. For a multi-step code generation workflow, the absence of a 'run tests and verify' step is a notable gap. | 2 / 3 |
Progressive Disclosure | The skill references specific files (custom-rule.ts, no-v7-imports.ts, scaffold-new-rule.mjs) which is good for navigation, but no bundle files are provided to support these references. The content is somewhat monolithic—the detailed process steps, directory placement, and implementation guidance are all inline rather than structured with clear sections pointing to supporting documentation. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- coinbase/cds
- Commit
f79a780
- Reviewed
Table of Contents
Is this your skill?
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.