classify-changelisted

# classify-change The single most important rule for AI-assisted coding in production: confine the AI's mass output to leaf nodes, where the inevitable bit of tech debt won't propagate through the system. This skill makes the leaf-vs-core call concrete and consistent, so individual judgment doesn't drift across the team. ## When to use Use whenever the leaf-vs-core distinction matters. Triggers include: - "Is this leaf or core?" - "What classification is this change?" - "Should I vibe code this / can AI write this?" - "How carefully do I need to review this?" - Before starting non-trivial work, even when the user didn't ask - Before or during `plan-feature` or `pr-prepare`, when the leaf/core call should be explicit and consistent with this framework Skip only for changes that are obviously trivial (typo fixes, etc.). ## The two categories **Leaf node.** Code that nothing else depends on — feature endpoints, UI components, scripts, reports, one-off migrations. Failure is local. Tech debt here doesn't spread. Safe for high AI involvement, lighter review. **Core code.** Code many things depend on — auth, payment, data schema, public APIs, shared frameworks, orchestrators. Failure is system-wide. Tech debt here compounds. Requires human leadership and line-by-line review, even if AI assists. When a change spans both, it counts as **core** (the stricter rule wins). ## The six diagnostic questions Walk through these in order. Get user input where the answer isn't obviou