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.
77
66%
Does it follow best practices?
Impact
94%
1.77xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/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-structured skill description with a clear 'Use when' clause and strong domain-specific trigger terms. Its main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., projection rebuilding, snapshot management, denormalization strategies). Overall it performs well for skill selection in a multi-skill environment.
Suggestions
Expand the capability list with more concrete actions, e.g., 'Build read models and projections from event streams, handle projection rebuilds, manage denormalized views, and implement catch-up subscriptions.'
| 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 concrete actions like specific techniques (e.g., creating denormalized tables, handling projection rebuilds, managing read model schemas). | 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 that users in this domain would use: 'read models', 'projections', 'event streams', 'CQRS', 'read sides', 'materialized views', 'query performance', 'event-sourced systems'. Good coverage of the terminology a developer would naturally mention. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche targeting CQRS read sides and event-sourced projections. The combination of 'read models', 'CQRS', and 'event streams' creates a very distinct trigger profile unlikely to conflict with other skills. | 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 main strength. However, it is severely bloated with repetitive template code that follows the same pattern - five full implementations where one or two with brief notes would suffice. It also lacks error handling demonstrations and validation steps despite dealing with database operations, and all content is crammed into a single file with no progressive disclosure.
Suggestions
Reduce to 1-2 inline templates (Basic Projector + one domain example) and move the remaining templates to a separate TEMPLATES.md or EXAMPLES.md file with clear references.
Remove the repetitive handler methods in OrderSummaryProjection - show one handler fully and note the pattern for others, or use a table-driven approach.
Add explicit error handling and validation to the Projector._run_projection method, showing what happens when apply() fails (retry, dead-letter, skip-and-alert).
Remove the 'Core Concepts' architecture diagram and projection types table - Claude understands these concepts; jump straight to the actionable templates.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. The 'Core Concepts' section explains projection types and architecture that Claude already understands. The five full template implementations are highly repetitive - Templates 2-5 are variations of the same pattern with nearly identical boilerplate. The Order Summary projection alone has 6 nearly identical handler methods that differ only in SQL. This could be condensed to one example with a note about the pattern. | 1 / 3 |
Actionability | The code templates are fully executable with concrete SQL, real library usage (asyncpg, elasticsearch), and complete class implementations. The examples are copy-paste ready with specific field names, SQL queries, and proper async patterns. | 3 / 3 |
Workflow Clarity | The Projector.run() method shows the basic flow (checkpoint → read → apply → save checkpoint), and rebuild() is included. However, there are no explicit validation checkpoints, no error handling in the projection pipeline, and no guidance on what to do when a projection fails mid-batch. The 'Don't skip error handling' best practice is mentioned but never demonstrated. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of code with no references to separate files. Five full template implementations are inlined when 1-2 would suffice with the rest in a separate EXAMPLES.md or TEMPLATES.md. The content would benefit greatly from splitting templates into referenced files. | 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.
6e3d68c
Table of Contents
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.