# Classify Change > Classify a proposed code change as Leaf Node or Core Code to decide how much AI usage and review rigor is appropriate. Use this skill whenever the user asks "is this leaf or core", "what kind of change is this", "should I vibe code this", "can AI write this", "how rigorous should the review be", or before starting any non-trivial change. Also useful as a sub-step inside other workflows (planning, PR prep, code review) when classification matters. Asks 6 diagnostic questions about propagation range, change frequency, tech-debt tolerance, examples, failure cost, and review intensity, then outputs a clear classification with the recommended approach. Trigger even when the user describes a change without explicitly asking for classification — the answer changes how they should proceed. - Skill: `majiayu000/classify-change` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds add majiayu000/classify-change` - Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/classify-change/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: majiayu000 (https://skillmd.com/u/majiayu000) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/majiayu000/classify-change --- # 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 obvious from the codebase. ### Q1 — Propagation range > If we change this, what depends on it? - Few callers (one or two specific places) → leaf-leaning - Many callers / many modules → core-leaning ### Q2 — Expected change frequency > Will this part of the codebase keep evolving, or is it close to "done"? - Likely stable for the foreseeable future → leaf-leaning - Will keep evolving and needs to stay extensible → core-leaning ### Q3 — Tech-debt tolerance > If this code becomes a little ugly, will future work suffer? - A bit of debt is fine, contained → leaf-leaning - Debt here will block other work → core-leaning ### Q4 — Examples that fit > Which of these does the change look most like? > > - Reports, dashboards, single endpoints, UI components, scripts, one-off jobs → **leaf** > - Auth, payments, data schema, public APIs, shared utilities, orchestration → **core** ### Q5 — Failure cost > If this code goes wrong, how far does the failure spread? - Region of the app, easy rollback → leaf-leaning - System-wide, affects users / data → core-leaning ### Q6 — Review intensity needed > Can the change be trusted via interface + tests, or must someone read every line? - Interface + tests are enough → leaf-leaning - Line-by-line read required → core-leaning ## Decision logic After running through the questions: - **All / mostly leaf-leaning** → classify as **leaf** - **All / mostly core-leaning** → classify as **core** - **Mixed / spans both** → classify as **core** (strictest rule wins; consider splitting the change) ## Output format ```markdown ## Classification: [LEAF NODE | CORE CODE] ## Why - Q1 (propagation): → - Q2 (frequency): → - Q3 (tech debt): → - Q4 (examples): → - Q5 (failure cost): → - Q6 (review intensity): → ## Recommended approach ### If LEAF - Safe for high AI involvement - 1 reviewer is enough - Trust the tests + interface; you don't need to read every line - 3 e2e tests minimum (1 happy + 2 errors) - Plan still required, but plan.md can be lightweight ### If CORE - AI may assist, but a human must lead the design and own the review - 2+ reviewers, including the module owner - Line-by-line review of the diff - PR description must mark which files were human-reviewed line-by-line - If the change is large, split into a human-led core change + a leaf feature change ``` ## Edge cases ### "It's a leaf, but it touches core code in passing" If the change reads core code (imports, calls) but doesn't *modify* core code, it's still leaf. The classification is about which lines change, not which lines exist. ### "It's a script / one-off / migration" These are leaf even if they read core data — failure is bounded by a single run. But: if the script writes to production data, the *verification* of the script needs to be core-grade (don't trust it from spot-checks alone). ### "The code is in a leaf path but the failure mode is system-wide" E.g., a script that accidentally writes to every user record. Reclassify based on **failure cost**, not file location. The point of the framework is failure containment. ### "Modeling the boundary will keep moving as models improve" True. Today's core might be tomorrow's leaf as models become more reliable. Tech leads should re-examine the leaf/core boundary quarterly. But don't move the line based on hope — move it based on track record. ## Common mis-classifications - **A new endpoint is leaf, even if "the API" is core.** A single new endpoint is local. Modifying the framework that all endpoints use is core. - **A new UI page is leaf.** Modifying the design system or shared component library is core. - **A new report is leaf.** Modifying the BI infrastructure / data warehouse schema is core. - **A bug fix is whatever the file it's in is.** Don't auto-classify bug fixes as low-risk; if the bug is in core, treat the fix as core. ## Stopping condition End the skill when the user has a clear classification + the recommended approach for it. Carry the classification into `plan-feature` or `pr-prepare` to set the review rigor there — this skill is the canonical owner of the leaf/core definition those workflows should follow.