Importance: High. Status: In Progress (web-reachable items Complete; three items need a Mac session).
Continuation. Sam approved 1A (run injector), 2A (reconcile + migrate to canonical repo, always-allow granted), 3A (notification targets), 4A (compare cowork-disk-cleanup vs monthly-dedupe), 5A (repoint scheduler, always-allow granted), and gave his contact info.
cowork-disk-cleanup clears regenerable caches inside the ephemeral Cowork sandbox (deletes freely, caches regrow); monthly-dedupe dedupes the real Mac home folder and moves irreplaceable user files to Trash with rollback. Different target, cadence, and risk model. No consolidation. cowork-disk-cleanup already carries its own QA-reflection section.docs/migrate-skills-to-repo.sh. One-way (live skills -> repo), dry-run by default, never edits live skills, adds only skills absent from the repo, and lists differing skills as conflicts for manual review instead of overwriting. Dry-run against the Cowork mount classified 87 candidate skills and correctly flagged a conflict without clobbering it.This is the Claude.ai web/Cowork container. It has no write path to Sam's Mac filesystem or scheduler (read-only skills mount, no Mac SSH, no Desktop Commander wired here). So the following are staged turnkey rather than executed:
docs/apply-selfaudit-to-scheduled-skills.sh against the live skills (idempotent, per-file .bak).docs/migrate-skills-to-repo.sh --apply after reviewing its dry-run, then git push./monthly-dedupe and retire the old read-only body. The exact mechanism (launchd plist, cron, or a Claude/Codex scheduled task) needs Mac inspection to edit precisely.All repo changes are plain commits, individually revertable. Both committed scripts are dry-run or idempotent and write backups, so they are safe to run and re-run. The reason the four scheduled skills and the broad migration were not executed from this session is environmental (no Mac write path from web chat), not a blocker in the work itself. When you are on a Mac with the repo checked out, the two scripts in docs/ do the heavy lifting; review their dry-run output before applying. The open architectural question Sam should weigh in on: should the repo be canonical for ALL ~80+ skills (the migration script assumes yes and moves toward it conservatively), or stay a curated subset. GitHub token sourced from Notion API Keys (GITHUB_TOKEN_1), scrubbed after each use.