emitting-api-events
Build event-driven APIs with webhooks, Server-Sent Events, and real-time notifications. Use when building event-driven API architectures. Trigger with phrases like "add webhooks", "implement events", or "create event-driven API".
68
62%
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-event-emitter/skills/emitting-api-events/SKILL.mdQuality
Discovery
82%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 reasonably well-structured with explicit 'Use when' and trigger phrase guidance, covering the completeness dimension well. However, it lacks specificity in the concrete actions it performs beyond the generic 'build', and some terms like 'events' and 'real-time notifications' could cause overlap with adjacent skills. Adding more specific capabilities would strengthen it.
Suggestions
Add more specific concrete actions, e.g., 'Register webhook endpoints, manage event subscriptions, handle delivery retries, validate webhook signatures, configure SSE streams'.
Improve distinctiveness by clarifying boundaries, e.g., 'Not for WebSocket-based real-time communication or message queue architectures' to reduce conflict risk with similar skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (event-driven APIs) and lists some technologies (webhooks, Server-Sent Events, real-time notifications), but doesn't describe concrete actions beyond 'build'. Lacks specifics like 'register webhook endpoints, manage subscriptions, handle retries, validate signatures'. | 2 / 3 |
Completeness | Explicitly answers both 'what' (build event-driven APIs with webhooks, SSE, real-time notifications) and 'when' (use when building event-driven API architectures, with explicit trigger phrases). Has a clear 'Use when...' clause and trigger examples. | 3 / 3 |
Trigger Term Quality | Includes good natural trigger terms: 'webhooks', 'events', 'event-driven API', 'Server-Sent Events', 'real-time notifications', plus explicit trigger phrases like 'add webhooks', 'implement events'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | While 'webhooks' and 'Server-Sent Events' are fairly distinct, 'events' and 'real-time notifications' could overlap with other skills like general API design, WebSocket skills, or message queue skills. The term 'event-driven' helps but isn't fully disambiguating. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is well-organized with good progressive disclosure and a clear error handling table, but critically lacks any executable code or concrete implementation examples. The instructions read more like a high-level architecture document than an actionable skill—every step describes what to build without showing how. For a skill about building event-driven APIs, the absence of any code snippets (event schema JSON, webhook endpoint code, SSE handler, HMAC signing) significantly undermines its utility.
Suggestions
Add executable code examples for at least the core patterns: event schema definition, webhook HMAC-SHA256 signing, SSE endpoint handler, and transactional outbox query—these are the novel, non-obvious parts Claude needs.
Replace abstract instruction steps like 'Implement the event emitter service' with concrete code showing the actual implementation pattern, even if abbreviated.
Add a validation checkpoint after step 3 (event emitter) and step 5 (webhook delivery) to verify events are flowing correctly before building additional components.
Convert the prose examples into actual code examples showing input/output, such as the event JSON envelope format and a sample webhook delivery request with headers.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary verbosity, particularly in the overview and prerequisites sections which explain concepts Claude already understands. The error handling table and examples section describe patterns at a conceptual level rather than providing lean, actionable content. | 2 / 3 |
Actionability | Despite listing 8 steps, the skill provides zero executable code, no concrete commands, and no copy-paste ready examples. Everything is described abstractly (e.g., 'implement the event emitter service', 'build a webhook subscription management API') without showing actual implementation. The examples section describes scenarios in prose rather than providing code. | 1 / 3 |
Workflow Clarity | The 8 steps provide a reasonable sequence for building the system, and the error handling table adds some validation guidance. However, there are no explicit validation checkpoints or feedback loops within the workflow itself—step 8 mentions tests but there's no 'validate before proceeding' pattern between steps, which is important for this kind of multi-component architecture. | 2 / 3 |
Progressive Disclosure | The skill effectively uses progressive disclosure with clear references to external files: `references/implementation.md` for the full guide, `references/errors.md` for error patterns, and `references/examples.md` for additional examples. References are one level deep and well-signaled, with the main file serving as a clear overview. | 3 / 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
70e9fa4
- 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.