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 'what' and 'when' clause, and targets a distinct technical niche. Its main weakness is that the capabilities described are somewhat high-level rather than listing specific concrete actions, and the trigger terms could be broader to capture related concepts like CQRS, event streams, or specific technologies.
Suggestions
Add more specific concrete actions such as 'append events to streams, read event streams, implement snapshots, build projections/read models'.
Expand trigger terms to include related concepts users might mention: 'CQRS', 'event stream', 'domain events', 'append-only log', 'EventStoreDB', 'event replay'.
| 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' (Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns) with an explicit 'Use when...' clause. | 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', 'EventStoreDB', 'event log', or 'domain events'. | 2 / 3 |
Distinctiveness Conflict Risk | Event sourcing and event stores are a well-defined niche within software architecture. The description is specific enough to be clearly distinguishable from general database skills, messaging skills, or broader architecture skills. | 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 across multiple technologies, which is its primary strength. However, it is severely bloated — inlining four complete implementations plus conceptual tables that Claude doesn't need. It lacks workflow sequencing for actually setting up and validating an event store, and desperately needs progressive disclosure to split templates into separate referenced files.
Suggestions
Move each implementation template (PostgreSQL, Python, EventStoreDB, DynamoDB) into separate referenced files and keep only a brief overview with links in SKILL.md
Remove the 'Core Concepts' section (event store architecture diagram, requirements table) — Claude already understands these fundamentals
Add an explicit end-to-end workflow with validation steps: create schema → verify tables → insert test events → read back and validate → set up subscriptions
Remove or drastically condense the technology comparison table — it's subjective and not actionable guidance
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~350+ lines. It includes extensive ASCII diagrams, requirement tables explaining basic event sourcing concepts Claude already knows, a technology comparison table that's more opinion than actionable guidance, and four full implementation templates that could be referenced externally. Much of this content doesn't earn its token cost. | 1 / 3 |
Actionability | The code templates are fully executable and copy-paste ready — complete PostgreSQL schema, Python asyncpg implementation with concurrency control, EventStoreDB client usage, and DynamoDB implementation. These are concrete, specific, and immediately usable. | 3 / 3 |
Workflow Clarity | While individual templates show clear patterns (append, read, subscribe), there's no explicit workflow for setting up an event store end-to-end. No validation checkpoints are provided — e.g., no steps to verify the schema was created correctly, test the event store works, or validate events after writing. The DynamoDB template notably lacks actual conditional writes despite mentioning concurrency. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with four complete implementation templates inline. The PostgreSQL schema, Python implementation, EventStoreDB usage, and DynamoDB implementation should each be in separate referenced files. There are no references to external files, and the content is far too long for a single SKILL.md overview. | 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
27a7ed9
- 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.