Problem
The skill's reporting is organized around bytes — target_reclaimable_local_bytes, size qualifiers, free-space deltas, "reclaimable-bytes total". Under that framing, a zero-byte directory is worth nothing and effectively drops out of the report.
That inverts the actual objective for at least one operator, and arguably in general: safe tidiness is the primary goal; reclaimed space is secondary.
Evidence from a real session
Auditing the C: volume root turned up six user-created directories. Five of them held 1,461 bytes combined — four were entirely empty. They were nonetheless the whole point of the exercise: orphaned residue sitting at the root of the OS drive, left behind by test runs that died before cleanup.
A byte-centric report would have ranked all five as worthless and moved on to the 4.8 GB directory. The operator's judgement was the opposite: the empty directories at the volume root were the complaint.
What the skill should require per entry, regardless of size
- Where did this come from? Provenance resolved from evidence — a manifest, a config file's own contents, an owning repository's source — not guessed from the name.
- What was it for? Intent.
- If it has file content, inspect it all the way down before proposing removal.
In the session above this worked: reading a 66-byte config.toml and one .pem filename identified the owning test suite, and grepping that repository produced the exact call sites that create these directories. None of that was reachable from size data.
Note on the existing line
The skill already says "Empty directories are not inherently junk." That line exists to prevent deleting them — it does not ask anyone to investigate them, and the byte-centric reporting then gives an auditor no reason to spend effort there.
Proposed change
- Make provenance-and-intent a required reported field per entry, rather than a by-product of hint matching.
- Report zero-byte entries as first-class findings.
- Reframe the run summary so tidiness outcomes lead and reclaimed bytes follow.
Problem
The skill's reporting is organized around bytes —
target_reclaimable_local_bytes, size qualifiers, free-space deltas, "reclaimable-bytes total". Under that framing, a zero-byte directory is worth nothing and effectively drops out of the report.That inverts the actual objective for at least one operator, and arguably in general: safe tidiness is the primary goal; reclaimed space is secondary.
Evidence from a real session
Auditing the
C:volume root turned up six user-created directories. Five of them held 1,461 bytes combined — four were entirely empty. They were nonetheless the whole point of the exercise: orphaned residue sitting at the root of the OS drive, left behind by test runs that died before cleanup.A byte-centric report would have ranked all five as worthless and moved on to the 4.8 GB directory. The operator's judgement was the opposite: the empty directories at the volume root were the complaint.
What the skill should require per entry, regardless of size
In the session above this worked: reading a 66-byte
config.tomland one.pemfilename identified the owning test suite, and grepping that repository produced the exact call sites that create these directories. None of that was reachable from size data.Note on the existing line
The skill already says "Empty directories are not inherently junk." That line exists to prevent deleting them — it does not ask anyone to investigate them, and the byte-centric reporting then gives an auditor no reason to spend effort there.
Proposed change