Conciseness

The bulk is dense, executable code (good), but there are several padded sections Claude does not need: 'What is cdk8s?' and 'Key Benefits' marketing bullets ('Type Safety: Catch configuration errors at development time', 'IDE Support: Autocomplete'), a 'When to Use cdk8s' list that duplicates the later 'When to Use cdk8s vs Alternatives' section, and inline time-sensitive version data (cdk8s==2.70.26, cdk8s-plus-27/28/29 compatibility table) not placed in a deprecated/version section. Not 2 because the majority of the body is lean runnable code rather than prose padding; not 4 because the duplication and benefit-fluff sections are more than minor.

Actionability

Mostly executable guidance: complete install commands, a runnable first application, three full workflows, pytest tests, CI/CD YAML, EKS bridge code, and a command cheat-sheet. Not 5 because of small gaps — the L3 construct example is a stub ('# Compose deployment + service + ingress'), and the 'Use Explicit Names' best practice mixes an ambiguous `Deployment` with `k8s.ObjectMeta` without a clear import, making it non-copy-paste ready.

Workflow Clarity

The Quick Start gives a clear ordered sequence (install → init → write → synth → review → apply), and 'Test Before Deploying' provides explicit checkpoints (kubectl apply --dry-run=client, pytest tests/, git diff dist/) plus a Testing section with synth-and-assert loops. Not 5 because there is no explicit error-recovery feedback loop (e.g., 'if dry-run fails, fix and re-validate') tying validation into the deploy sequence.

Progressive Disclosure

References exist, are real, one level deep (verified: references/*.md only cross-link laterally), and are clearly signaled in a 'Detailed Guides' section with descriptions. However, the ~630-line body inlines substantial content that belongs in those files and largely duplicates them — installation/quick-start (getting-started.md), L1/L2/L3 construct explanations (constructs.md), and multi-environment/microservice patterns (patterns.md). Not 4 because content that should be separate is inline at well-beyond-overview scale; not 2 because structure and signaling are genuinely good.

Specificity

The 'what' clause ('CDK8s for type-safe Kubernetes manifests using Python') names the domain, and the 'Use when' clause lists several concrete actions — 'building complex K8s applications programmatically, generating manifests from code, creating reusable infrastructure patterns, or managing multi-environment deployments'. Not 5 because the what-clause is a noun phrase relying on the tool name rather than explicit action verbs (e.g., 'define K8s apps in Python, synthesize to YAML'); not 3 because multiple specific actions are stated, exceeding 1-2.

Completeness

Both questions are explicitly answered: what ('CDK8s for type-safe Kubernetes manifests using Python') and when ('Use when building complex K8s applications programmatically, generating manifests from code, creating reusable infrastructure patterns, or managing multi-environment deployments') with four concrete trigger phrases. Fits the anchor 5 example pattern; the score-4 caveat ('when' could be more explicit) does not apply since the when-clause is fully explicit.

Trigger Term Quality

Good natural keyword coverage: 'Kubernetes manifests', 'K8s applications', 'manifests from code', 'multi-environment deployments', 'infrastructure patterns'. Not 5 because common variations users would say are missing — notably 'YAML', 'Helm'/'Kustomize' comparison terms, and file/CLI hints like 'cdk8s synth'; not 3 because coverage goes well beyond a single generic keyword with several natural phrases.

Distinctiveness Conflict Risk

The named tool 'CDK8s' and triggers like 'generating manifests from code' establish a clear niche distinct from generic coding skills. Not 5 because broad terms like 'Kubernetes manifests' and 'multi-environment deployments' could overlap with closely related K8s skills (Helm, Kustomize, raw YAML, general kubectl help) for a user who just says 'help me write Kubernetes manifests'.