cupertino-cannibalizelisted

This technique only runs when the user explicitly asks for it by name or clear equivalent. A PreToolUse hook denies dispatching this skill while a `cupertino-review` pipeline is active in this repo (`.cupertino/flags/review-pipeline-active`) — if you see that denial, finish or exit the review pipeline first, then invoke this skill separately and explicitly. Do not try to route around the hook; if `cupertino-review` surfaces a cannibalization question organically, it will flag it and suggest exactly this: come back and invoke this skill on its own. ## Steps 1. **Name the current most-successful, load-bearing thing** under consideration — precisely, so it's clear what would actually be replaced and what depends on it today. 2. **Apply the exact distinguishing test**: *could this keep improving incrementally?* - If **no** — it is a **Vista Trap**: the current thing is failing not because someone chose to replace it, but because its architecture has run out of runway. This is bad, and the fix is `cupertino-longevity`'s Rosetta Roadmap, not cannibalization. Say so and redirect rather than dressing up a forced rewrite as a bold strategic move. - If **yes** — it is a genuine **cannibalization candidate**: the current thing is fine and could keep improving, but a deliberately-built successor could be meaningfully better. This is the iPhone-vs-iPod case: healthy, chosen, not forced. 3. **For a genuine candidate only**: assess the competitive threat or opportunity driving this