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 specialized skill. It excels at completeness with a clear 'Use when' clause and includes excellent domain-specific trigger terms. The main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., event replay, snapshot management, denormalization strategies).
Suggestions
Expand the capability list with more concrete actions, e.g., 'Build read models and projections from event streams, handle event replay, manage projection snapshots, and create denormalized query stores.'
| 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 other skills due to the highly specialized domain terminology and clear scope boundaries. | 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 — five full templates with repetitive patterns (especially the order summary's six near-identical handlers) make it extremely token-inefficient. The content would benefit enormously from splitting templates into separate files, condensing the main skill to a concise overview with one representative example, and adding explicit error handling/validation workflows.
Suggestions
Extract templates 2-5 into separate files (e.g., templates/order_summary.py) and reference them from SKILL.md, keeping only Template 1 (Basic Projector) inline as the representative example.
Condense the order summary projection to show 2 handlers max (e.g., created + item_added) with a comment like '# Similar handlers for shipped, completed, cancelled' to eliminate repetitive SQL.
Add explicit error handling and validation workflow: what to do when a projection fails, how to verify projection correctness after rebuild, and how to handle poison events.
Remove the 'Core Concepts' architecture diagram and projection types table — Claude understands these patterns; replace with a one-line summary linking to a reference file if needed.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. The 'Core Concepts' section explains projection types and architecture that Claude already understands. The five full templates are highly repetitive (each follows the same pattern with minor variations), and the order summary projection alone has six nearly identical handler methods. The best practices section states obvious things like 'use transactions' and 'store checkpoints' which are already demonstrated in the code. | 1 / 3 |
Actionability | The code templates are concrete, executable Python with real SQL queries, proper async patterns, and specific library usage (asyncpg, elasticsearch). Each template is copy-paste ready with complete class implementations that could be adapted to real projects. | 3 / 3 |
Workflow Clarity | The projector's run/rebuild methods show a basic workflow, but there's no explicit validation or error handling in the projection pipeline. For batch operations processing event streams, missing error recovery steps (what happens when a projection fails mid-batch?) and no verification that projections are correct after rebuild caps this at 2. | 2 / 3 |
Progressive Disclosure | Everything is in a single monolithic file with no references to external files. The five full template implementations should be split into separate files, with SKILL.md providing a concise overview and linking to detailed templates. The content is a wall of code that could easily be 5x shorter with proper file organization. | 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.