I Wrote a Config Setting That Doesn't Exist, Then Debugged It for an Hour

Have you ever followed your own notes, finished the task, then realized the notes were wrong — and you wrote them yourself?

That was my today.

---

Here's What Happened

Claude Code startup threw a red line:

212 skill descriptions dropped · /doctor for details

I had 222 skills installed, exceeding Claude Code's default 1% context budget. 212 got "dropped" — descriptions aren't loaded, auto-triggering effectively dead.

How do you disable the unused ones? I opened a rules file I'd written two months ago:

~/.claude/rules/anchor-summon.md

It said, clear as day:

Set ~/.claude/settings.local.json with skillOverrides:

{
  "skillOverrides": {
    "ref-low-priority": "off"
  }
}

Fine. I'll do that.

I ran a script stuffing 130 unused skills into skillOverrides set to "off", restarted Claude Code.

Startup message:

212 skill descriptions dropped · /doctor for details

Not a single one fewer.

---

I Blamed Three Wrong Things First

First reaction: wrong path?

I'm on a Claude Code Junyi variant where the config dir is ~/.claude-junyi/, not ~/.claude/. Stepped on this mine two days ago.

CLAUDE_CONFIG_DIR=/Users/young/.claude-junyi

Created a symlink. Restarted. Still 212.

Second reaction: wrong value? Maybe it's "disabled" not "off"?

Started grepping every keyword combination.

Third reaction: maybe the Junyi variant doesn't support this setting?

Started questioning the dual-Claude architecture.

An hour burned.

---

The Truth

I ran:

claude --help 2>&1 | grep -i skill

--bare       ... Skills still resolve via /skill-name
--disable-slash-commands       Disable all skills

No skillOverrides.

I WebSearched "Claude Code skillOverrides."

Three results total. All written by me.

skillOverrides never existed.

Two months ago, I "reasonably inferred" a setting I thought Claude Code "should" have. The naming was plausible, it looked real, and even I was fooled two months later.

Claude Code sees an unknown key and silently ignores it — no error, no warning.

I stuffed 130 entries into a key the tool doesn't recognize. Of course nothing happened.

---

What Actually Works

Back to official docs. Claude Code v2.1.129+ has real mechanisms:

// ~/.claude/settings.json
{
  "skillListingBudgetFraction": 0.02
}

Default 0.01 (1% context). Set 0.02 = double the budget.

Or run:

/skills

Opens a UI picker to individually toggle skills on/off.

Or the strongest option: add to each SKILL.md frontmatter:

disable-model-invocation: true

These three are real, implemented by Anthropic, verifiable via --help and official docs.

My skillOverrides? My imagination.

---

The Real Lesson

It's not "I wrote a wrong setting." That's surface-level.

The real problem: I didn't verify when I wrote the notes two months ago.

Past-me thought "Claude Code should have this feature," and casually wrote it into a rules file as if it were real SOP.

Present-me followed the notes and fell into a pit I'd dug myself.

Worse: if I hadn't caught it, those notes would keep feeding into future AI sessions, misleading future-me indefinitely.

The iron rule for writing config / SOP in the AI era:

1. Does the CLI actually support this key? Run <tool> --help
2. Do official docs actually document this setting? WebSearch or fetch official sources
3. Has anyone asked about it on GitHub? Check feature requests or bug reports
4. After changing it, is there an observable behavior difference? Run a sentinel test that must change

If any of the four fails, label it [unverified]. Don't write it into SOP.

And definitely don't write it into notes that future-you will follow blindly.

---

Epilogue

I wrote this lesson into a feedback memory:

memory/feedback-imagined-feature-not-verified.md

Added an override rule to CLAUDE.md: verify any config key exists before writing it.

Then built a skill-budget-fix skill that SOP-ifies the real fix — next time I see "N skill descriptions dropped," I run this skill instead of inventing imaginary solutions.

This blog post is itself a failsafe — once published, I can't pretend it didn't happen.

Your rules files — do any of them have a skillOverrides equivalent? Something past-you invented two months ago that present-you treats as ground truth?

Next time you onboard a new tool, maybe run an audit.