ba-auto-daily/.claude/skills/clean-scratchpad/SKILL.md

name, description

name	description
clean-scratchpad	Delete this session's temporary probe scripts, debug screenshots, and logs from scratchpad/ (locally and on nik-gpu) using literal filenames only, avoiding Claude Code's permission prompts on destructive commands. Use when asked to clean up scratchpad, or proactively per CLAUDE.md's workflow step 13 once temporary investigation files from the current session are no longer useful.

/clean-scratchpad

Removes this session's disposable files from scratchpad/ — locally and, when relevant, on nik-gpu.

The rule: rm must receive fully spelled-out literal filenames, nothing else

Claude Code's permission engine requires that everything rm (or mv/cp) will actually touch be visible as static, literal text in the command itself. Any command where the real deletion target is determined dynamically gets flagged for manual approval — regardless of the mechanism used to compute it. Confirmed live, three different ways:

1. rm -f scratchpad/test_glob_*.txt — a raw shell glob handed to rm. Blocked: "Glob patterns are not allowed in write operations." Not silenceable via a .claude/settings.json allow-rule.
2. find ... -print0 | while IFS= read -r -d '' file; do rm -f -- "$file"; done — looked like a fix (the glob only ever reaches find, quoted, never the shell), but the loop's IFS= read itself got flagged: "IFS assignment changes word-splitting — cannot model statically." Silently approved during initial testing, which is why this looked clean the first time — it wasn't.
3. find ... -exec rm -f -- {} + — no loop, no IFS, still rejected. The {} placeholder is itself dynamic enough to trigger the same class of guard.

Only the fully literal form is reliably prompt-free:

rm -f -- scratchpad/exact_name_1.png scratchpad/exact_name_2.log

No find, no glob, no loop, no -exec, no xargs in the deletion step — ever. This means you (Claude) must resolve the file list yourself, by reading the output of a prior read-only listing command, and then type out the exact names as literal rm arguments. There is no shortcut that both matches multiple files and avoids the prompt.

A separate, unrelated guard also exists: a compound command that does cd some/dir && ... > file (i.e. cd followed by output redirection in the same command) is blocked as a "path resolution bypass" risk. Avoid this by never combining cd with > in one command — use absolute or already-relative paths instead of cd-ing first.

Steps

1. List what's actually in scratchpad first (read-only, never flagged):

   ls -la scratchpad/
   

   Decide what's disposable (this session's probe screenshots, debug .png/.log output, one-off probe_*.py scripts) versus anything that looks like a reusable calibration asset worth keeping across sessions (e.g. named probes referenced from plan.md or CLAUDE.md, like past probe_arena_*/probe_badge_ocr*/probe_find_best* scripts). If unsure whether something is reusable, ask rather than deleting it.

2. Delete locally with every target filename spelled out literally in one rm -f -- command. Build the list by hand from what step 1 actually showed — don't reuse a stale list from a previous session, and don't fall back to a glob or a find pipeline no matter how many files there are:

   rm -f -- scratchpad/current_state.png scratchpad/old_event_check.png \
     scratchpad/check_badge_now.png scratchpad/check_badge_now2.png \
     scratchpad/probe_ocr_now.py
   

3. Delete remotely on nik-gpu, only if this session also pushed probe files there (e.g. via scp/rsync during live testing). First list read-only, then delete with literal names, no cd combined with redirection:

   ssh nik-gpu 'ls -la ~/repo/ba-auto-daily/scratchpad/'
   

   ssh nik-gpu 'rm -f -- ~/repo/ba-auto-daily/scratchpad/probe_ocr_now.py ~/repo/ba-auto-daily/scratchpad/check_now.png'
   

4. Confirm the result:

   ls -la scratchpad/
   

   Report what was deleted and what was intentionally kept, rather than just reporting exit code 0. If a permission prompt appeared at any step, say so explicitly — a silently-approved prompt still means the pattern used wasn't actually prompt-free, even if the command "succeeded".