projection-patterns
Build read models and projections from event streams. Use when implementing CQRS read sides, building materialized views, or optimizing query performance in event-sourced systems.
85
66%
Does it follow best practices?
Impact
97%
1.59xAverage score across 6 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/backend-development/skills/projection-patterns/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 well-crafted description for a niche domain skill. It excels at completeness with a clear 'Use when' clause and includes strong trigger terms that developers in the CQRS/event-sourcing space would naturally use. The main weakness is that the 'what' portion could be more specific about the concrete actions performed beyond the high-level 'build read models and projections.'
Suggestions
Expand the capability list with more specific actions, e.g., 'Build read models and projections from event streams, handle event replay, manage projection state, create denormalized query views.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (CQRS/event sourcing) and some actions ('build read models and projections from event streams'), but doesn't list multiple specific concrete actions like creating denormalized views, handling event replay, managing projection state, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (build read models and projections from event streams) and 'when' (implementing CQRS read sides, building materialized views, optimizing query performance in event-sourced systems) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'read models', 'projections', 'event streams', 'CQRS', 'read sides', 'materialized views', 'query performance', 'event-sourced systems'. Good coverage of terms a developer working in this domain would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche targeting CQRS read-side projections in event-sourced systems. Unlikely to conflict with general database, API, or even event-sourcing write-side skills due to the precise domain focus on read models and projections. | 3 / 3 |
Total | 11 / 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 Python code for building event-sourced projections, which is its primary strength. However, it is severely over-verbose with five repetitive templates that follow the same pattern, wasting significant token budget. The content would benefit greatly from condensing to one or two templates with brief notes on variations, and splitting detailed examples into referenced files.
Suggestions
Consolidate Templates 2-5 into a single representative example (e.g., OrderSummaryProjection) and add brief bullet points describing how to adapt it for search indexes, aggregations, and multi-table scenarios.
Move detailed template implementations to a separate EXAMPLES.md or TEMPLATES.md file, keeping only the base Projector class and one concrete projection in the main skill.
Remove the 'Core Concepts' section (projection types table, ASCII diagram) — Claude understands these architectural patterns and the templates themselves demonstrate the concepts.
Add explicit error handling and validation steps to the Projector.run() method, such as dead-letter handling for failed events and a verification step after rebuilds.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with 5 full template implementations that are largely repetitive (Templates 2-5 are variations of the same pattern with different SQL). The 'Core Concepts' section explains projection types and architecture that Claude already understands. The ASCII diagram and type table add little value. This could be reduced to one template with brief notes on variations. | 1 / 3 |
Actionability | The code templates are fully executable with concrete SQL queries, proper async/await patterns, and real library usage (asyncpg, elasticsearch). The examples are copy-paste ready with specific field names, SQL statements, and complete class implementations. | 3 / 3 |
Workflow Clarity | The Projector class includes a rebuild method and checkpoint-based resumption, but there's no explicit validation workflow for building/testing projections. Missing error handling in the projection apply methods, no guidance on verifying projection correctness after rebuild, and no feedback loops for detecting data inconsistencies. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of code with 5 full templates inline. Templates 2-5 should be in separate files or condensed significantly. There are no references to external files, and the content is ~350+ lines that could be structured as a brief overview with links to detailed examples. | 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
70444e5
- 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.