This is a well-structured, highly actionable skill with a clear 5-step workflow, executable commands, and a precise output schema. Its main weaknesses are moderate verbosity (particularly in the scope exclusion list and LSP section) and the inability to verify referenced language pattern files. The cross-validator boundary definitions and severity precedence rules demonstrate thoughtful design.

Suggestions

Trim the 'MUST NOT report on' scope list to a single sentence like 'Only checks error handling completeness — not style, security, chaining, wrapping, logging config, or formatting (owned by other validators).'

Condense the LSP enrichment section (Step 3) into a compact table mapping language → what to hover → why, rather than separate paragraphs per language.

Dimension	Reasoning	Score
Conciseness	The skill is mostly efficient and avoids explaining basic concepts, but the scope declaration's 'MUST NOT report on' list is lengthy and could be trimmed. The LSP section (Step 3) is verbose with per-language explanations that could be more compact. The repeated clean-pass JSON example adds tokens.	2 / 3
Actionability	Provides fully executable bash commands for getting diffs, concrete file extension mappings, a precise JSON output schema with field-level definitions, and clear categorization rules (HARD/SHOULD/WARN). The guidance is specific and copy-paste ready throughout.	3 / 3
Workflow Clarity	The 5-step workflow is clearly sequenced with explicit fallback chains (git diff order), batch processing guidance for large changesets, intra-rule precedence logic, and clear pass/fail criteria. The LSP step has explicit skip/fallback behavior. The cross-validator scope boundaries prevent ambiguity.	3 / 3
Progressive Disclosure	The skill correctly references external `languages/go.md`, `languages/python.md`, and `languages/typescript.md` files for language-specific patterns, which is good progressive disclosure. However, no bundle files were provided, so we cannot verify these references exist. The main file itself is quite long (~130 lines of content) and the LSP enrichment details could potentially be split out.	2 / 3
	Total	10 / 12 Passed

Description

22%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This description is too terse and vague to effectively guide skill selection. It lacks concrete actions, natural trigger terms, and any explicit 'Use when...' guidance. While the domain of error handling validation is somewhat distinctive, the description fails to communicate what specific checks are performed or when the skill should be invoked.

Suggestions

Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks to review error handling, check exception coverage, audit try/catch blocks, or verify fault tolerance in code.'

List specific concrete actions such as 'Checks for uncaught exceptions, validates error propagation paths, identifies missing try/catch blocks, and audits error logging patterns.'

Include natural keyword variations users would say, such as 'exception handling', 'try/catch', 'error recovery', 'unhandled errors', and specific language names if applicable.

Dimension	Reasoning	Score
Specificity	The description names a single vague action ('validate error handling completeness') without listing concrete actions like checking try/catch blocks, verifying exception propagation, or auditing error codes. It's abstract and doesn't explain what validation entails.	1 / 3
Completeness	The description weakly addresses 'what' (validate error handling completeness) but completely lacks any 'when' clause or explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also too vague to merit even that.	1 / 3
Trigger Term Quality	It includes some relevant terms like 'error handling' and 'validate' that users might naturally use, but misses common variations like 'exception handling', 'try/catch', 'error codes', 'fault tolerance', or 'error recovery'.	2 / 3
Distinctiveness Conflict Risk	The focus on error handling validation is somewhat specific, but 'across languages' is broad and could overlap with general code review, linting, or static analysis skills. The lack of concrete scope makes conflict with similar skills likely.	2 / 3
	Total	6 / 12 Passed

Validation

81%

Warnings & errors only

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
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	9 / 11 Passed

Reviewed

20 days ago

Table of Contents

Discovery Implementation Validation