Conciseness

The body is largely efficient — it assumes CloudFormation knowledge, never explains what a VPC is, and instructions like "Do not parameterize every route or tag unless it meaningfully changes between environments" are dense and valuable. It is not a 5 because the ~150-line full inline Example 1 template duplicates territory already covered by references/examples.md (961 lines), and closing lines like "Stable outputs make application stacks easier to compose and migrate" add mild padding.

Actionability

Validation commands are copy-paste ready ("aws cloudformation validate-template --template-body file://vpc.yaml", change-set creation, describe-route-tables filters), and the Example 1 template is complete and deployable. Not a 4 because the concrete commands and full YAML cover the common cases end-to-end; the only placeholder (<vpc-id>) is appropriately parameterized.

Workflow Clarity

The five-step sequence (address plan → layered build → parameterize → export → validate) is clearly ordered, and "Validate before deployment" supplies an explicit checkpoint with change-set review ("Review change set before applying") acting as the review-before-apply loop plus post-hoc verification commands for routing and IGW attachment. Not a 4 because validation checkpoints are explicit and comprehensive rather than mostly present with gaps.

Progressive Disclosure

References are real, one level deep, and clearly listed in a dedicated ## References section (references/examples.md, references/reference.md), with an Overview pointer ("Use the `references/` files for larger templates and extended service combinations"). Not a 5 because the navigation is a flat list rather than per-topic pointers (e.g., which file holds full templates vs. resource property tables), and the large inline Example 1 template is borderline content that the skill's own best practice ("Keep the root skill focused and move larger networking variants to references/examples.md") suggests belongs in the bundle.

Specificity

"Provides AWS CloudFormation patterns for VPC foundations, including subnets, route tables, internet and NAT gateways, endpoints, and reusable outputs" names the domain and enumerates multiple specific concrete components with comprehensive coverage of the VFC foundation surface (subnets, routing, gateways, endpoints, outputs). Not a 4 because coverage is not merely 'several specific actions with minor gaps' — the enumerated components span the full scope of a VPC baseline skill.

Completeness

Both 'what' and 'when' are explicitly stated: the what is "Provides AWS CloudFormation patterns for VPC foundations, including..." and the when is "Use when creating a new network baseline, segmenting public and private workloads, or preparing CloudFormation networking stacks for application deployments." This matches the anchor-5 pattern of a concrete capability statement followed by an explicit 'Use when...' trigger clause with concrete trigger phrases.

Trigger Term Quality

Natural user terms are comprehensively covered: "VPC", "CloudFormation", "network baseline", "subnets", "N gateways", "endpoints", "networking stacks", "public and private workloads" — exactly what a user asking for network infrastructure would say. Not a 4 because the vocabulary spans both technical terms and the natural phrasings ("segmenting public and private workloads", "preparing... stacks") users would use when requesting this work.

Distinctiveness Conflict Risk

The niche is precise — CloudFormation-specific VPC networking, not general AWS work, not Terraform, not application stacks — and triggers are anchored to distinct phrases like "VPC foundations", "network baseline", and "CloudFormation networking stacks". Not a 4 because the overlap risk is limited to closely adjacent AWS networking skills and the description's tool-locked vocabulary makes accidental triggering unlikely.