Conciseness

The body is dense, skill-specific orchestration with no explanations of concepts Claude already knows, and it assumes competence throughout (e.g., "$AZURE_SUBSCRIPTION = The subscription id passed explicitly on every `az` command. Never rely on the CLI's ambient active-subscription context."). However, a few rules are restated across sections — the Generate/run_mode consent rule appears in Philosophy, Execution, and State Management, and the x86_64-vs-Graviton default appears in Philosophy, Sidebar Placement, and Defaults — which is more than minor trimming would remove. Not 3: the overwhelming majority of the 245 lines is unique, load-bearing orchestration rather than unnecessary explanation; not 5: the cross-section repetition and some defensive justifying prose could be tightened.

Actionability

For an instruction-only orchestration skill, the guidance is fully executable: exact state transitions with conditions ("If `current_phase == "estimate"` AND `phases.estimate == "completed"` AND `phases.workshop` is `"pending"` or `"in_progress"`, **do not recompute Estimate**"), an exact copy-paste sidebar prompt with labeled options and per-option state outcomes, precise file paths to load per decision point, and exact state-key semantics ("`run_mode`" | "decide_and_execute""). Not 4: there are no gaps — every rule is stated with the specific files, keys, and conditions needed to execute it.

Workflow Clarity

The multi-phase workflow is clearly sequenced with explicit validation checkpoints: the interpreter loop is summarized ("reads `.phase-status.json`, determines the current phase, runs each phase's `_preconditions` / fragments / `_assemble` / `_postconditions`, advances on `HANDOFF_OK` via `_advances_to`, and validates state"), cold-start and warm-start entry rules are precise, interrupted-state recovery is handled (the mandatory workshop-resume rule), and a halt-on-error checkpoint is stated ("If unable to complete a step, stop and report the specific issue. Do not fabricate or infer data."). Not 4: validation is explicit at every gate (Clarify mandatory, `run_mode` NOT consent, workshop must complete before Generate), not merely implicit or partial.

Progressive Disclosure

The body is a well-structured overview that routes to a real, well-organized bundle: "begin at `references/phases/discover/discover.md`, this skill's entry phase", "the vendored `references/vendored/dsl/INTERPRETER.md`: ... **Load it first**", and per-dialect files "it loads only for the dialects actually present" — and every referenced path I checked (discover-live.md, shared/graviton.md, shared/extract-terraform.md, vendored/pricing/aws-infra-pricing.json, design-refs/ai.md, vendored/ai/*) exists. Not 5: reference chains run 2+ levels deep (SKILL.md → phase orchestrator → fragments → shared refs), which the top anchor flags, even though navigation signals and the ~800-line budget rules keep it navigable.

Specificity

"Migrate workloads from Microsoft Azure to AWS" plus "Runs a 6-phase process: discover Azure resources from Terraform, the live `az` CLI, app code, and billing exports, then clarify, design, estimate costs, optionally reprice scenarios, generate artifacts, and collect feedback" enumerates multiple concrete actions with comprehensive coverage, including sources, gating semantics ("Generate is opt-in at the post-Estimate decision gate"), and a stated limitation ("Bicep/ARM discovery is not yet implemented"). Not 4: coverage of what the skill does and how it runs is complete, with no gaps; every clause is concrete.

Completeness

Both "what" (the enumerated 6-phase process) and "when" (the explicit "Triggers on:" list, the equivalent of a "Use when..." clause) are clearly and concretely stated, and negative scope ("Do not use for: GCP migrations ... Heroku migrations ... AWS-to-Azure reverse migration, or Azure-to-Azure refactoring") is also explicit. Not 4: the "when" is not merely present but given as concrete trigger phrases, matching the top anchor.

Trigger Term Quality

"Triggers on: migrate from Azure, Azure to AWS, move off Azure, migrate AKS to EKS, migrate App Service or Azure VMs to AWS compute, migrate Azure SQL or Azure Database to RDS, migrate Cosmos DB to DynamoDB, migrate Azure OpenAI to Bedrock, move Azure AI or agentic workloads to AWS, estimate AWS costs for my Azure infrastructure, what-if workshop" comprehensively covers natural user phrasings including synonyms ("move off Azure") and service-pair specifics (AKS→EKS, Cosmos DB→DynamoDB). Not 4: no common variation of the ask is missing, including cost-estimation and what-if framings.

Distinctiveness Conflict Risk

A clear niche (Azure-to-AWS migration) with distinct service-level triggers and explicit disambiguation against sibling skills ("see gcp-to-aws", "see heroku-to-aws", "see architect-for-startups") plus reverse/refactor exclusions. Not 4: conflict risk is not just minor but actively minimized by the named anti-triggers.