The Optimizer Agent — A Framework That Does Not Bloat
How Datarim's Optimizer agent audits skills, agents, commands, and templates for bloat, duplication, and drift — and proposes concrete fixes before things get out of hand.
A framework grows by addition. A new skill here, a new agent there, a command added for a one-off need that quietly stays in the roster. After enough additions, the descriptions start contradicting each other, two skills cover the same domain, and the total context cost of loading the framework is noticeably higher than it was six months ago. The Optimizer agent exists to catch this before it becomes structural debt.
It runs at /dr-optimize and also participates in /dr-archive Step 0.5 — the health check that runs before a task is closed — where it flags bloat but does not auto-run a full optimization pass.
What the audit covers
The Optimizer scans all skills, agents, commands, and templates. It measures size against thresholds — skills over 300 lines get a warning, over 400 a split recommendation; agents over 120 lines get a warning, over 180 a split recommendation. It checks description budgets: each description has a 155-character cap, and the total across the framework has an 8 000-character ceiling. It maps the dependency graph from commands down to agents and skills, and surfaces any orphaned components that nothing references.
The structured audit report has six sections: a health metrics dashboard, the top five oversized files per type, description budget violations, merge candidates, orphan analysis, and actionable recommendations grouped by risk level.
A concrete example
Suppose two skills both contain sections on how to handle API rate limits — one inside a networking skill, one inside a retry skill. The overlap is around 80%. The Optimizer flags them as merge candidates, shows the duplicated content side by side, and proposes a single consolidated skill with a cross-reference from the other. Nothing is deleted until the operator approves.
The boundary
The agent does not delete files on its own. Every removal, merge, and rewrite is a proposal first. It also does not merge components that serve genuinely different purposes — overlap alone is not sufficient reason. The goal is context efficiency without losing meaning, not compression for its own sake.
Where it fits
The Optimizer runs on Sonnet. The work is systematic analysis against defined thresholds — it does not require the deeper reasoning of an architecture review. It can run as a quarterly maintenance pass or after a burst of new component additions, whenever the framework needs a coherence check.
Full details on the Optimizer reference card, or read what Datarim is for context.