check-compiler-errors
Run compile and type-check commands and report failures
50
37%
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 ./cursor-team-kit/skills/check-compiler-errors/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 conveys a basic idea of what the skill does—running compile and type-check commands—but lacks a 'Use when' clause, specific tool/language references, and natural trigger term variations. It is too terse to reliably distinguish itself from other build/lint/CI-related skills in a large skill library.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to compile code, check for type errors, run tsc, or fix build failures.'
Include natural trigger terms and variations users would say, such as 'build', 'build errors', 'tsc', 'typescript', 'compilation errors', '.ts files'.
List more specific concrete actions, e.g., 'Runs TypeScript compiler (tsc), reports type errors with file locations, and suggests fixes for compilation failures.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a domain (compilation/type-checking) and some actions (run commands, report failures), but doesn't list specific concrete actions like which languages, tools, or what 'report failures' entails in detail. | 2 / 3 |
Completeness | Describes what the skill does (run compile/type-check commands and report failures) but has no 'Use when...' clause or equivalent explicit trigger guidance, which per the rubric caps completeness at 2, and the 'what' is also fairly thin, placing this at 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'compile', 'type-check', and 'failures', but misses common user variations such as 'build', 'tsc', 'typescript', 'build errors', 'compilation errors', or specific tool names. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to compile/type-check workflows, but could overlap with general build tools, linting, or CI/CD skills. The lack of language or toolchain specificity increases conflict risk. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a high-level outline rather than actionable guidance. While it's well-structured and concise, it lacks any concrete commands, code examples, or ecosystem-specific instructions that would allow Claude to actually perform the task. It reads more like a task description than a skill that teaches Claude something it doesn't already know.
Suggestions
Add concrete example commands for common ecosystems (e.g., `tsc --noEmit`, `cargo check`, `go build ./...`, `javac`) so Claude knows what to run.
Include an example of the expected error summary output format (e.g., a grouped table or structured list) to make the Output section actionable.
Add guidance on how to discover the repo's compile/type-check commands (e.g., check package.json scripts, Makefile targets, CI config files).
Provide a concrete example of the fix-and-recheck loop, showing how to parse a compiler error and apply a fix.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is brief and doesn't over-explain concepts Claude knows, but it's also so sparse that it's mostly filler — the workflow steps are generic descriptions rather than earning their tokens with specific, useful information. | 2 / 3 |
Actionability | No concrete commands, code examples, or specific tool invocations are provided. 'Run the repo's compile and type-check commands' is entirely vague — it doesn't specify how to discover or run these commands, nor does it give examples for common ecosystems (tsc, gcc, cargo check, etc.). | 1 / 3 |
Workflow Clarity | Steps are listed in a logical sequence and include a re-run/feedback loop (step 4), but there are no concrete validation checkpoints, no specific commands, and no guidance on what 'blocked' means or how to handle it. | 2 / 3 |
Progressive Disclosure | For a simple, short skill with no bundle files, the content is appropriately organized into clear sections (Trigger, Workflow, Output) without unnecessary nesting or references. The structure is clean for its scope. | 3 / 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
- cursor/plugins
- Commit
7dd9fea
- 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.