code-quality
MUST be used whenever reviewing a Flows app for code quality, maintainability, or clean code issues — before a PR review, after a feature is complete, or when the user asks for a code review. Do NOT skip linting steps. Triggers: code quality, code review, clean code, refactor, maintainability, technical debt, any type, naming, dead code, duplication, DRY, single responsibility, component size, lint, linting, TypeScript strict, dependency injection, file structure.
65
79%
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/code-quality/SKILL.mdQuality
Discovery
82%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 excels at providing explicit trigger guidance and answering when to use the skill, with a comprehensive list of trigger terms. However, it is weak on specificity — it tells Claude when to activate but doesn't clearly enumerate the concrete actions the skill performs (e.g., what checks are run, what output is produced). The broad trigger terms also create some conflict risk with other code review skills.
Suggestions
Add concrete action descriptions like 'Checks naming conventions, identifies dead code, flags code duplication, validates component size, enforces single responsibility principle' to improve specificity.
Consider narrowing some of the broader trigger terms (e.g., 'code review' alone is very generic) or adding qualifiers like 'Flows app code review' to reduce conflict risk with other code review skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Flows app code quality review) and mentions some actions like linting steps, but it doesn't list multiple concrete actions — it mostly lists trigger terms rather than describing what the skill actually does (e.g., 'checks naming conventions, identifies dead code, flags duplicated logic'). | 2 / 3 |
Completeness | Clearly answers both 'what' (reviewing a Flows app for code quality, maintainability, clean code issues) and 'when' (before a PR review, after a feature is complete, when user asks for code review), with explicit trigger guidance and a comprehensive trigger list. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'code review', 'refactor', 'clean code', 'technical debt', 'dead code', 'duplication', 'DRY', 'lint', 'linting', 'naming', 'single responsibility', 'component size'. These are terms developers naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | The 'Flows app' scoping helps distinguish it, but many trigger terms like 'code review', 'refactor', 'technical debt' are extremely broad and could easily conflict with general code review skills or other framework-specific review skills. | 2 / 3 |
Total | 10 / 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 highly actionable and well-structured code review checklist with excellent executable commands and concrete good/bad code examples throughout. Its main weakness is length — at ~400 lines it's a heavy context load that could benefit from splitting detailed sub-topics (type safety patterns, DI patterns, naming conventions) into referenced files. Some explanatory content about well-known patterns (branded types, discriminated unions, DI) could be trimmed to respect Claude's existing knowledge.
Suggestions
Extract detailed pattern examples (branded types, discriminated unions, DI via context, ViewModel pattern) into a separate PATTERNS.md reference file, keeping only the grep commands and flag criteria in the main skill.
Remove explanatory framing for concepts Claude already knows — e.g., 'Fewer reachable states = easier code to read and change' and 'This enables testing without module-level mocks' — and keep only the concrete detection commands and fix instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is thorough and mostly efficient for its scope, but includes some explanatory content Claude already knows (e.g., explaining what branded types are, what discriminated unions are, why DRY matters). Some code examples like the branded type pattern and DI pattern explanations could be trimmed. However, given the breadth of the checklist, most content earns its place. | 2 / 3 |
Actionability | Exceptionally actionable — nearly every step includes executable bash/shell commands, concrete grep patterns, specific code examples showing good vs bad patterns, and clear tables mapping problems to solutions. The guidance is copy-paste ready throughout. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit ordering ('Work through every step below in order'). Step 1 establishes a hard gate (lint errors must be fixed before proceeding), Step 8 has a hard gate for dead code, and Step 10 provides a structured reporting format. The progression from automated checks → manual review → reporting is logical with clear validation checkpoints. | 3 / 3 |
Progressive Disclosure | The skill is a monolithic ~400-line document with no references to external files for detailed sub-topics. The TypeScript type safety section (Step 2) alone is substantial and could be split into a referenced file. The naming conventions table, file structure template, and pattern examples for DI/ViewModel could all benefit from being in separate reference files. However, the internal structure with numbered steps and sub-sections is well-organized. | 2 / 3 |
Total | 10 / 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 |
metadata_version | 'metadata.version' is missing | Warning |
Total | 9 / 11 Passed | |
- Repository
- cognitedata/builder-skills
- Commit
d6af887
- 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.