event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
82
58%
Does it follow best practices?
Impact
97%
1.15xAverage score across 6 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/backend-development/skills/event-store-design/SKILL.mdQuality
Discovery
75%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 well-structured with a clear 'Use when' clause that covers the main trigger scenarios, and it targets a distinct niche (event sourcing). However, it could benefit from more concrete action verbs and additional trigger terms that users might naturally use when seeking help with event sourcing.
Suggestions
Add more specific concrete actions such as 'append events to streams, read event streams, implement snapshots, build projections/read models'.
Include additional natural trigger terms like 'CQRS', 'event stream', 'append-only log', 'EventStoreDB', 'event replay', or 'event journal' to improve keyword coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (event sourcing) and some actions ('design and implement event stores', 'choosing event store technologies', 'implementing event persistence patterns'), but the actions are somewhat high-level and not as concrete as listing specific operations like 'append events, read streams, handle snapshots, implement projections'. | 2 / 3 |
Completeness | Clearly answers both 'what' (design and implement event stores for event-sourced systems) and 'when' (explicit 'Use when' clause covering building event sourcing infrastructure, choosing technologies, or implementing persistence patterns). | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'event store', 'event-sourced', 'event sourcing', and 'event persistence patterns', but misses common variations users might say such as 'event stream', 'CQRS', 'append-only log', 'event log', 'EventStoreDB', or specific technology names. | 2 / 3 |
Distinctiveness Conflict Risk | Event sourcing and event stores are a well-defined niche domain. The description is specific enough that it would not easily conflict with general database skills, messaging skills, or other architecture patterns. | 3 / 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.
The skill provides highly actionable, executable code templates for multiple event store implementations, which is its primary strength. However, it is excessively verbose—packing four complete implementations, conceptual tables, and ASCII diagrams into a single file without any progressive disclosure or external references. It also lacks a clear workflow for actually designing and deploying an event store, reading more like a reference catalog than a guided skill.
Suggestions
Extract each implementation template (PostgreSQL, Python, EventStoreDB, DynamoDB) into separate referenced files and keep only a concise overview with links in SKILL.md.
Remove the ASCII architecture diagram, requirements table, and technology comparison table—Claude already understands these concepts. Replace with a brief decision heuristic (e.g., 'Use PostgreSQL if already in stack, EventStoreDB for dedicated event sourcing').
Add a clear numbered workflow: 1) Choose technology, 2) Create schema, 3) Implement store class, 4) Verify with test append/read, 5) Set up subscriptions—with explicit validation steps.
Remove the do's/don'ts section or compress it to 2-3 non-obvious tips that Claude wouldn't already know.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines. The ASCII diagram, requirements table, and technology comparison table explain concepts Claude already knows well. The four full implementation templates (PostgreSQL, Python, EventStoreDB, DynamoDB) are exhaustive but bloated—much of this could be condensed or split into separate files. The do's/don'ts section restates common knowledge. | 1 / 3 |
Actionability | The code templates are concrete, executable, and copy-paste ready. The PostgreSQL schema is complete with indexes and constraints, the Python implementation includes full async methods with optimistic concurrency, and the EventStoreDB and DynamoDB examples are functional with real library calls. | 3 / 3 |
Workflow Clarity | There is no clear multi-step workflow for actually setting up an event store. The templates are presented as standalone blocks without sequencing (e.g., 'first create schema, then implement store class, then verify with test writes'). No validation checkpoints or error recovery steps are provided for the setup process. | 2 / 3 |
Progressive Disclosure | Everything is crammed into a single monolithic file with no references to supporting documents. The four full implementation templates (each 40-80 lines) should be in separate files with the SKILL.md providing an overview and links. There is no bundle structure to support this content. | 1 / 3 |
Total | 7 / 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
- wshobson/agents
- Commit
112197c
- 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.