Claude Code Skills Have a Model Field. Here's Why You Should Be Using It.

I've been building Claude Code skills for a few weeks. Writing the prompts, testing them, tweaking descriptions so Claude knows when to use which one. Felt pretty on top of it.

Then I got annoyed that every skill was running on the same model — my fastest, most expensive one — even for tasks like "open the dashboard" or "run git status." So I went looking for a way to change that. I opened the source code.

There are 15 frontmatter fields in a Claude Code skill. I was using 3.

The Fields That Actually Matter

Most people write a skill like this:

--- name: my-skill description: Does the thing. ---

--- name: my-skill description: Does the thing. ---

Enter fullscreen mode

Exit fullscreen mode

That's fine. It works. But you're leaving a lot on the table.

Here are the fields that change runtime behavior — not just metadata:

model — Which brain runs this skill

model: haiku

Enter fullscreen mode

Exit fullscreen mode

Claude Code actually switches models when running this skill. Not "uses a cheaper mode" — it calls a different model entirely. So a skill that opens a dashboard, commits code, or fills a form? That's haiku work. A skill that writes a dev article, reviews code, or synthesizes research? That's sonnet territory. Orchestrators that spawn subagents and need maximum reasoning? Leave those on default.

I audited 42 skills. Set 17 to haiku (mechanical tasks), 15 to sonnet (writing/reasoning), left 10 on default (complex orchestration). Every session is now running the right tool for the job.

when_to_use — How Claude decides to auto-invoke

when_to_use: "Use when user mentions 'deploy', 'push to prod', or 'release'. NOT for staging."

Enter fullscreen mode

Exit fullscreen mode

This field gets appended directly to your skill's description in the system prompt. It's what Claude reads when deciding whether to auto-invoke your skill. Skip it and Claude guesses from the description alone, which works fine until your deploy skill triggers on "push this to my notes."

One thing: it's capped at 250 characters. Precise beats comprehensive.

paths — Conditional loading to protect your context window

paths:

• "**/*.sol"
• "**/hardhat.config.*"`

Enter fullscreen mode

Exit fullscreen mode

Skills with a paths: field are not loaded at session start. They sit in a conditionalSkills map and only activate when Claude touches files matching those patterns. A Solidity auditing skill with 2,000 tokens of prompt has no business being in your context window when you're working on a React app.

Every skill without a paths: field is burning context on every session, whether you need it or not.

effort — Thinking depth per skill

effort: low # or medium, high, or an integer

Enter fullscreen mode

Exit fullscreen mode

Controls how much thinking Claude applies before responding. A skill that just runs git log doesn't need deep reasoning. A skill writing a technical spec probably does. Set it explicitly and stop paying for thinking you don't need.

allowed-tools — Hard constraints on what the skill can touch

allowed-tools:

• Read(*)
• Write(src/**)
• Bash`***

Enter fullscreen mode

Exit fullscreen mode

This isn't just documentation. Claude Code enforces it. A skill that should only read files? Lock out Write. A skill that touches source code? Restrict it to src/. You get scope safety without writing a single line of validation logic.

"Just Edit the SKILL.md Files Directly"

You can. Open ~/.claude/skills/my-skill/SKILL.md, add the fields, save. Works fine.

The problem is visibility. You have no idea what model each of your 42 skills is currently set to without opening each file. You can't see which ones have paths: set and which ones are bloating every session. You're grepping through directories to find the one you want, editing files one by one, with no picture of the whole thing.

There's no overview. Until now.

CCO Now Has a Frontmatter Config Editor

The latest version of Claude Code Organizer shows editable frontmatter fields per item in the detail panel. Click any skill: you see the model it's currently set to, its when_to_use text, its paths patterns. Change the model from a dropdown. Edit when_to_use inline. See immediately which skills have conditional loading set and which are loading unconditionally every session.

Same for agents: model dropdown and maxTurns number input to cap runaway agentic loops. For memories: the description field that controls how accurately Claude recalls them.

One place to see and tune the runtime config for your entire Claude setup.

What This Looks Like in Practice

When I ran the audit:

• 17 skills on haiku: dashboard openers, git operations, form-filling, status checkers. Fast, cheap, correct. No reasoning required.

• 15 skills on sonnet: writing assistants, code reviewers, research agents. These need nuance.

• 10 skills on default: complex orchestrators that spawn subagents. They need the full model.

The mechanical skills running on the default model were doing fine — but they didn't need to be. Every extra token is a real cost, and a context window is finite. Right-sizing your skill fleet is the same discipline as right-sizing your cloud infrastructure.

Try It

npx @mcpware/claude-code-organizer

Enter fullscreen mode

Exit fullscreen mode

mcpware

/ claude-code-organizer

Dashboard to manage Claude Code memories, configs, and MCP servers — security scanner for tool poisoning, context token budget tracker, duplicate cleanup, scope management. npx @mcpware/claude-code-organizer

Claude Code Organizer

AI agents: read AI_INDEX.md first. It is the navigation manifest for this codebase — where to find every module, how they connect, and where to look before making any claim about the code.

English | 简体中文 | 繁體中文 | 廣東話 | 日本語 | 한국어 | Español | Bahasa Indonesia | Italiano | Português | Türkçe | Tiếng Việt | ไทย

Claude Code Organizer (CCO) is a free, open-source dashboard that lets you manage all Claude Code configuration — memories, skills, MCP servers, settings, agents, rules, and hooks — across global and project scopes. It includes a security scanner for MCP tool poisoning and prompt injection, a per-item context token budget tracker, per-project MCP enable/disable controls, and bulk cleanup for duplicate configs. All without leaving the window.

v0.16.0 — Context budget constants and MCP security features now verified against Claude Code's leaked source. MCP Controls lets you disable…

About Me

CS dropout. Less than a year of dev experience. I built the first version of CCO after discovering 140 Claude config files I didn't know existed. That was a month ago. Now it has 100+ GitHub stars, users from 15+ countries, and apparently I've been awake for most of March.

I read source code when the docs don't answer my questions. That's how I found these 15 fields — not from documentation (there isn't much), but from loadSkillsDir.ts and SkillTool/prompt.ts. If you want the full field spec, open an issue and I'll write it up.

Here's how to help:

• ⭐ Star it on GitHub — visibility = contributors = better tool for everyone

• 🍴 Fork it — ~800 lines of vanilla JS, very readable

• 🐛 Open an issue — missing a field? Found a bug? I'll look at it same day

• 💬 Comment below — what fields are you actually using? Curious what the distribution looks like across other setups

Now go set a model on every skill you own.