Conciseness

The body is lean and assumes Claude's competence (no concept explanations), but the three MCP call blocks repeat the same org_id/project_id boilerplate, and the opening paragraph duplicates the frontmatter description. Anchor 4 ('efficient; minor instances that could be trimmed') fits; it is well above the padded verbosity of anchor 3 but not the every-token-earns-its-place ideal of anchor 5.

Actionability

Concrete MCP tool calls with named parameters ('Call MCP tool: harness_list', resource_type, pipeline_id), explicit thresholds ('no more than 1.1x baseline', P50/P95/P99), and a defined PASS/FAIL/WARNING output contract. Falls short of anchor 5 because parameters are placeholders ('<organization>', '<pipeline_identifier>') rather than copy-paste ready, and several verification bullets (e.g., 'All referenced connectors... are accessible') describe what to check without the specific call that checks it — minor gaps, so anchor 4.

Workflow Clarity

A clear five-step sequence (scope → task identification → the three assessment workflows), explicit checklists for each check category, a structured GO/NO-GO decision output, and Troubleshooting sections providing feedback loops for error recovery ('Readiness Check Returns False Negatives' → verify connectors, check scan results). These are read-only assessments, so the destructive-batch validation cap does not apply; this matches the anchor-5 pattern of clear sequencing, checklists, and recovery loops.

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent) and the body has no broken or nested references; sections are clearly headed and easy to navigate, and the ~155-line body is a reasonable overview of three tightly related workflows. It does not hit anchor 5 (the <50-line well-organized exception or cleanly split one-level-deep references) because the three per-task check detail blocks and troubleshooting could plausibly live in separate reference files, so 'good structure; most content appropriately placed' (anchor 4) is the best fit.

Specificity

It lists three specific concrete capabilities — 'Run pre-deployment readiness checks with go/no-go recommendations, analyze environment drift between source and target environments, and provide data-driven canary rollout decisions' — comprehensively covering the skill's scope, matching anchor 5. It is clearly above anchor 4, which would require gaps in coverage of the skill's own three workflows.

Completeness

It explicitly answers both what (the three named capabilities in the first sentence) and when ('Use when asked to check if a service is ready to deploy, compare environments before deployment, or decide whether to promote a canary') plus concrete trigger phrases — the exact anchor-5 example pattern. Anchor 4 would require the 'when' to be less explicit than this direct 'Use when...' clause.

Trigger Term Quality

The explicit trigger list covers natural phrases users would say, including synonyms and variants: 'deployment readiness, ready to deploy, pre-deploy check, environment drift, canary decision, promote canary, rollback canary, go no-go, deployment checklist, production readiness, canary analysis' — comprehensive natural-term coverage matching anchor 5, not the 'a few natural terms missing' of anchor 4.

Distinctiveness Conflict Risk

A clear niche (deployment readiness via 'Harness MCP') with distinct triggers and an explicit negative boundary — 'Do NOT use for running pipelines (use run-pipeline instead) or debugging failures (use debug-pipeline instead)' — that actively disambiguates from sibling skills. Minimal conflict risk, matching anchor 5; anchor 4 would imply residual overlap with closely related skills, which the disambiguation clause forecloses.