Conciseness

A lean ~36-line thin wrapper: no concept explanations Claude already knows, no padding — every section (settings, first move, gates, example) earns its tokens. It assumes competence throughout ("No new behavior tests are written — the existing suite is the safety net"), matching anchor 5 exactly.

Actionability

Concrete, specific guidance: exact phase mask ("0 → 2 → 4 → 5 → 6"), named gates, a named agent with its tools ("refactor-cleaner ... knip / depcheck / ts-prune"), and a commit-message convention (`refactor:`). The gap keeping it below anchor 5 is that the core execution ("Run the orch-pipeline engine") is delegated to a sibling skill that is not part of this bundle, so the skill alone is not copy-paste executable — above anchor 3's pseudocode level.

Workflow Clarity

Clear sequence with explicit checkpoints: confirm tests green BEFORE touching code, plan [GATE 1], restructure in small steps re-running tests after each, code-review, commit [GATE 2]. Falls short of anchor 5 only in lacking an error-recovery feedback loop (no 'if tests go red, do X' path); it is clearly above anchor 3, which has only implicit checkpoints.

Progressive Disclosure

Well-organized short body (under 50 lines) with clear sections and a clearly signaled one-level-deep reference to the engine ([`orch-pipeline`](../orch-pipeline/SKILL.md)) plus an inline example. Below anchor 5 because the referenced sibling engine file is absent from the evaluated bundle, so navigation to the load-bearing detail cannot be verified; above anchor 3, whose references are vague or whose content is misfiled.

Specificity

Lists several concrete actions — "confirm tests are green", "restructure without changing behavior", "keep tests green", "review, and gated commit" — but coverage has minor gaps: some phrasing is family-internal jargon ("gated commit") rather than plainly concrete actions. It sits clearly above anchor 3 (only 1-2 actions) but does not reach the comprehensive, self-contained coverage of anchor 5.

Completeness

Explicitly answers both: the what ("Orchestrate a behavior-preserving refactor — confirm tests are green, restructure without changing behavior, keep tests green, review, and gated commit") and the when ("Use when the structure should improve but behavior must not change") with a concrete trigger clause. Matches anchor 5; the 'when' is fully explicit, not merely implied as at anchor 4.

Trigger Term Quality

Strong natural terms users would say: "refactor", "behavior-preserving", "structure should improve", "tests are green". Missing common synonyms and variations such as "clean up code", "tidy", "remove duplication", or "dead code", so it falls just short of anchor 5's comprehensive synonym coverage while being noticeably above anchor 3.

Distinctiveness Conflict Risk

The behavior-preservation scope carves a clear niche ("structure should improve but behavior must not change") and even distinguishes siblings (orch-change-feature / orch-fix-defect in the body), so it is mostly distinct. Minor overlap risk remains with generic refactoring/review requests, keeping it below anchor 5's minimal-conflict niche.