CtrlK
BlogDocsLog inGet started
Tessl Logo

check-compiler-errors

Run compile and type-check commands and report failures

58

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./cursor-team-kit/skills/check-compiler-errors/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

78%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, well-organized body with a clear trigger statement, sequenced workflow including a re-run validation loop, and a defined output format. Its main weakness is actionability: it never specifies how to discover or invoke the repo's compile/type-check commands, leaving the executor to infer the concrete tooling.

Suggestions

Add concrete command-discovery guidance, e.g. "Detect build tooling from the repo (package.json scripts, Makefile, Cargo.toml, tsconfig.json) and run the corresponding compile/type-check commands (npm run build, tsc --noEmit, cargo check, make)."

Sharpen step 3 with a prioritization heuristic, e.g. what counts as "highest-confidence" (unused imports, missing types, syntax errors before architectural mismatches).

DimensionReasoningScore

Conciseness

The ~20-line body ("Run the repo's compile and type-check commands. / Summarize errors by file and type. ..." plus the three-bullet Output section) contains zero padding and no explanation of concepts Claude already knows; every token earns its place, matching anchor 5.

5 / 5

Actionability

The workflow steps are followable process directives ("Summarize errors by file and type", "Fix the highest-confidence issues first") but include no concrete commands or discovery heuristics (e.g. how to find the repo's compile commands via package.json scripts, Makefile, or cargo/tsc), matching anchor 3's "some concrete guidance but incomplete; missing key details" rather than anchor 4's executable commands.

3 / 5

Workflow Clarity

The four steps are clearly sequenced and include an explicit validation feedback loop ("Re-run checks until clean or blocked"), fitting anchor 4's "clear sequence with most checkpoints present"; anchor 5's example shows a more explicit validate-then-conditionally-proceed structure with concrete commands, and this is not a destructive/batch operation so no cap applies.

4 / 5

Progressive Disclosure

The skill is under 50 lines with no external references needed and no bundle files present; the Trigger/Workflow/Output sections are well organized, so the simple-skill exception applies and anchor 5 is warranted.

5 / 5

Total

17

/

20

Passed

Description

53%Weight 40%Scale 1-5

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 states a clear, third-person "what" with reasonably distinct domain terms, but it omits any "when to use" trigger guidance and lacks common synonyms like "build errors" or "type errors". It is serviceable but below the quality of the reference good examples, which all pair capabilities with an explicit "Use when..." clause.

Suggestions

Add an explicit trigger clause, e.g. ". Use when compile or type-check failures are blocking local validation or CI, or when the user mentions build or type errors."

Broaden trigger terms with common synonyms users actually say: "build errors", "type errors", "compiler", "CI failures", and file/extension-adjacent terms like "tsc" or "npm run build".

Optionally mention the fix-and-iterate capability in the description (e.g. "...then fix the highest-confidence issues and re-run until clean") to lift specificity from 1-2 actions toward comprehensive coverage.

DimensionReasoningScore

Specificity

"Run compile and type-check commands and report failures" names the domain and two concrete actions (run checks, report failures), matching the 1-2-concrete-actions anchor; it is not comprehensive enough for anchor 4 since fixing, prioritizing, or build/lint coverage is absent.

3 / 5

Completeness

The description has a clear "what" ("Run compile and type-check commands and report failures") but no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines; it is above anchor 2 because the "what" is not vague.

3 / 5

Trigger Term Quality

"compile", "type-check", and "failures" are natural terms users would say, but common variations and synonyms are missing ("build errors", "type errors", "compiler", "lint", language-specific terms like "tsc"), matching anchor 3 rather than the good-coverage anchor 4.

3 / 5

Distinctiveness Conflict Risk

Compile/type-check failure handling is a mostly distinct niche with only minor overlap risk against general build or debugging skills, fitting anchor 4 better than anchor 3's generic-domain example.

4 / 5

Total

13

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
cursor/plugins
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.