How to check code by linting, building, and testing.
73
60%
Does it follow best practices?
Impact
93%
1.60xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/lint-build-test/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 is a brief how-to summary that names three concrete activities (linting, building, testing) but lacks depth in each and entirely omits trigger guidance. It reads more like a title than a description, providing insufficient detail for Claude to confidently select this skill from a large pool. Adding explicit 'Use when...' triggers and more specific capability details would significantly improve it.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to lint, build, compile, run tests, or check code quality before committing.'
Include common trigger term variations such as 'lint', 'run tests', 'compile', 'type check', 'CI', 'pre-commit checks', and specific tool names if applicable.
Expand the capability description with more specifics, e.g., 'Runs linters to catch style and syntax issues, builds the project to verify compilation, and executes test suites to validate correctness.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (code checking) and lists three actions (linting, building, testing), but doesn't elaborate on specifics like which languages, tools, or what kind of testing. | 2 / 3 |
Completeness | Describes 'what' at a high level (linting, building, testing) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also weak, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'linting', 'building', and 'testing' that users might mention, but misses common variations like 'lint', 'compile', 'run tests', 'CI', 'check code quality', 'type check', or specific tool names. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of linting, building, and testing is somewhat distinctive as a code quality checking workflow, but 'check code' is broad enough to overlap with code review, debugging, or CI/CD skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
87%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise skill that provides clear, actionable commands for checking code in a monorepo. Its main weakness is the lack of explicit error handling/recovery steps — it tells Claude to 'report any errors' but doesn't specify whether to continue after failures or how to handle common error scenarios. Overall it's a strong, practical skill.
Suggestions
Add error recovery guidance: specify whether to stop on first failure or continue, and what to do when lint/build/test fails (e.g., 'If lint:fix fails, review errors and fix manually before proceeding to build').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section is lean and purposeful. No unnecessary explanations of what linting or building is. The categorization of file types and decision tree are compact and informative. | 3 / 3 |
Actionability | Provides specific, copy-paste ready commands (e.g., `yarn workspace <package-name> lint:fix`, `yarn lint:fix`) with clear parameterization. The decision logic for what to run is concrete and unambiguous. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (analyze → determine → run), but there are no explicit validation checkpoints or error recovery feedback loops. The skill says 'report any errors' but doesn't describe what to do when a step fails (e.g., fix lint errors and re-run, or stop on build failure). | 2 / 3 |
Progressive Disclosure | For a simple skill under 50 lines, the content is well-organized with clear sections and logical grouping (specific package vs. monorepo). No need for external references given the scope. | 3 / 3 |
Total | 11 / 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.
d93dc41
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.