iii-http-endpoints
Exposes iii functions as REST API endpoints. Use when building HTTP APIs, webhooks, or inbound request handling where iii owns the route.
70
62%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/iii-http-endpoints/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 has a solid structure with an explicit 'Use when' clause that clearly separates what the skill does from when to use it. However, the term 'iii' is opaque and may confuse skill selection, and the specific capabilities could be more concretely enumerated. The trigger terms cover the main use cases but miss some common variations users might naturally use.
Suggestions
Add more specific concrete actions beyond 'exposes as endpoints', such as 'defines routes, handles HTTP methods (GET, POST, PUT, DELETE), parses request/response bodies'.
Expand trigger terms to include common variations like 'web server', 'routes', 'HTTP handler', 'API server', 'request/response' in the 'Use when' clause.
Clarify what 'iii' refers to so that the description is self-contained and meaningful for skill selection without prior context.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (REST API endpoints) and a few actions (building HTTP APIs, webhooks, inbound request handling), but doesn't list concrete specific actions like defining routes, handling GET/POST methods, parsing request bodies, returning responses, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (exposes iii functions as REST API endpoints) and 'when' (building HTTP APIs, webhooks, or inbound request handling where iii owns the route) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'REST API', 'endpoints', 'webhooks', 'HTTP APIs', and 'request handling', but misses common variations users might say such as 'web server', 'routes', 'HTTP handler', 'API server', 'express', or 'listener'. The term 'iii' is opaque and not a natural trigger term. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'iii functions' and 'iii owns the route' provides some specificity to a particular framework/system, but 'REST API endpoints' and 'webhooks' are broad enough to potentially overlap with other API-related skills. The 'iii' reference is distinctive but unclear without context. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured skill with good progressive disclosure and clear cross-references to related patterns and full implementations. Its main weaknesses are the lack of an inline executable code example (relying entirely on external reference files) and some redundancy in the boundary/usage sections. Adding a minimal inline example and consolidating the repeated boundary guidance would meaningfully improve it.
Suggestions
Add a minimal inline executable code example (e.g., a simple GET endpoint) in the skill body so Claude has copy-paste-ready code without needing to read external files.
Consolidate the 'Pattern Boundaries', 'When to Use', and 'Boundaries' sections into a single section to eliminate redundancy and save tokens.
Add explicit numbered steps for creating a new endpoint (e.g., 1. Register worker, 2. Define handler with registerFunction, 3. Bind route with registerTrigger, 4. Verify by hitting the endpoint) to improve workflow clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but has some redundancy — the 'When to Use' and 'Boundaries' sections at the end repeat information already covered in 'Pattern Boundaries'. The 'Key Concepts' preamble 'Use the concepts below when they fit the task' and similar meta-commentary add minor bloat. The architecture diagram and table are concise and useful. | 2 / 3 |
Actionability | The skill provides concrete API patterns (registerFunction, registerTrigger, response shape) and references full working examples, but the skill body itself contains no executable code — only descriptions of what code commonly includes. The 'Common Patterns' section lists code fragments but not a complete, copy-paste-ready example inline. | 2 / 3 |
Workflow Clarity | The architecture diagram provides a clear request flow sequence, and the common patterns section lists the steps implicitly (register worker → register function → register trigger). However, there are no explicit numbered steps for creating an endpoint, no validation checkpoints, and no error handling guidance for common failure modes like port conflicts or malformed requests. | 2 / 3 |
Progressive Disclosure | The skill provides a clear overview with well-signaled one-level-deep references to full implementations in JS, Python, and Rust, plus cross-references to related skills (iii-http-middleware, iii-http-invoked-functions, iii-queue-processing). Content is appropriately split between the overview and reference files. | 3 / 3 |
Total | 9 / 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
- iii-hq/iii
- Commit
8921efa
- 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.