Vibe Code Leaf Finder

Vibe Code Leaf Finder

Purpose

Classify every part of a codebase by risk-to-modify-with-AI, producing a report that tells the user where AI can write freely (leaves), where it needs guardrails (branches), and where humans must stay in the loop (trunks).

Based on Erik Schluntz's framing from "Vibe coding in prod" (Anthropic, 2025): tech debt is acceptable in leaf nodes because nothing depends on them, but trunks and branches are core architecture that must be "protected, deeply understood, extensible, and flexible."

Full framework quotes and rationale: references/schluntz-framework.md.

When to Use

Trigger this skill when the user:

• Points at a codebase or directory and asks where it's safe to use AI.
• Wants a report of "leaf nodes" vs "trunks" before a vibe-coding session.
• Is a PM, founder, or non-engineer who wants to ship features without breaking core architecture.
• Says phrases like: "vibe-code audit", "leaf finder", "where can I let Claude loose", "which files are safe to rewrite", "can a PM edit this".

Do NOT use this skill for: general code review, bug hunting, or performance audits. This skill only answers one question — "where is it safe to let AI write this code without human review of every line?"

Workflow

Execute these four checks against the target scope. If no scope is given, ask the user once: "Scope this to a directory, a package, or the whole repo?"

Step 1: Dependency Check (outward edges)

For each file in scope, find every place outside the file (and outside the scope directory if scoped) that imports or references it.

Use ripgrep, not grep. Search for:

• Import statements: from <module>, import <module>, require('<path>'), from '<path>'
• Symbol references: exported class names, exported function names
• String references: dynamic imports, module registries, route tables

Record, for each file: a list of external referrers. Zero referrers = candidate leaf.

Step 2: Isolation Check (inward edges)

For each candidate leaf from Step 1, confirm it is also a pure consumer not a provider:

• Does it register anything globally (plugins, middleware, migrations, event handlers, cron jobs)?
• Does it write to shared state (singletons, global config, shared DB schema)?
• Does it expose a public API surface (HTTP routes, SDK exports, CLI commands)?

A file with zero external importers but that registers a middleware or a route is NOT a leaf — it is a hidden trunk. Flag these as BRANCH.

Step 3: Stability Check (time axis)

For each remaining leaf candidate, inspect git history:

git log --follow --oneline --since="12 months ago" -- <file>
git log --follow --stat -- <file> | head -40

Signals of a true leaf (end-feature, unlikely to grow):

• Low commit frequency after initial creation.
• Commits are bugfixes or copy changes, not structural refactors.
• File has no TODO, FIXME, or HACK comments pointing to future expansion.
• No recent PR descriptions mention building on top of it.

Signals of a hidden trunk:

• High commit churn.
• Frequent "refactor", "extract", "split" commits.
• Comments like "temporary", "will move", "refactor soon".

Step 4: Testability Check (verification axis)

This is the Schluntz test: can you verify this feature works without reading the implementation?

For each leaf candidate, answer:

• Does it have clear, observable inputs and outputs (HTTP request → response, CLI args → stdout, form input → rendered DOM)?
• Can you write an end-to-end test that exercises it from outside?
• Can a non-engineer verify the behavior by using the product?

If no to any of these: downgrade to BRANCH.