refactoring-typescript
TypeScript refactoring: SOLID principles, DRY, type safety improvements, and eliminating code smells
51
55%
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 ./skills/refactoring-typescript/SKILL.mdQuality
Discovery
32%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 identifies a clear domain (TypeScript refactoring) and lists relevant principles, but it reads more like a topic label than a functional skill description. It lacks a 'Use when...' clause, concrete action verbs, and sufficient trigger term coverage to reliably distinguish it from general code quality or refactoring skills.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to refactor TypeScript code, improve type safety, reduce duplication, or apply SOLID principles to .ts files.'
Replace abstract categories with concrete actions, e.g., 'Extracts interfaces, introduces generics, removes duplicate logic, replaces magic numbers, and splits large classes in TypeScript codebases.'
Include natural trigger term variations users might say, such as 'clean up code', 'improve code quality', '.ts files', 'technical debt', or 'code review'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (TypeScript refactoring) and lists some categories of actions (SOLID principles, DRY, type safety improvements, eliminating code smells), but these are more like abstract categories than concrete specific actions like 'extract interface', 'replace magic numbers', or 'introduce generics'. | 2 / 3 |
Completeness | Describes what the skill does (TypeScript refactoring with various principles) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause should cap completeness at 2, and since the 'what' is also somewhat vague, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'TypeScript', 'refactoring', 'SOLID', 'DRY', 'type safety', and 'code smells' that users might naturally use, but misses common variations like 'clean up code', 'improve code quality', 'reduce duplication', 'extract method', or file extensions like '.ts'. | 2 / 3 |
Distinctiveness Conflict Risk | The TypeScript-specific focus and refactoring domain provide some distinctiveness, but 'code smells' and 'SOLID principles' could overlap with general code review or other language-specific refactoring skills. The lack of explicit triggers increases conflict risk. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
77%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, well-structured refactoring skill with excellent actionability — every recommendation comes with executable TypeScript examples. The workflow section provides clear validation checkpoints. The main weakness is moderate verbosity: several examples and SOLID definitions cover ground Claude already knows, and the file could benefit from splitting detailed examples into a referenced file.
Suggestions
Trim SOLID Principles to just the actionable heuristics (e.g., 'if the function name needs "and", split it') without restating the principle names/definitions Claude already knows.
Move the longer before/after examples (Strategy Pattern, Async Flattening) into a separate EXAMPLES.md and reference it from the main file to improve progressive disclosure and reduce token cost.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good use of tables and code examples, but some sections explain concepts Claude already knows well (SOLID principle definitions, what guard clauses are). The before/after examples are valuable but there are many of them, making the file longer than necessary for an experienced AI assistant. | 2 / 3 |
Actionability | Every recommendation is backed by concrete, executable TypeScript code examples with clear before/after patterns. The smell-to-fix table is immediately actionable, and commands like `tsc --noEmit` and `eslint` are specific and copy-paste ready. | 3 / 3 |
Workflow Clarity | The 'Before You Start' section establishes a clear workflow: ensure tests pass → refactor in small steps → run tsc/eslint after each change → never change behavior. This is a well-sequenced process with explicit validation checkpoints (tests green, tsc --noEmit, eslint) and a clear constraint (one change at a time). The 'When Not to Refactor' section adds important guardrails. | 3 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers and a logical progression from setup to principles to examples to caveats. However, at ~150 lines with 6 full code examples, some content (e.g., the strategy pattern example, async flattening) could be split into a separate EXAMPLES.md or PATTERNS.md to keep the main file leaner. No bundle files exist to offload to. | 2 / 3 |
Total | 10 / 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
- ucdavis/ai-skills-registry
- Commit
c0b2e4b
- 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.