Run /doctor first — the two-minute checkup
Before you spend an hour on the big audit, run the checkup that's already built into Claude Code. It's called /doctor and hardly anyone knows it's there. It looks over your setup, tells you what's broken or dead weight, and offers to fix it. It asks before it changes anything.
Type it into Claude Code
Open Claude Code in the folder you work in most, type this, and hit enter. It only exists in Claude Code — the normal Claude chat app doesn't have it.
What it checks
• Installation health — is Claude Code itself installed properly.
• Invalid settings files — one typo in a settings file and Claude quietly ignores the whole file. This is the sneaky one.
• Unused extensions — the add-ons you installed once and never touched again.
• Duplicate agent names — two subagents with the same name in the same folder.
• Bloated CLAUDE.md — instructions in your project's CLAUDE.md that Claude could work out by reading your files anyway, so they're just taking up room.
Go through the fixes one at a time
For each problem it finds, it proposes a fix and waits for your yes. Read each one before you approve it. If you don't understand a fix, ask it "explain that like I've never seen a settings file" before you say yes.
Then do the deep clean below
/doctor checks the plumbing. It won't tell you that a rule you wrote last year is now fighting the newer models — that's what the workspace audit in the next section is for. Do both, in this order.
Just want a look without changing anything?
Type claude doctor in your terminal before you start a session. That version is read-only — it prints the installation and settings problems and touches nothing. Source: Anthropic's "Debug your configuration" guide →
The workspace audit — the deep clean
This is the one I'm running on my own workspace right now. It reads every skill and every set of project instructions you've written, checks them against how the current models actually work, and tells you which of your own rules are getting in the way. It changes nothing until you say so.
Open these two first
Paste both into the chat before you paste the audit prompt, so Claude is auditing you against the real documentation and not its own memory of it.
Anthropic's prompting best practices → · Alvaro Cintas's condensed version on X →
Run the audit
Open Claude Code in the folder you work in most. Paste the two links above, then paste this.
What to expect: this is not a thirty-second job. It has to open every skill file and every instruction file you own and read them properly. If you've got a lot of skills, go and do something else — mine ran for about an hour. Half of mine need to go.
Get it back as something you can actually read
A wall of terminal output is useless for deciding what to delete. Ask for the same audit as a report you can open in your browser, grouped so the obvious deletions sit together.
If the docs melt your brain
There's a plain-language version of the same guide floating around on Reddit. Optional extra reading, not required for any of this: r/promptingmagic thread →
The five working rules to paste at the top
This is the bit that's helped me most. Five rules that go at the top of a project or a skill and change how Claude behaves for everything underneath. They came out of Alvaro Cintas's post — he condensed Anthropic's guide into one copy-paste prompt, and these are my paraphrase of the working rules inside it. Credit where it's due: @dr_cintas. Go and read the original.
Rule 5 is the one that kills the wall of text
Status updates stop being a recap of everything it touched and start being "your invoices are now filing themselves, here's the one thing I couldn't do."
Rule 3 is the one that kills the fake "all done!"
Nothing wastes an afternoon like being told a thing is finished and finding out at 4pm that it was never tested. Make checking a real result the price of claiming progress.
Where to put them
Top of your CLAUDE.md if you want them everywhere, top of a single skill file if you want them only for that job. They're instructions about behaviour, so they belong above the instructions about the work.
Rewrite your rules with the reason attached
Most of us wrote our rules as commands. Never do this. Always do that. That worked on the older models and it makes the newer ones worse, because a hard rule with no reason can only be applied literally — so it gets applied in the ten situations you meant and the ninety you didn't.
Anthropic's own example, word for word:
✗ Less effective
NEVER use ellipses
✓ More effective
Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.
Their line under it: "Claude is smart enough to generalize from the explanation." That's the whole mechanic. Give it the why and it handles the cases you never thought to write down.
The test that catches a bad rule
The docs call it the golden rule: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too." Same energy as the other line I keep coming back to — "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows." Very clever, zero idea how you work. What would they need to know to do the job properly?
Here are four more, written for the kind of rules we all have sitting in our project files.
✗ Before · formatting
Never use bullet points.
✓ After
This copy gets pasted into Instagram captions, where line breaks collapse and bullet characters render as boxes. Write in short paragraphs instead.
✗ Before · tone
Always write casually.
✓ After
My readers are non-technical business owners who have been sold to by a lot of AI people. Write the way I'd explain it to a friend over coffee: name the thing, say what it does, skip the adjectives. If a sentence sounds like a brochure, cut it.
✗ Before · scope
Don't change other files.
✓ After
I maintain this on my own and I can't read code, so I need to understand every change you make. Change the one file we're working on. If a fix genuinely needs a second file touched, tell me which one and why before you touch it.
✗ Before · when to ask
Always ask before you proceed.
✓ After
I'm usually away from the screen while you work, so a question stops the job dead. Ask me only when the choice is mine to make, the action can't be undone, or it spends money. Everything else, pick the sensible option, keep going, and tell me what you picked at the end.
About "just give it the goal"
Lead with the goal and the outcome, and let it choose the how — that's the shift. It is not "numbered steps are dead". The docs still say to "provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters." So: outcome first, always. Explicit steps when the order genuinely matters or something would get missed — a filing process, an onboarding sequence, anything with a compliance step in it.
All five, ready to paste
Drop this into your project instructions and edit the reasons to match your actual business. The reasons are the working part — generic ones do nothing.
When it's still going wrong
Five symptoms and what each one actually is. Every fix here is a line you add, not a prompt you rewrite.
It stops constantly and asks permission for everything
That's rule 4 missing. Add "pause only when you genuinely need me" and define what genuinely means for you — irreversible, costs money, or a decision that's yours. Without a definition it treats every fork in the road as your call.
It over-engineers a simple task
Add "do the simplest thing that works", then be explicit about the outcome you want rather than the method. Asking for a method invites elaboration. Asking for an outcome invites the shortest route to it.
The audit comes back vague
Tell it to name specific files and quote the specific conflicting lines, not general themes. "Your skills have some overlapping instructions" is a horoscope. "Line 14 of content-script.md contradicts line 6 of CLAUDE.md" is something you can delete.
It says "all done!" and it is very much not done
Rule 3. Make checking a real result the price of claiming progress: "before you tell me a thing is finished, run it, open it, or look at the output, and paste me what you saw." Claims get cheap when nothing verifies them.
You fixed the setup and the output is still flat
Then it's a context problem, not a rules problem. It doesn't know your business. Give it the real inputs — who your customers are, what you sell, five things you've actually written — and tell it what a good result looks like. Brilliant new employee, first week, no handover.
The point
Most people are trying to fix output by writing better prompts on top of a broken setup. The setup is the problem. Clean that up first.
Ready to go deeper?
Where to go from here.
Wright Mode Membership
Join a community of women entrepreneurs implementing AI and automation in their businesses. Live calls, templates, and ongoing support.
Claude Masterclass
Learn how to use Claude like a pro. From prompting fundamentals to building real workflows that save hours every week.
Claude Code Masterclass
Go beyond the chat interface. Build automations, process data, and create tools with Claude Code — no developer experience needed.