SKILL.md
Sliced Bread Depth
Score every slice as a deep module: a small, stable public surface hiding substantial implementation. A slice can pass every boundary check while its crust is the implementation — a 900-line crust over two trivial helpers is compliant but shallow. The full rationale lives in the Sliced Bread reference; this skill is the measuring pass.
Scope
Default to every slice in the repo. If the user names slices, measure only those but still list the full inventory so ratios have context. Include documented crust exceptions (e.g. a singleton that is the slice's seam) — classify them; do not flag their existence.
Step 1 — Inventory
Find each slice's crust — its public seam in the language's native form: exported identifiers in Go, the package init surface in Python, an index module in TypeScript, a public class surface elsewhere. Apply the surface test: can a consumer see a small, obvious set of externally usable operations at the top level, with no digging into internals and no hundred-symbol entry point? Classify the crust's shape:
| Shape | Signature |
|---|---|
| Thin facade | Re-exports, factories, catalogs; little or no logic of its own |
| Framework-bound | The crust must subclass a framework base (scene node, view, component) |
| Service/sim | The crust owns a hot loop or long-lived process (step, tick, dispatch) |
Step 2 — Measure
Per slice, compute with code (not estimation):
- Crust LOC and slice total LOC — the key ratio is the
implementation share: crust LOC ÷ slice total LOC.
- Internal module count and LOC — the deep layer the crust is hiding.
- Public surface — approximate count of exported/non-underscore
functions, methods, and events/signals on the crust.
- Lifetime mix — whether the public surface mixes unrelated lifetimes
(one-time setup vs per-frame/per-request vs UI wiring).
Step 3 — Assess
Recommend breaking a crust down (extract internals — never add a second public seam) when both hold:
- (a) the crust file holds the hot-path implementation, and
- (b) the deep layer is empty or thin (implementation share heavily
crust-side), or the public surface mixes unrelated lifetimes.
Calibrations that keep the metric fair:
- The ratio is the metric, not absolute LOC. A 250-line crust that is
100% of a pure-factory leaf slice is healthy; a 900-line crust holding 85% of its slice's mass is the smell.
- Framework-bound crusts get a cohesion allowance. Framework callbacks
(lifecycle, physics, render) must live on the subclass; extraction targets are plain helper objects the crust owns, not a second public seam.
- Many internal files is not a finding. A wide crust over thirty deep
modules has an API-clustering problem — group and narrow the surface — not a depth problem. Do not recommend splitting the slice.
- Respect documented intent. A crust whose docstring or comments declare
its surface intentional gets a soft-no with the citation, not a finding.
- Dual seams (live singleton + pure-helper facade) are a
clarify-don't-split: recommend documenting which seam owns what, not inventing a second crust.
- Compare siblings. Two slices implementing the same pattern with
opposite depth (one delegates its hot loop, one inlines it) is the highest-confidence finding — the repo already contains the target shape.
Growth guards — false positives to suppress when grading depth:
<!-- doctrine:growth-guards:start -->
- A single consumer does not by itself prove premature abstraction; grade whether concrete pressure exists. Two consumers are normal evidence, not a hard requirement.
- New single-file concepts that stayed single files are correct; do not flag them.
- A dispatcher introduced to break a cross-slice cycle is demonstrated pressure, even with one event and one subscriber.
- Numeric thresholds are advisory signals, not gradeable violations; grade implementation share, public-surface size, and lifetime mixing.
- In a language whose only privacy mechanism is file placement, a subdirectory marking its contents internal is demonstrated pressure for that visibility boundary, even with a single file inside.
<!-- doctrine:growth-guards:end -->
Verdicts
| Verdict | Meaning |
|---|---|
| extract | Both heuristic arms hold; peel internals out of the crust |
| narrow | Depth exists; cluster and shrink the public surface |
| watch | Trending fat but single-axis; revisit when the next feature lands |
| healthy | Depth where it belongs; no action |
| intent | Wide by documented design; soft-no with citation |
Output
Report three sections, read-only — this skill never edits code:
- Catalog — one table: slice, shape, crust LOC, internal modules,
implementation share, public surface.
- Assessment — one table: verdict per slice, ordered extract → narrow →
watch, each with a one-line why citing file:line.
- Top 3 extractions by ROI — concrete: what leaves the crust, where it
goes, and the in-repo precedent to mirror if one exists. Prefer mechanical wins with existing precedent over speculative restructuring.
An all-healthy catalog is a valid outcome; never manufacture findings.