Conciseness

The body is dense with non-obvious specifics ('ISSUE#9 sorts after ISSUE#100 lexicographically; zero-pad', 'DynamoDB TTL has a 48h deletion window', 'Filter expressions do NOT reduce read costs') and assumes Claude's knowledge of DynamoDB basics. It falls short of the leanest anchor because the 'design access patterns first' principle is restated three times (opening section, Quick Reference, Anti-Patterns) and the Version Matrix carries time-sensitive date/version info ('Nov 2025', 'v6.29.0+') outside any deprecated section.

Actionability

Guidance is largely executable and concrete: exact key formats ('ISSUE#00000009', 'ISSUE#CLOSED#<id>'), a specific read guard ('FilterExpression: TTL > current_epoch'), parallel-scan parameters ('TotalSegments + Segment'), a named pricing tool ('awslabs.aws-pricing-mcp-server'), and unambiguous behavioral steps. Minor gaps remain — e.g., 'read-shard caches across N copies' and 'numeric difference enables reverse integer ordering' are too compressed to act on without loading the reference file.

Workflow Clarity

The core design workflow is clearly sequenced with an explicit gate ('Design only after the user confirms a list') and covers pushback and the build-versus-design exception. However, the migration guidance recommends batch rewrites ('Scan + UpdateItem to add GSI attributes to all existing parent items', parallel scans) with no validation or verification steps for the ETL, and the rubric caps workflow clarity at 3 for batch/database operations missing feedback loops.

Progressive Disclosure

The body is a genuine overview — quick-reference table, anti-patterns, decision frameworks — that delegates detail to one real, one-level-deep reference (references/dynamodb-patterns.md, 583 lines) whose headings match the body's anchor links. The reference is signaled three times, including a closing 'Reference Loading Strategy' section stating exactly when to load it and what it covers, matching the clear-overview anchor.

Specificity

The description states the concrete capability ('designing or reviewing a DynamoDB table') and enumerates comprehensive, specific facets: 'access patterns, partition and sort keys, single-table design, GSIs and sparse indexes, hot partitions, one-to-many and many-to-many modeling, capacity mode and cost, or the Terraform for the table'. This covers the full DynamoDB design domain with no vague language, matching the comprehensive-coverage anchor rather than the minor-gaps anchor below it.

Completeness

Both what and when are explicit: the capability ('designing or reviewing a DynamoDB table') is stated directly, and the 'Use when ...' clause lists concrete trigger topics (access patterns, GSIs, hot partitions, Terraform for the table). This matches the anchor for clearly and explicitly answering both what AND when with concrete triggers.

Trigger Term Quality

Good natural keyword coverage — 'DynamoDB table', 'partition and sort keys', 'single-table design', 'GSIs', 'hot partitions', 'Terraform' are phrases users would actually say. A few natural terms are missing, such as the legacy synonyms 'hash key'/'range key', 'NoSQL', and the spelled-out 'global secondary index', so it falls short of the comprehensive-synonyms anchor.

Distinctiveness Conflict Risk

'DynamoDB' is a clear niche with distinct triggers and minimal conflict risk; even the broadest phrase, 'or the Terraform for the table', stays scoped to the DynamoDB table, so overlap with a generic Terraform or AWS-cost skill is negligible.