notes-audit · git:20260719.c17d429 · 2026-07-19 · sha256 dc210d033b49df63
notes-audit git:20260719.c17d429A
Immutable. This exact content never changes and is served at /api/v1/blob/dc210d033b49df63.
--- name: notes-audit description: Analyze the macOS Notes folder taxonomy and propose a better organization - find empty/near-empty folders, oversized dumping grounds, duplicate-purpose folders, mixed-language naming, and stale content; then present a target hierarchy for operator approval BEFORE any moves. Use when notes feel sporadic/messy, before a big cleanup, or to review organization health periodically. TRIGGERS - audit my notes, notes are a mess, propose notes organization, analyze notes folders, notes cleanup plan. allowed-tools: Bash, Read --- # notes-audit — analyze, then PROPOSE (never act unilaterally) > **Self-Evolving skill** — if the smell table stops matching how the operator actually organizes (new smells found, false positives), evolve the table in this SKILL.md; see the Post-Execution Reflection at the bottom. This skill is an analysis workflow, not a script: you (Claude) gather the data with the plugin's CLIs, reason over it, and present a proposal. **No reorganization happens in this skill** — execution belongs to `notes-organize`, only after operator approval. ## 1. Gather ```bash NC="$HOME/.claude/plugins/marketplaces/cc-skills/plugins/notes-commander/scripts/notes.ts" bun "$NC" inventory --json # folder tree + counts (fast; always do this) bun "$NC" export # full snapshot when content-level analysis is wanted ``` For content-level auditing, Read the snapshot's `manifest.json` (note names, per-note modified dates, char counts) and sample individual markdown files — do NOT paste hundreds of notes into context; sample representatives per folder. ## 2. Analyze — look for these smells | Smell | Signal in the data | Typical proposal | | ------------------------ | --------------------------------------------------------- | -------------------------------------------------------------- | | Empty/near-empty folders | `count` 0–2 | merge into a sibling or an `Archive` | | Dumping ground | one folder ≫ others (e.g. a 100+ default "Notes") | split by detected themes | | Duplicate purpose | two folders whose names/content overlap | merge, keep the better-named one | | Mixed-language taxonomy | sibling folders in different languages for related topics | group under one parent per domain, keep native names as leaves | | Stale content | manifest `modified` dates years old across a folder | move to `Archive / <year>` | | Deep-vs-flat mismatch | 20+ flat top-level folders | introduce 3–6 domain parents, nest leaves | Respect what's working: don't propose churn for folders that are already coherent. ## 3. Propose Present, in this order: 1. **A target hierarchy** (tree view) with each existing folder's destination. 2. **The move list** — the exact `mkdir` / `move-note` / `merge-folder` commands (with `--dry-run` variants) that implement it. 3. **Manual items** — anything the tooling deliberately won't do: deleting emptied folders, cross-account moves, tag cleanup (no AppleScript API for tags). Then STOP and get explicit approval. On approval, hand off to `notes-organize` and follow its safety protocol (snapshot → dry-run → execute → verify counts). ## Post-Execution Reflection After an audit, check: (1) did the operator reject/modify parts of the proposal? Their reasoning is a missing smell or a wrong default — encode it in the smell table. (2) Did any proposal require a capability the tooling lacks (tags, cross-account)? Confirm it's listed under manual items. (3) Did sampling miss something the operator knew about a folder? Note the folder type so the next audit samples it deeper. Update only for real, reproducible gaps.