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.
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-crafted description for a niche domain skill. It has excellent trigger term coverage and completeness with an explicit 'Use when' clause. The main weakness is that the 'what' portion could enumerate more specific concrete actions beyond the general '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 and catch-up, manage projection state and versioning, create denormalized query-optimized 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 concrete actions like specific techniques (e.g., creating denormalized tables, handling event replays, managing projection state). | 2 / 3 |
Completeness | Clearly answers both 'what' (build read models and projections from event streams) and 'when' (explicit 'Use when' clause covering CQRS read sides, materialized views, and query optimization in event-sourced systems). | 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 relevant terminology. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche targeting CQRS read-side projections in event-sourced systems. The combination of 'read models', 'projections', 'CQRS read sides', and 'event-sourced' creates a 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 could be condensed or split into separate files. The lack of error handling and validation steps in the workflow, combined with the monolithic structure, significantly reduces its effectiveness as a skill document.
Suggestions
Consolidate Templates 2-5 into one complete example plus brief snippets showing only the unique aspects (e.g., Elasticsearch indexing, UPSERT for aggregation, multi-table transactions) rather than repeating the full class structure each time.
Split detailed templates into separate referenced files (e.g., templates/order_projection.py) and keep SKILL.md as a concise overview with navigation links.
Add explicit error handling and validation to the Projector._run_projection method, including what to do on failure (retry, dead-letter, alert) since this is a batch/streaming operation.
Remove the 'Core Concepts' architecture diagram and projection types table - Claude understands these patterns. Replace with a brief one-liner on when to choose each type.
| 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 complete example plus brief diffs. | 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 provided. 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 contradicts the absence of any error handling in the templates. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of code with no references to separate files. All five templates are inline when they could easily be split into separate files. The content would benefit enormously from a concise overview in SKILL.md with links to individual template files for each projection type. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
47823e3
- 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.