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.
63
73%
Does it follow best practices?
Impact
—
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
89%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 is a solid description that clearly communicates both what the skill does and when to use it, with good trigger terms. Its main weakness is that the specificity of capabilities could be improved by listing more concrete actions beyond the high-level 'exposes functions as REST API endpoints'. The term 'iii' is domain-specific and assumes familiarity, which is appropriate if the skill set is within that ecosystem.
Suggestions
Add more specific concrete actions such as 'define routes, handle HTTP methods (GET, POST, PUT, DELETE), parse request/response bodies, set status codes' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It 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, etc. | 2 / 3 |
Completeness | Clearly answers both what ('Exposes iii functions as REST API endpoints') and when ('Use when building HTTP APIs, webhooks, or inbound request handling where iii owns the route') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'REST API', 'endpoints', 'HTTP APIs', 'webhooks', 'inbound request handling', 'route'. These cover common variations of how users would describe this need. | 3 / 3 |
Distinctiveness Conflict Risk | The description is clearly scoped to exposing iii functions as REST endpoints, with the qualifier 'where iii owns the route' further narrowing the niche. This is unlikely to conflict with general coding or other API-related skills. | 3 / 3 |
Total | 11 / 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. Its main weaknesses are the lack of inline executable code (relying entirely on external reference files) and missing validation/verification steps in the workflow. Some sections are slightly redundant, particularly the 'When to Use' and 'Boundaries' sections which overlap with 'Pattern Boundaries'.
Suggestions
Add a minimal but complete inline code example (e.g., a single GET endpoint) so the skill is actionable without needing to open reference files.
Add a validation step after worker setup and route registration, such as 'Verify the route is live: curl http://localhost:3111/your-path' to improve workflow clarity.
Consolidate 'When to Use', 'Boundaries', and 'Pattern Boundaries' into a single section to reduce redundancy and improve conciseness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some redundancy. The 'When to Use' and 'Boundaries' sections at the bottom repeat information already conveyed in 'Pattern Boundaries' and the description. The 'Common Patterns' section largely restates what's already covered in the table and key concepts. Some trimming would improve token efficiency. | 2 / 3 |
Actionability | The skill provides concrete API shapes (registerFunction, registerTrigger configs, response objects) and references full working examples, but the SKILL.md itself contains no executable code — only pseudocode-level patterns and a reference link. 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, and the 'Adapting This Pattern' section gives sequenced guidance (e.g., add worker first, then register functions). However, there are no explicit validation checkpoints — no step to verify the worker is running, no verification that routes are registered correctly, and no error recovery guidance for common failures like port conflicts or misconfigured triggers. | 2 / 3 |
Progressive Disclosure | The skill provides a clear overview with well-signaled one-level-deep references to implementation files in JS, Python, and Rust, plus cross-references to related skills (iii-http-middleware, iii-queue-processing, iii-http-invoked-functions). Content is appropriately split between overview and reference implementations. Note: bundle files were not provided so path accuracy cannot be verified, but the structure is sound. | 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
a7ebbbb
- 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.