Why this matters

Claude Code custom commands are just Markdown files in a specific folder. There’s no package manager step, no build — you drop a file at ~/.claude/commands/<name>.md and /name becomes available in your next session. That simplicity is exactly what let the original tool disappear without a trace: nothing about “drop a file in a folder” requires that folder to be backed up anywhere.

The structure

/doctor lives in a public methodology repo: github.com/nino-chavez/agentic-ways-of-working, at commands/doctor.md. The repo’s own install.sh symlinks its commands, skills, and hooks into ~/.claude/ — which means installing this way gives you the fix for the vanishing problem for free: a symlink into a git-tracked repo, not a lone file with nothing behind it.

Your turn

Clone the repo somewhere durable, then either run its installer or symlink the one file by hand if you’d rather not take everything:

git clone https://github.com/nino-chavez/agentic-ways-of-working.git ~/agentic-ways-of-working
mkdir -p ~/.claude/commands
ln -s ~/agentic-ways-of-working/commands/doctor.md ~/.claude/commands/doctor.md

Start a new Claude Code session (or restart your current one) so the command becomes available.

Why this matters

/doctor runs ten checks, and the report can look like a wall of findings if you don’t know what you’re looking at. The report is structured so the summary tells you what matters and the detail table backs it up — read it in that order, not top to bottom as a flat list.

The structure

The ten checks fall into a few natural groups:

Is the install itself sound? (Check 0) — duplicate or leftover Claude Code installs, a PATH problem, settings files that fail to parse, agent-definition files with broken or colliding names. As of the version you just installed, this check also asks whether each skill, command, hook, and agent-definition file is actually backed by version control — more on that in Exercise 3.

What’s costing you and not earning it? (Check 1) — unused skills, MCP servers, and plugins, scored against real usage counters rather than a guess. The important nuance: some MCP tool connections cost context on every single turn, and some cost nothing until you actually invoke them (Claude Code defers their full definition until it’s needed). /doctor knows the difference and won’t tell you to remove something “to save context” when the real savings are zero — it’ll frame that as decluttering instead, which is honest about what you’re actually getting.

Is your memory bloated or duplicated? (Checks 2-4) — overlap between your personal, always-loaded notes and your project’s checked-in rules; content in a CLAUDE.md file that a session could just as easily derive by reading the code; guidance that’s always loaded but only needed sometimes, which could move to an on-demand skill instead.

Is anything slow, current, or unnecessarily locked down? (Checks 5-9) — hooks that run often and take too long, your total resident context cost across everything, whether your Claude Code install itself is current, and two permission-related checks covered in Exercise 4.

Your turn

Open your own report. Find the plain-language summary at the top — it should be two or three sentences, no jargon. Then find ONE specific item in the detail table below it, and before moving on, answer for yourself: what is this thing, why was it flagged, and what would happen if you removed it?

Why this matters

This is the check that didn’t exist when the original tool disappeared. Everything else in /doctor asks “is this earning its keep.” This one asks a different question: “if your machine died tomorrow, would this still exist anywhere?”

The structure

An untracked item is a file or symlink that’s present on disk, fully loadable by your next session, and backed by nothing — never committed to git anywhere. If it’s lost — a new machine, a careless cleanup command, a bad git clean in the wrong directory — there’s no error, no log entry, nothing to git diff against. It’s just gone, the same way the original command was.

The subtle part: a lot of what’s in ~/.claude/skills/ and ~/.claude/commands/ is symlinks, not real files — small pointers to a real file living elsewhere. A symlink can point at a perfectly legitimate, fully-committed repository while the pointer itself was never added to git. Checking where a symlink points isn’t enough. The pointer needs its own entry tracked too, or the wiring disappears even if the target survives.

That gives you two things to actually worry about, and they’re not the same severity:

• Untracked and never used — the easy case. Nothing is lost if it’s gone; it’s just clutter. Safe to remove or safe to ignore.
• Untracked and actively used — the one worth taking seriously. Something you rely on, sitting with no recovery path. This is exactly the state the original /doctor command was in for the four days before it disappeared.

Your turn

Go back to your Check 0 findings and pull out everything flagged as untracked. For each one, cross-reference it against Check 1’s usage data: has it actually been used?

Why this matters

A tool that finds problems and doesn’t distinguish “safe to auto-apply” from “changes what runs without asking you” is a tool you’ll eventually stop trusting. /doctor draws that line explicitly, with two separate confirmation gates instead of one.

The structure

Gate one: cleanup. Checks 0 through 4 and 7 — the unused extensions, the memory dedup, the derivable content, the version currency, and now the untracked-extension findings — bundle into a single question. The recommended action is listed first and labeled “(recommended)”; declining everything is listed last. You can also say “let me pick” and get a follow-up with one option per group.

Gate two: permissions. Checks 8 and 9 — turning on auto permission mode by default, and pre-approving specific read-only commands you keep getting denied on — are asked separately, and only if they found something to propose. This is deliberate: changing what runs without asking you is a different kind of risk than deleting an unused skill, and bundling the two would let you consent to a permission change without really seeing it.

Almost everything proposed is reversible. Skills and MCP servers get disabled, not deleted — a one-line settings change you can flip back. Where something does get deleted (a leftover duplicate install, for instance), the report quotes exactly what’s being removed so you can reconstruct it if needed.

Your turn

Answer the cleanup question. If you’re not sure about a specific item, choose “let me pick” rather than accepting everything blind — the follow-up question lets you approve group by group.