Conciseness

Lean and efficient: every line carries operational content (size floor, phase mask, gate names, sibling disambiguation) with zero explanation of concepts Claude already knows. Even the one explanatory line — "Changing the tests first is what separates a tweak from a fix" — earns its place as a decision rule.

Actionability

Concrete, specific guidance throughout: a literal phase mask ("0 → (1 only if the new behavior needs research) → light 2 → 4 → 5 → 6"), explicit gates, and a worked example. Minor gap: it delegates execution to the `orch-pipeline` engine, so this file alone is not fully self-executable.

Workflow Clarity

Clear sequence via the numbered "How It Works" list plus the phase-mask ordering, with explicit checkpoints ("Gate 1 (plan / changed-test approval)" and "Gate 2 (pre-commit)") and an implicit feedback loop ("change the implementation until they pass"). Not 5: error-recovery behavior at a failed gate is not described.

Progressive Disclosure

Under 50 lines with no bundle files needed; the content is well organized into clear sections (When to Use, Operation settings, How It Works, Example) and its single outward reference to the shared engine ([`orch-pipeline`](../orch-pipeline/SKILL.md)) is clearly signaled and one level deep.

Specificity

The description lists multiple concrete actions — "update its tests to the new spec, change the implementation to match, review, and gated commit" — covering the full pipeline comprehensively with no vague padding.

Completeness

Explicitly answers both: what ("update its tests to the new spec, change the implementation to match, review, and gated commit") and when ("Use when behavior is not broken but should be different") with a concrete trigger clause.

Trigger Term Quality

Good natural-phrase coverage: "altering an existing, working feature", "behavior is not broken but should be different", "change". A few common synonyms users would say ("modify", "tweak", "make it also do X", "instead of X do Y") are only in the body, not the description.

Distinctiveness Conflict Risk

The qualifiers "existing, working feature" and "behavior is not broken but should be different" carve a clear niche that distinguishes it from fix-defect and add-feature siblings; minimal overlap risk.