Conciseness

The body is procedural and skill-specific throughout — no explaining of concepts Claude already knows — with near-zero fluff per section. However, the verify-before-persist rule is restated ~6 times (intro, "What this skill is for", the loop, "Verify is the load-bearing wall", Anti-patterns #1, Best practices #2) and "Best practices" substantially overlaps "Anti-patterns", so there is more than a single token of trimmable repetition — between anchors 3 and 4, closer to 4 since the repetition is deliberate emphasis rather than padding.

Actionability

Fully executable guidance: a copy-paste-ready HEAL entry markdown template, exact commands (`grep -n "Pattern-Key: <your-pattern-key>" .learnings/HEALS.md`, `mkdir -p .learnings` / `touch .learnings/HEALS.md`), concrete per-shape examples for all five trigger types, an exact ID format with examples, and a verification table mapping each failure shape to its proof. The common cases are covered end-to-end.

Workflow Clarity

The Heal Loop (diagnose → patch → verify → file) is presented as a sequenced diagram with an explicit verification gate, bounded retries ("cap at 3 attempts"), failure classification (deterministic/transient/shared-service) required before any retry, a 1/2/3 escalation protocol when verification fails, and honest terminal states (pending-verify, abandoned). This is the top anchor: clear sequence, explicit validation steps, and genuine feedback loops.

Progressive Disclosure

The body is a well-signaled overview with one-level-deep references (`references/hooks.md`, `examples.md`, `pipeline-integration.md`, `interop-with-self-improvement.md` — all real files), each introduced with what it contains. Two gaps hold it below the top anchor: the three bundled scripts (`scripts/detect-failure.sh`, `find-similar-heals.sh`, `new-heal.sh`) are functional utilities never referenced from the body, and the "See also" section repeats links already made inline.

Specificity

The description lists multiple concrete, specific actions covering the full capability: "diagnose the root cause, write a fix, VERIFY by re-running the broken thing, then file a `HEAL-` entry to `.learnings/HEALS.md` with proof", plus "Search `HEALS.md` by `Pattern-Key` first" and "increment `Recurrence-Count` instead of duplicating". This matches the anchor for comprehensive coverage of concrete actions; no action is left as abstract language.

Completeness

Both halves are explicit: the opening sentence answers "what" (diagnose → fix → verify → file, with proof) and the "Use whenever..." clause answers "when" with concrete trigger phrases. This is the top anchor exactly; the when-clause is far beyond weakly implied.

Trigger Term Quality

The "Use whenever" clause is exhaustive and natural: "a command, test, build, or lint fails or exits non-zero", "missing tooling, dependency/lockfile mismatch, wrong runtime version, venv or permission errors, port conflicts, dirty git state, or a missing `.env`", "external API, tool, or MCP errors or rate-limits", "when a test flakes". It covers synonyms, concrete file names, and phrasings an agent/user would actually produce; nothing common is missing.

Distinctiveness Conflict Risk

It carves a clear niche (active runtime recovery with mandatory verification) and explicitly disambiguates the nearest neighbor: "Pairs with `self-improvement` (which promotes recurring heals to durable memory) but owns the verify-before-persist discipline self-improvement doesn't". Triggers are failure-specific, so wrong-skill triggering risk is minimal.