Api Health Checker - Auto-activating skill for API Integration. Triggers on: api health checker, api health checker Part of the API Integration skill category.
34
0%
Does it follow best practices?
Impact
100%
1.02xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./planned-skills/generated/16-api-integration/api-health-checker/SKILL.mdQuality
Discovery
0%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 essentially a placeholder with no substantive content. It repeats the skill name as its only trigger term, provides no concrete actions or capabilities, and lacks any explicit guidance on when Claude should select this skill. It would be nearly impossible for Claude to correctly choose this skill from a pool of similar API-related skills.
Suggestions
Add specific capabilities such as 'Checks API endpoint availability, monitors response times, validates HTTP status codes, and reports on service health status'.
Add an explicit 'Use when...' clause like 'Use when the user asks about API uptime, endpoint health, service availability, or needs to verify that an API is responding correctly'.
Expand trigger terms to include natural variations users would say: 'API status', 'health check', 'endpoint monitoring', 'API uptime', 'service health', 'ping API', 'check if API is up'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description provides no concrete actions. 'Api Health Checker' is a name, not a description of capabilities. There are no specific actions like 'checks endpoint availability', 'monitors response times', or 'validates API status codes'. | 1 / 3 |
Completeness | Neither 'what does this do' nor 'when should Claude use it' is meaningfully answered. The description only states the skill name, a duplicate trigger, and a category label. There is no 'Use when...' clause or equivalent. | 1 / 3 |
Trigger Term Quality | The trigger terms are just the skill name repeated twice ('api health checker, api health checker'). Missing natural user terms like 'API status', 'endpoint monitoring', 'uptime check', 'health endpoint', 'API availability', or 'service health'. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so vague that it could overlap with any API-related skill. 'API Integration' as a category and 'api health checker' as a trigger provide minimal differentiation from other API monitoring, testing, or integration skills. | 1 / 3 |
Total | 4 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is an empty placeholder with no substantive content. It contains only generic boilerplate that repeats the phrase 'api health checker' without providing any actionable guidance, code examples, health check patterns, or workflow steps. It fails on every dimension of the rubric.
Suggestions
Add concrete, executable code examples showing how to implement an API health checker (e.g., a Python/Node.js script that pings endpoints and reports status codes, latency, and error rates).
Define a clear workflow: 1) identify endpoints to monitor, 2) implement health check logic, 3) configure alerting thresholds, 4) validate the checker works by simulating failures.
Include specific patterns such as retry logic, timeout configuration, circuit breaker integration, and example health check response schemas (e.g., JSON with status, uptime, dependencies).
Remove all boilerplate sections ('When to Use', 'Example Triggers', 'Capabilities') that describe meta-information Claude doesn't need, and replace with actual technical content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is entirely filler and boilerplate. It explains nothing Claude doesn't already know, provides no specific technical content, and every section restates the same vague idea ('api health checker') without adding value. | 1 / 3 |
Actionability | There is zero concrete guidance—no code, no commands, no API endpoints, no health check patterns, no example requests/responses. Every bullet is abstract and descriptive rather than instructive. | 1 / 3 |
Workflow Clarity | No workflow, steps, or sequence of any kind is provided. There are no validation checkpoints, no error handling guidance, and no process to follow for implementing an API health checker. | 1 / 3 |
Progressive Disclosure | The content is a monolithic block of generic text with no references to supporting files, no structured navigation, and no bundle files to support it. There is no meaningful content to disclose progressively. | 1 / 3 |
Total | 4 / 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 | |
3a2d27d
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.