The /dr-optimize Command — Auditing the Datarim Framework
How /dr-optimize detects bloat, unused components, duplicate coverage, and broken references across Datarim skills, agents, and commands — then proposes and applies fixes with an explicit approval gate.
A framework that grows without periodic review develops the same problems as any codebase: unused components, overlapping instructions, stale references, and descriptions that no longer match what a file actually does. /dr-optimize brings the same structured audit discipline to the Datarim framework itself.
The Optimizer agent runs the work. It covers skills, agents, commands, and templates — building a full inventory, mapping the dependency graph, detecting issues by category, and presenting actionable proposals before changing anything.
When to run it
The recommended cadence is after every five to ten completed tasks, or when /dr-help output starts feeling overwhelming. Running it right after /dr-addskill checks whether the new component overlaps with something that already existed. The command is also auto-suggested by /dr-archive Step 0.5 when the reflection health-check detects framework inefficiencies.
The audit
The command builds a complete inventory table for each component type: name, line count, description, and what loads it. From that inventory it maps all cross-references — which command loads which agent, which agent loads which skills, which skills reference each other. Unreferenced components surface as orphans.
The issue detector applies concrete thresholds: skills above three hundred lines trigger a warning; above four hundred a split is proposed. Agents above one hundred and twenty lines are flagged; above one hundred and eighty, a rewrite is proposed. Any two components with over seventy percent content overlap are merge candidates. Descriptions longer than one hundred and sixty characters are flagged for trimming, since long descriptions reduce reliable skill triggering.
Datarim state hygiene
Beyond the framework files, the audit also checks the operational state. If a task ID appears in both the Active Tasks and Archived Tasks sections of tasks.md, a removal proposal is raised automatically — this catches archives that ran before the cleanup steps existed. The same check runs against activeContext.md for already-archived tasks still listed as active.
Proposals and the approval gate
Every detected issue becomes a numbered proposal: prune, merge, split, fix-description, fix-references, or sync-docs. The command presents the full list and asks which to apply. The answer must be explicit — all, none, or comma-separated numbers. Nothing changes without it.
For any change targeting $HOME/.claude/, a stack-agnostic gate runs over each proposal's text before writing. Stack-specific content — references to particular frameworks, languages, or tools — fails the gate. The proposal is returned to the operator for rewording or relocation to a project-scoped directory instead.
Read about the agent that executes this work in the Optimizer agent post, or start with what Datarim is for context.