/optimizer

name: optimizer
description: "Framework-driven audit and optimizer for a Baalda vault. Applies 10 frameworks covering CLAUDE.md quality, wiki structure, compression, context rot, memory, progressive disclosure, hygiene, cross-file synthesis, architecture and discoverability, plus F10 Claude 5 rule rewriting. Every finding ships a concrete fix; the user picks apply-now or save-to-plan per finding. F10 rewrites rules written for older Claude models into judgment plus the reason, and proposes the documented Claude Fable 5.1 vault guardrails where they are missing. Baalda-aware: takes a vault checkpoint before applying, never touches .context/, and routes every move, rename or delete of a synced note through the app or the MCP tools so notes keep their doc_id. TRIGGERS: optimizer, rewrite my rules, audit my CLAUDE.md, my rules feel too strict, optimize my vault, vault audit, second brain audit, clean up my Baalda vault, framework audit, discoverability check, architecture audit, reorg vault. Run from the vault root."

Baalda Vault Optimizer

Apply 10 frameworks to every markdown file in the vault. For each framework, read its pass-implementation file, run every check, log findings, walk the user through fixes per item, apply (or save to a plan). Save one comprehensive HTML report grouped by framework. **Do not inline the HTML in chat — only the saved path and a one-paragraph summary.**

Operating philosophy — read carefully, this is what makes this skill different

1. **Every finding ships a concrete fix.** No flag-only. No "warn and forget." No manual-review pile. When the user runs apply-mode, every finding becomes either an applied edit, a saved migration step in a dated reorg plan, or (only if the user explicitly declines this finding in walk) a recorded decline. Nothing lingers as an open warning across runs. 2. **Severity is informational, not gating.** `fail` / `warn` / `info` describes how load-bearing the issue is; it does *not* gate whether a fix is offered. Every check produces fixes. 3. **Walk per item, user picks the target.** Bulk-apply is reserved for purely mechanical fixes (em dashes, duplicate H1). Anything semantic — wikilink repointing, merges, routing rewrites, Plot.md generation, reorganizations — is walk-only with the user confirming the destination/winner/wording per item. 4. **Two modes for every fix:** *apply now* (executes in this run) or *save to plan* (writes the change as a checklist step into the **plan file**, whose path is resolved from the role registry in Step 4.3). User picks per finding for high-blast-radius items. Smaller fixes default to apply-now. 5. **Visible progress, never silent.** Step 0.5 creates one TaskCreate entry per stage and per framework; tasks update `in_progress` → `completed` as the run unfolds. The user watches the audit walk through the vault rather than waiting for one big report at the end. 6. **Read and reason, don't just match.** Every framework's triggers surface candidates; every finding requires the agent to read context, judge alignment with the user's stated world, and produce reasoning specific to the case. No paraphrased rule restatements as "reasoning." 7. **Discover structure, never assume folder names.** Vaults vary. One user's curated layer is `Context/`; another's is `About/`, `Me/`, frontmatter on root, or scattered across topic folders. The optimizer runs Step 1.5 (role discovery) before any framework, and every framework references **roles** (context-equivalent, decisions-equivalent, daily-equivalent, folder-index convention…) discovered from content — never hardcoded names. If a role is missing, it surfaces as a finding with a proposed fix ("you have no decisions-equivalent folder; here's a recommendation"), not as a silent assumption. Static path references in pass files are always abstractions; the agent resolves them through the role registry at run time.

8. **Respect how Baalda stores things.** Notes are plain `.md` files, so every *content* fix is a normal file edit and lands live in the app (and for teammates) within ~300ms. But three things are not negotiable — see **Baalda rules** below. Violating them silently destroys note identity and version history, which is the one failure mode this skill must never cause.

Baalda rules

Run these checks in Step 0, before anything else.

R1 — `.context/` and `attachments/` are out of scope

`<vault>/.context/` is Baalda's SQLite index, CRDT update log and doc-id map. `attachments/` holds binaries the app syncs on its own. Never audit, edit, move, delete or report on either. They are in the technical skip list in Step 1.1 and in the protected list in Step 5.

R2 — Is this vault synced? It changes which fixes you may apply

test -f .context/config.json && echo "SYNCED-CAPABLE" || echo "LOCAL-ONLY"

A `.context/config.json` carries the server vault id and the note→`doc_id` map, so this vault is (or has been) synced: its notes have identity and history on a server, and possibly teammates.

• **LOCAL-ONLY** → every fix, including moves, renames, merges and deletes, is a plain file

operation. Proceed normally.

• **SYNCED-CAPABLE** → *content* edits in place are still completely safe and merge live. But a

**move, rename or delete done with `mv`/`rm` looks like delete-then-create to the app**: the note gets a brand-new `doc_id` and loses its version history, its backlinks from other notes' indexes and its sharing settings. So for every finding whose fix relocates or removes a note or folder (F2 merges, F8.2 merges, F9.5 folder merges, F9.6 reorgs, hygiene deletes): 1. If this session is connected to the vault over Baalda's MCP endpoint (**Vault settings → MCP** mints the token), the tools `move_note`, `move_folder`, `delete_note`, `delete_folder` and `create_folder` are available — apply the fix **through them**, never with shell commands. They preserve `doc_id` and broadcast the change to every open app