The short version

One install, no leftovers, every config file parses. Healthy. The problem was never the software, it was the pile of stuff loading into every session: a 2.5-month-old log of finished work, an unused plugin, four idle connections, and a version 10 patches behind.

Freed: about 2,870 tokens on every session in the MyExecAssistant project. Everything done here is reversible.

---

What was loading before you typed anything

On top of that, your rules tell every session to also read annette.md (~13,900) and soul.md (~2,600). Run /context in a fresh session for the exact live number. The figures here are disk-based estimates.

---

What changed

1. The stale memory dump, deleted

AGENTS.md opened with 85 lines of session notes from May 14 and 15, logging Vitalency headline scoring work, ending mid-decision on a fork you resolved months ago. It told every session to run tools from the claude-mem plugin, which you have since switched off. That block loaded into every session for 2.5 months. Gone. Your cross-harness handoff protocol underneath it is untouched.

2. The project CLAUDE.md, trimmed 34 lines to 8

• The skill index listed 21 slash commands that do not exist yet. Replaced with a pointer to BRIEF.md, where the roadmap already lives.
• Three remote-launch bullets collapsed into the link that was sitting right above them.
• Removed a reference to Master-TODO.md, which you retired on 2026-07-26.

3. Video transcription moved to a skill

The Whisper workflow now lives in its own skill file and loads only when you actually share a video, instead of sitting in context always.

4. Turned off

• Plugins: cc-gemini-plugin (and your own notes say the Gemini bridge is broken anyway), youtube
• Connections, zero calls in 5.5 days: gmail, youtube-analytics, ideogram (which also needs re-authorizing), postiz

5. Claude Code updated

2.1.210 to 2.1.220. You were stale because background auto-updates are switched off, which is your own setting and I left it alone.

---

The skill listing, fixed

79 skills were producing about 12,100 tokens of names and descriptions against a ~4,000 budget. Over budget, entries get truncated and skill routing degrades, meaning the wrong skill gets picked or one gets missed entirely. Two changes fixed it, and the order matters.

The budget ceiling went from 0.02 to 0.07 (~4,000 tokens to ~14,000). This is the part worth understanding: the setting is a truncation CEILING, not an allocation. You pay for the listing you actually have, so raising it costs nothing today and simply stops the menu being silently cut off as Tier 1 grows.

Then 41 skills moved to Tier 2 on your instruction: the 16 AWS toolkit skills and the 25 HyperFrames video skills, none of which had ever dispatched. Tier 2 is the toy shelf, not the bin. It already holds 216 skills and any one comes back with a single command the moment that work comes up.

Result: Tier 1 dropped from 79 skills (~12,100 tokens) to 45 skills (~7,500), against a 14,000 ceiling. No more truncation, and real headroom to add skills before it becomes a problem again.

One correction, logged

This sweep initially switched off three skills on zero-use evidence: daily-brief, weekly-checkin, and classify-post. All three are on your explicit do-not-park keep-list, which a previous sweep deliberately honoured. That was a mistake, and all three are back. The rule is now written into the tier reference: a standing rule pointing at a skill outranks a zero counter, and the keep-list gets read before any park is proposed.

---

Hooks

You run 20 hooks: 13 at user level, 7 in this project. Every script exists and none is broken.

The Stop hook tail is capped at 45 seconds. Four of the five Stop hooks already had tight timeouts (5 and 15 seconds). The project's session-summary.sh, which makes an OpenRouter call, had none. 45 was chosen deliberately over 30: the script self-caps its own API call at 30 seconds, so a 30-second hook timeout would kill it a moment before it could fail gracefully and log the failure, silently losing summaries on exactly the long sessions where they matter most.

Correction: an earlier version of this page pinned a 600-second Stop-hook run on this script. Stop hooks are all logged under one generic name, so that run cannot actually be attributed to any specific script, and this one's worst realistic case is about 35 seconds.

The count is not your problem, the placement is. Per-tool hooks fire thousands of times at about 190ms and cost you nothing you would notice. But 10 of the 20 run at SessionStart, and that is the 849ms-to-54-second wait before you can type. If you ever want startup faster, that is the only lever worth pulling.

Two startup fixes. The blockers banner was reading from a file last updated on 10 May, which is why every session still claimed a GCP login unblocks "ReverseEngineeringYouTubeChannel", a project your own hot.md says does not exist on this laptop. The hook was fine; the data was 2.5 months old. It has been rewritten from what is actually true now: five real blockers, each date-stamped. Separately, autosave-recovery.py was making a blocking git pull on every session start, capped at 15 seconds, which was the likeliest source of the 54-second startup tail. It only existed for the fresh-clone case, which does not apply on one laptop. Removed.

---

Other findings, no action taken

• SessionStart runs 10 hooks. Median 849ms, worst case 54 seconds, 4 timeouts. That is the pause before you can type.
• Something adds 25 seconds to prompt submission. A UserPromptSubmit hook logged a 25.8-second median. It is not in your settings, so it comes from a plugin in another project.
• Per-tool-call hooks are fine. Bash hooks ran nearly 8,000 times, all near 190ms.
• 164 permission denials, none fixable with an allow rule. About 90 were attempts to cd into another project folder, which is the working-directory boundary rather than a permission rule. 35 were WebFetch, and 5 were rm -f hitting your own deny rule on purpose.
• dataforseo was already switched off in MyExecAssistant before this sweep. It works fine in your other projects. Worth knowing if SEO tools ever go quiet in that one project specifically.

---

How to undo any of it

Config backups are saved on the laptop under ~/.claude/doctor-backups-2026-07-31/. Say "undo the doctor changes" in any session and Charlie restores them.

The three file edits are deliberately left uncommitted so you can review them with git diff before they become permanent. Skills and plugins come back by flipping their value back to true or removing the override.

Scan basis: 400 sessions across 43 projects, 2026-07-25 to 2026-07-31. Usage totals are lifetime since install; window activity comes from session transcripts.