handling-api-errors
Implement standardized error handling with proper HTTP status codes and error responses. Use when implementing standardized error handling. Trigger with phrases like "add error handling", "standardize errors", or "implement error responses".
65
58%
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 ./plugins/api-development/api-error-handler/skills/handling-api-errors/SKILL.mdQuality
Discovery
67%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 functional and covers the basic requirements with both 'what' and 'when' clauses, which is its strongest aspect. However, it lacks specificity in the concrete actions it performs and could benefit from more diverse trigger terms. The description feels somewhat circular, with the 'Use when' clause essentially restating the first sentence.
Suggestions
Add more specific concrete actions, e.g., 'Creates error handling middleware, maps exceptions to HTTP status codes, formats consistent error response bodies, implements error logging and validation error handling.'
Expand trigger terms to include natural variations users would say: 'API errors', 'exception handling', 'error middleware', 'status codes', '4xx/5xx responses', 'error format'.
Make the 'Use when' clause more informative rather than circular — e.g., 'Use when building or refactoring API endpoints that need consistent error responses, or when error handling is inconsistent across a codebase.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (error handling) and mentions some actions like 'proper HTTP status codes and error responses', but doesn't list multiple concrete specific actions (e.g., creating error middleware, mapping exceptions to status codes, formatting error payloads, logging errors). | 2 / 3 |
Completeness | It explicitly answers both 'what' (implement standardized error handling with HTTP status codes and error responses) and 'when' (with a 'Use when' clause and explicit trigger phrases), meeting the criteria for completeness. | 3 / 3 |
Trigger Term Quality | Includes some relevant trigger phrases like 'add error handling', 'standardize errors', and 'implement error responses', but misses common natural variations users might say such as 'error middleware', 'exception handling', 'API errors', 'status codes', '500 error', or 'error format'. | 2 / 3 |
Distinctiveness Conflict Risk | While it focuses on error handling specifically, the description is somewhat generic and could overlap with general API development skills, middleware skills, or HTTP response handling skills. The term 'standardized error handling' is moderately distinctive but not sharply differentiated. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-structured overview of API error handling with clear sections and a logical workflow, but falls short on actionability by describing what to build rather than showing executable code. The content is moderately concise but could be tightened, and the referenced bundle files don't exist, undermining the progressive disclosure strategy. The error handling table is a strong addition but the lack of validation checkpoints in the workflow and absence of concrete code examples limit its effectiveness.
Suggestions
Add executable code examples for at least the typed error classes and the centralized error handler middleware, rather than just describing them in prose.
Include explicit validation checkpoints in the workflow, e.g., 'After step 4, run the test suite to verify all error types return correct status codes before adding monitoring integration.'
Provide the referenced bundle files (implementation.md, errors.md, examples.md) or remove the references if they don't exist, as broken references reduce trust in the skill.
Trim the prerequisites section—Claude doesn't need to be told what a structured logging library or error monitoring service is—and condense the overview which largely repeats the instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but includes some unnecessary verbosity. The overview restates what the instructions cover, the prerequisites list items Claude would know to use, and some instructions describe concepts (like RFC 7807 fields) that could be more terse. However, it avoids egregious over-explanation. | 2 / 3 |
Actionability | The instructions provide a clear sequence of what to do but lack executable code examples. Steps describe actions at a high level ('Create typed error classes', 'Implement centralized error handling middleware') without providing concrete, copy-paste-ready implementations. The examples section shows JSON output format but not the actual code to produce it. | 2 / 3 |
Workflow Clarity | The 9-step workflow is clearly sequenced from audit through testing, which is good. However, there are no explicit validation checkpoints or feedback loops between steps—for instance, no step says 'verify the middleware catches all error types before proceeding' or 'run tests after step 4 to confirm basic handling works before adding monitoring.' | 2 / 3 |
Progressive Disclosure | The skill references external files (implementation.md, errors.md, examples.md) for deeper content, which is good structure. However, no bundle files are provided, so these references are broken. The main file itself is somewhat long with inline tables and detailed instructions that could benefit from better separation, though the section organization is reasonable. | 2 / 3 |
Total | 8 / 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 |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
3a2d27d
- 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.