Conciseness

The body is a lean set of directives with no concept tutorials, and includes genuinely non-obvious specifics like the '{{resolve:secretsmanager:secret-id:SecretString:json-key}}' dynamic reference and the 'aws:ViaAWSMCPService' condition keys. Not 5: a few phrases explain what Claude already knows ('IaC is reviewable, repeatable, and safely destroyable') and the six-pillar enumeration could be trimmed.

Actionability

Concrete, named guidance throughout — 'retrieve_skill', 'search_documentation' / 'read_documentation', forbidden commands ('secretsmanager get-secret-value' / 'batch-get-secret-value'), a copy-pasteable CloudFormation dynamic reference, and specific standing-cost examples (NAT gateways, RDS/Aurora provisioned instances, always-on load balancers). Not 5: it stops short of executable examples for the common cases (no CDK/CLI snippet, no least-privilege policy example using the named condition keys).

Workflow Clarity

The rules are grouped thematically rather than sequenced; only 'Before beginning a task, check whether a relevant AWS skill exists' provides explicit ordering, and verification guidance ('Verify, don't guess') is a rule rather than a checkpoint in a flow. The skill governs potentially destructive infrastructure operations yet includes no post-change validation step, so workflow clarity is capped at 3. Not 4: there is no clear overall sequence with checkpoints.

Progressive Disclosure

Sections are well organized (Core rules, Security defaults, Secret safety, Cost awareness) with no nested references, and the single external pointer ('See the aws-mcp-server skill for how to drive it') is clearly signaled. Not 5: no bundle files exist to resolve the referenced sibling skills, and the body slightly exceeds the ~50-line simple-skill threshold while inlining several rule sets that could live in references.

Specificity

The description lists five explicit concrete actions — prefer the AWS MCP Server, discover and load a relevant AWS skill, verify against live AWS documentation, prefer CDK/CloudFormation over CLI mutations, and follow Well-Architected — giving comprehensive, specific coverage. Not 4: the gaps are not minor; each directive is named concretely rather than left generic.

Completeness

It explicitly answers both what ('Baseline operating rules... Directs the agent to prefer the AWS MCP Server... discover and load a relevant AWS skill... verify uncertain details... prefer infrastructure-as-code... follow Well-Architected') and when ('Use whenever the user asks to build, deploy, configure, inspect, or troubleshoot anything on AWS') with concrete trigger phrases. Not 4: the 'when' clause is explicit and specific, not merely adequate.

Trigger Term Quality

Natural trigger phrases are present ('build, deploy, configure, inspect, or troubleshoot anything on AWS'), matching what users would actually say. Not 5: it omits common service-level synonyms and terms users naturally say (e.g., EC2, S3, Lambda, 'cloud'), keeping keyword coverage good but incomplete.

Distinctiveness Conflict Risk

The AWS domain niche and baseline-rules role are clear and distinguishable from generic skills, but 'any task that touches AWS' intentionally co-triggers with every AWS task and overlaps closely related sibling skills such as the referenced 'aws-mcp-server'. Not 5: the trigger scope subsumes closely related AWS skills; not 3: it is far more anchored than 'somewhat specific' examples.