disk-hygiene: SKILL.md claims a "final human permission prompt" where the mechanism is a hook-issued ask

[kyle-sexton]

plugins/disk-hygiene v0.20.21. Split out of the audit umbrella. F1, medium (reduced from high after the experiment below).

Problem

SKILL.md describes the manual-handoff deletion step as producing a "final human permission prompt". The actual mechanism is a hook verdict: destructive_guard.py:1539-1551 (_powershell_mutation_verdict) returns permissionDecision: "ask", with _POWERSHELL_VB_FILESYSTEM_DELETE (:1365-1368) matching the deletion spelling.

Confirmed by replaying a synthetic PreToolUse payload through the plugin's own guard and reading "ask" on stdout, with controls (read-only Get-ChildItem deferred, Set-Content returned ask, Bash wc returned deny under the belt).

The docs do not establish that a hook-issued ask reaches a human, and they contradict each other on it:

• One page says a hook can "force a prompt".
• Another's closed list of what no mode auto-approves omits hook-ask while including explicit ask rules.

Those pull in opposite directions and cannot be reconciled from current documentation.

What was measured

The audit initially declined to settle this, because the decisive test appeared to need a permissions.ask rule written into the user's settings. A cheaper discriminator existed and was run instead, needing no settings write:

1. Call 1 — Write tool. Harness lane. The plugin's matcher is Bash|PowerShell and does not cover Write, so a prompt here is not this plugin's.
2. Call 2 — Remove-Item via PowerShell. The guard lane.

Fired as separate calls so each prompt could be attributed. The operator observed a prompt on both.

So in the observed mode, the claim is true — the ask does reach a human. Severity drops accordingly.

Scope limit: this measured one session in one permission mode. It does not establish behavior across modes, and the permissions.ask-rule experiment remains what would settle the general case. Recommended as the maintainers' first step, since it needs a settings write this audit had no authority to make.

What still stands

The skill asserts as a guarantee something the documentation does not establish. That is now a documentation-accuracy finding rather than a safety one, but it is load-bearing: the manual handoff lane's entire safety argument rests on a human seeing that prompt, on the platforms where it is the only lane.

Suggested fix

1. Reword the claim to describe the actual mechanism — a hook-issued ask — rather than asserting a human.
2. Tell operators to add an explicit permissions.ask rule for the deletion spellings. Both doc pages agree an ask rule prompts in every mode and survives a hook, which is the mechanism that makes the original claim true rather than merely usually-true.
3. Optionally, run the settings-rule experiment and document the result, closing the contradiction for everyone.

Measured side effect worth knowing

Both lanes prompting means the manual handoff costs two prompts per path — one for the handoff-paths.json write, one for the deletion. The run behind this audit was 17 paths, so ~34 prompts to reclaim 8,529,560 bytes. The --path inline fix (separate issue) removes the file write and halves that.

Related

Umbrella: #3347. The --path fix: filed alongside this one.

🤖 Generated with Claude Code