claude-ops/audit-install-state: attribute the largest subtrees and node_modules so the JSON answers "why is my install so big", and record engine version plus CLI args

[kyle-sexton]

Context

"Why is my Claude Code install so big" is a listed trigger phrase in the skill's description, but the JSON report rolls every bulk tree into one row. On the 2026-09-08 run plugins/ reported 13,508 files / 279.1 MB as a single rolled-up entry. The actual answer had to be computed by hand from the CSV: plugins/cache/melodic-software/miro/0.3.15/node_modules held 178.2 MB / 6,150 files, of which biome (69.1 MB), typescript (27.9 MB), rolldown (19.4 MB), esbuild (11.4 MB), and lightningcss (10.0 MB) were build toolchain. The engine already counts every one of those bytes (walk_tree does not prune node_modules), so the attribution is a presentation of measured data, not a new measurement.

Upstream explains why the bytes are there: "When Claude Code copies a plugin into the cache, it also installs the plugin's Node.js package dependencies there", the install is npm ci --ignore-scripts when a package-lock.json is present, and "You can't turn the automatic install off; no setting or environment variable disables it" (plugins-reference.md, plugin caching section, fetched 2026-09-11). npm ci installs devDependencies unless --omit=dev (npm CLI v12 docs). A reader who sees a node_modules bucket with that citation knows the bytes are product-installed rather than litter, without the report rendering any verdict on the plugin.

Separately, the report is not reproducible from itself: it carries schema and generated_utc but no engine or plugin version and no record of the arguments used (--samples 3, --authored-threshold, --root).

Proposed work

• Add a largest_subtrees section: the top N entries by bytes at depths 2 through 5 under any rolled-up entry, each with bytes, files, and evidence: measured, so the JSON names the miro cache directly.
• Add a node_modules bucket: total bytes and file count under any node_modules directory inside plugins/cache/, with a why citing the upstream install behaviour. The bucket attributes no owner and parses nothing (consistent with reference/surfaces.md "never parses their contents"), and it renders no plugin verdict.
• Record engine_version (the plugin version from plugin.json or a constant in the script), and invocation (the parsed CLI arguments) in the report header.
• Tests for each section; SKILL.md Phase 3 gains one sentence pointing the reader at largest_subtrees for the size question.

Acceptance criteria

• On a tree with a plugin cache containing node_modules, the JSON largest_subtrees names the largest cached version directory and its node_modules child with measured bytes and file counts.
• The node_modules bucket's why cites the plugins-reference.md install behaviour and states that the bytes are product-installed; it names no plugin as at fault.
• WHILE an install has timed out and left a partial node_modules tree (plugins-reference.md documents this case), the bucket reports the measured bytes without claiming they are the plugin's full dependency set.
• The report header carries engine_version and invocation.samples, invocation.authored_threshold, invocation.root, invocation.csv.
• The CSV is unchanged in shape and row count.

References

• Run evidence: 2026-09-08 report; CSV breakdown of plugins/cache/melodic-software/miro/0.3.15/node_modules by package.
• plugins-reference.md "plugin caching" (install command table, the cannot-turn-off line, the timed-out partial install line), fetched 2026-09-11.
• npm CLI v12 npm ci and omit config docs.
• plugins/claude-ops/skills/audit-install-state/scripts/install_state.py: walk_tree, rollup, the report assembly; reference/surfaces.md.
• Related: the sibling miro: packaging issue filed alongside this one explains the specific 178 MB case.

Metadata

Field	Value
Category	unspecified
Area	unspecified
Ecosystem	unspecified

---

Generated by Claude Code