Conciseness

The body is a lean reference: every section is copy-paste code, parameter tables with defaults Claude cannot know, or targeted one-line facts ('Exit codes: 16 = resume to disambiguate, 17 = failed validation'). It never explains concepts Claude already knows (no 'what is fault tolerance' or NCCL tutorials). Not score 4: there are no over-explanatory passages left to trim — the only prose ('Section-based timeout monitoring covers...') conveys non-obvious behavior.

Actionability

Fully executable throughout: complete Python config snippets for every feature, the exact ft_launcher command with all flags, required env vars ('export TORCH_NCCL_RETHROW_CUDA_ERRORS=0'), and runnable verification commands with expected log lines ('Look for [FaultTolerance] / [RankMonitorServer] log lines'). Not score 4: no key details are missing; even failure semantics and exit codes are given.

Workflow Clarity

The structure (Enablement → Code Anchors → Pitfalls → Verification) gives each feature a clear enable path plus an explicit validation section with concrete commands and expected outputs — most checkpoints are present. Not score 5: the document is a per-feature reference rather than a sequenced workflow, and there are no explicit feedback loops (e.g., 'if the log line is missing, check X'); pitfalls partially but not systematically cover error recovery. Not score 3: validation steps are explicit and per-feature, not merely implicit.

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), so this is scored on structure alone: sections are well-organized with clear headers, and external pointers (@docs/training/resiliency.md, per-feature Code Anchors into repo paths) are one level deep and clearly signaled. Not score 5: the body is self-contained rather than an overview deferring detail to reference files — full parameter tables for six sub-features (~300 lines) are inlined, some of which (e.g., the 14-row InProcessRestartConfig table) could live in reference files; not score 3: organization is good and all pointers are clear.

Specificity

The description names the domain ('Resiliency features in Megatron Bridge') and enumerates all five concrete capability areas the skill covers: 'fault tolerance, straggler detection, in-process restart, preemption, and re-run state machine' — matching the body's full coverage. Not score 4: there are no minor gaps; the enumerated list is comprehensive relative to the skill's scope.

Completeness

It has a clear 'what' (five named resiliency features), but no 'Use when...' clause or equivalent trigger guidance inside the description itself — the when-guidance lives only in a separate when_to_use field. Per the rubric guideline, a missing explicit trigger clause caps completeness at 3. Not score 4: the 'when' is not merely implicit in this text, it is entirely absent from the description field.

Trigger Term Quality

Includes strong natural domain terms users would say ('fault tolerance', 'straggler detection', 'preemption', 'in-process restart'), but misses common synonyms and phrasings users actually use when troubleshooting, such as 'training hangs', 'hang detection', 'crash recovery', or 'automatic restart' — several of which appear only in the separate when_to_use field, not the description. Not score 5: anchor 5 requires comprehensive coverage including synonyms/extensions, which is absent; not score 3: the terms present go well beyond 'some relevant keywords'.

Distinctiveness Conflict Risk

'Resiliency features in Megatron Bridge' establishes a clear niche with distinct, framework-specific trigger terms (Megatron Bridge, in-process restart, re-run state machine) that are unlikely to fire for unrelated skills. Not score 4: the trigger surface is both specific and non-overlapping with generic training or checkpointing skills.