Conciseness

The body is lean and test-specific ('assert new_events == [OrderConfirmed(order_id="o1")]', the anti-patterns table, 'Test each projection off one stream independently'), but has minor over-explanation of concepts Claude already knows, e.g. quoting Fowler's definition 'rebuild application state from scratch by replaying events in order' and the 3-line rationale intro. These could be trimmed without losing guidance.

Actionability

The worked example is a complete, concrete test function ('history = [OrderCreated(...)] ... assert state_a == state_b') and the projection section names specific assertions with a parameterized example ('ProductPriceChanged → {"sku1.price": 120}'). Minor gaps remain: snapshot equivalence, upcasting, and swap mechanics are named but their code is deferred entirely to the references rather than shown or sketched inline.

Workflow Clarity

'How to use' gives a clear 6-step sequence with an explicit gate ('Once this base test is green, layer on the operational checks') and the anti-patterns table maps failures to fixes. Minor validation gaps: steps 3-6 have no per-step run/verify checkpoint and no explicit test-run command is given.

Progressive Disclosure

The body is a ~145-line overview that splits deep material into three real, one-level-deep bundle files, each clearly signaled with its scope in place ('see [references/snapshot-versioning-projections.md]', 'the deadline + poll + assert pattern in [references/convergence-windows.md]') and summarized again in the References section. Verified all three referenced files exist with no nested references inside them.

Specificity

The description lists multiple specific concrete test types with comprehensive coverage of the domain: 'the given-events / when-command / then-events aggregate test, replay determinism (same events produce the same state), event-versioning + upcasting, snapshot equivalence (replay-to-N vs snapshot-at-N must agree), retroactive event correction' plus four projection-test variants. Nothing in the domain is left unnamed, matching the level-5 anchor rather than the 'minor gaps' of level 4.

Completeness

It explicitly answers both questions with concrete trigger phrases: what — 'Build event-sourcing + CQRS tests' with the enumerated test types; when — 'Use when an event-sourced aggregate gains a new event type or a changed payload schema, when snapshots are introduced to shorten replay, when a read model is projected from the event stream, or when a documented convergence window needs a test.' This matches the level-5 anchor exactly; the 'when' is neither missing (3) nor merely present-but-generic (4).

Trigger Term Quality

Comprehensive natural-term coverage with synonyms for this domain: 'event-sourcing', 'CQRS', 'aggregate', 'replay', 'upcasting', 'snapshot', 'read model', 'projection', 'event stream', 'payload schema', 'convergence window'. These are exactly the phrases a developer of an event-sourced system would say; nothing common is missing, so it exceeds the 'a few natural terms missing' level-4 anchor.

Distinctiveness Conflict Risk

Clear niche with distinct triggers: event-sourcing + CQRS test construction. The triggers are specific to event-sourced systems (new event type, changed payload schema, snapshots shortening replay, convergence window), so overlap risk with generic testing or saga-transaction skills is minimal — it fits the 'clear niche with distinct triggers' level-5 anchor, not the 'minor overlap with closely related skills' level-4 one.