Conciseness

The body assumes Claude's competence throughout — it never explains what an MCP server, checkpoint, or sandbox is — and uses dense prescriptive tables instead of prose. However, the production-boundary rule is stated three times ("Do not use this skill against a production target, real user data, live credentials" / "Never delete real data, revoke real credentials" / "Do not include destructive commands, exploit payloads, credential material") and the inconclusive-on-missing-evidence rule appears four times, so minor trimming is possible.

Actionability

Concrete, actionable artifacts abound: an exact evidence-record field list ("run_id", monotonic "seq", "retry_remaining", "deadline_remaining_ms"), a complete JSON schedule example, a 7-row fault matrix naming injection boundaries and required observations, named join policies ("all_required", "best_effort", "compensate"), and defined verdicts. Minor gaps keep it below 5: no executable harness/wrapper snippet is provided and "compare the normalized timeline" leaves the normalization undefined.

Workflow Clarity

Validation is explicit and repeated ("Assert invariants after every recovery transition, not only at final output", "Run the same schedule twice and compare the normalized timeline", "Gate the verdict on invariants and remaining budget, not output text alone"), the safety preconditions form a numbered checklist, and Common Pitfalls supply problem/solution feedback loops. The end-to-end sequence is never enumerated as one ordered procedure — it must be assembled from the topic-ordered sections and the example run — which is the minor gap separating it from anchor 5.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories) and the single SKILL.md is well-sectioned with scannable headers and tables; the content is cohesive methodology rather than bulk reference material that clearly belongs in a separate file. It sits at anchor 4 rather than 5 because there are no one-level-deep references at all, and sections like the evidence field specification could arguably be split out to slim the overview.

Specificity

The description names the domain and a concrete deliverable ("deterministic recovery evidence" for "sandbox, MCP/tool, worker, checkpoint, memory, or orchestration failures") but never states the actions the skill performs — fault injection, building a fault matrix, or emitting a verdict are all absent. It matches anchor 3 (domain plus an implied action, not comprehensive) rather than 4, which requires several explicit action verbs.

Completeness

The 'when' is explicit and specific ("Use when an agent workflow needs deterministic recovery evidence for..."), but the 'what' exists only implicitly inside the when-clause — no statement of what the skill does. Scoring only what is stated, this is richer than anchor 2's bare trigger ("Use when working with documents") but lacks the explicit 'what' that anchors 4-5 require, so it sits at 3.

Trigger Term Quality

Good natural keyword coverage for the domain: "agent workflow", "recovery", "sandbox", "MCP/tool", "worker", "checkpoint", "memory", "orchestration failures" are all phrases a harness developer would use. A few natural terms are missing — notably "fault injection" (the skill's own name), "retry", "timeout", and "resilience/chaos testing" — which fits anchor 4's 'good coverage, a few natural terms missing'.

Distinctiveness Conflict Risk

The recovery-evidence-testing framing ("deterministic recovery evidence", enumerated failure classes) carves a distinct niche unlikely to steal triggers from unrelated skills. Minor overlap risk remains: broad terms like "sandbox", "memory", and "orchestration" could also pull in sandbox-setup, memory-management, or multi-agent-orchestration skills when failure testing is not intended, matching anchor 4 rather than 5.