op-approachlisted

# op-approach — assess approach before tackling Big work fails when it starts in the wrong shape. An audit run as audit-and-apply produces incoherent findings. A refactor that smuggles in feature work bloats the diff and breaks both. A migration without a cutover plan leaves orphan data. A spike that quietly becomes production decays for years. All the same family — **work-shape-blindness**. This skill is the meta-step *before* planning. Identify the shape, name the phases, name the traps. Then `op-prepare` runs the planning walk informed by the shape. ## When to fire - User uses any of the trigger phrases listed in the `description:` above. - User describes work that touches **>1 surface across >1 session**, or names a multi-domain change. - Before `op-prepare` runs, for any work that isn't obviously a single-feature build. - Whenever the user signals scale — *"the project has grown"*, *"step by step over multiple sessions"*, *"a big project"*. ## When NOT to fire - One-line edits or single-file feature work — overhead exceeds payoff. - A simple "I want to build X" where X is small and clearly build-shaped — `op-prepare` directly is fine. - The work has already been shape-assessed in this conversation and the user is now executing — don't re-fire. - Mid-session, when the user is in flow on Stage 3 Build — defer until the section is done. ## What to do A short walk — six steps, kept tight. Output is a 5–6 line approach assessment, not a document. 1. **Identify work s