Claude Code Skill Design: Choosing Location, Scope, and Tools

What Claude Code skill design asks of you

Claude code skill design is the evaluate-level skill of taking a requirement in plain English and producing a configuration that satisfies it on every relevant axis at once. The earlier knowledge points gave you the parts: command and skill directory structure, SKILL.md frontmatter, the skills-versus-CLAUDE.md decision, and personal customisation. Design is where you combine them. The exam stops asking "what is allowed-tools?" and starts asking "given these constraints, configure the thing correctly."

The trap at this level is partial answers. A design that picks the right folder but forgets to isolate a noisy skill, or that pre-approves tools without blocking the destructive ones, will be marked wrong even though it got something right. Train yourself to walk all three axes every time.

The three design axes

Reduce every scenario to these three questions and answer each explicitly.

• Location, who needs it? Shared with the team means the project .claude/ folder (committed via git): .claude/commands/<name>.md or .claude/skills/<name>/SKILL.md. Just for you means ~/.claude/. This is the sharing axis.
• Isolation, how noisy is it? If the skill generates verbose discovery output (codebase analysis, brainstorming, log spelunking) that you will not reference again, add context: fork so it runs in a subagent and returns only a summary. Quiet skills run inline.
• Tool scope, what may it touch? Pre-approve the tools the skill legitimately needs with allowed-tools so it runs without nagging you. For a read-only analysis skill, that means listing only Read, Grep, and Glob, and, to be sure it can never write, removing write-capable tools with disallowed-tools or permission deny rules. allowed-tools alone pre-approves but does not hard-block, so safety-critical restrictions need the deny side too.

Three canonical scenarios

The knowledge point is built around three textbook cases. Learn them as patterns.

1. Team-wide /review command. Requirement: everyone should run the same review. Design: project location, .claude/commands/review.md or .claude/skills/review/SKILL.md, committed so git shares it. Tool scope is read-leaning since review inspects rather than rewrites.
2. Personal /brainstorm skill with verbose output. Requirement: a private ideation helper that prints a lot of exploratory text. Design: personal location ~/.claude/skills/brainstorm/, plus context: fork so the verbose brainstorming runs in an isolated context and only the distilled result returns to your main thread.
3. Analysis skill that must not modify files. Requirement: a safe auditor. Design: allowed-tools: Read Grep Glob to pre-approve exactly the read-only tools, and disallowed-tools (or deny rules) to remove Write, Edit, and destructive Bash so the skill is structurally incapable of changing the codebase.

The fourth consideration: who pulls the trigger

The three axes cover most scenarios, but a complete design sometimes has to answer a fourth question: who is allowed to invoke this, you or Claude? Two frontmatter fields settle it. disable-model-invocation: true makes a skill manual-only, which is the responsible default for anything with side effects, a deploy, a commit, a message send, because you do not want Claude deciding the moment is right on its own. user-invocable: false does the opposite, hiding a skill from the slash menu so only Claude can reach it; this suits background knowledge that is not a meaningful action for a person to type, such as a skill that explains how a legacy system behaves. When a scenario stresses control over timing or warns against automatic side effects, the invocation-control fields are the part of the design that earns the marks. Treat this as an optional fourth axis you reach for whenever the requirement is about who triggers rather than what runs.

A design checklist

Turn the axes into a routine you can run under exam pressure. For any command or skill, answer in order:

1. Location. Shared with the team means the project .claude/ folder, committed via git. Personal means ~/.claude/. Decide and commit.
2. Isolation. Verbose, single-use output means context: fork, usually with an agent such as Explore. Quiet work runs inline.
3. Tool scope. Pre-approve the tools it genuinely needs with allowed-tools. If it must never perform an action, deny those tools with disallowed-tools or permission rules, pre-approval alone is not a restriction.
4. Invocation. Side effects or timing-sensitive actions get disable-model-invocation: true. Background knowledge gets user-invocable: false. Otherwise leave both defaults.

A design that answers all four lines is complete; one that stops early is the partial answer the distractors are built from.

Why partial designs are the trap

The reason this knowledge point reaches evaluate level is that every wrong answer is almost right. A distractor will nail the folder and forget that a noisy skill needs forking. Another will pre-approve a tidy read-only tool set and quietly leave write tools reachable for a skill the prompt said must never modify code. A third will pick the correct isolation but place a team workflow in a personal folder, so the team never gets it. Because each of these gets one axis correct, they feel plausible, and a reader who fixates on the axis they happened to check first will choose one. The defence is mechanical discipline: walk location, isolation, and tool scope (and invocation when relevant) on every option, and prefer the answer that is correct on all of them rather than the one that is correct on the axis you noticed. Architects are paid for complete configurations, and the exam mirrors that by rewarding the design that leaves no requirement unaddressed.

Common misreadings to avoid

Reading a requirement for its hidden constraints

Half the difficulty at this level is not the configuration itself but noticing every constraint the scenario implies without spelling out. Train your ear for the signal words. "Everyone on the team should run the same check" is a location signal pointing at the project folder. "Produces a long report" or "floods the conversation" is an isolation signal pointing at context: fork. "Must never alter," "read-only," or "safe to run unattended" is a tool-scope signal pointing at deny rules layered over a read-only allowed-tools set. "Only when I decide" or "has side effects" is an invocation signal pointing at disable-model-invocation. A single sentence can carry two or three of these at once, which is why the complete design so often combines settings rather than relying on one.

The discipline, then, is to read the requirement twice: once for what it asks you to build, and once for the constraints hidden in its adjectives. Underline the signal words, map each to an axis, and only then assemble the configuration. This habit is what separates an architect who reliably picks the complete answer from one who configures the obvious axis and misses the implied one. Because the exam writes its distractors precisely around those missed constraints, slowing down to extract them is the highest-leverage move you can make on this knowledge point.

A practical drill makes the habit stick: take any requirement and write the three or four axis answers as a single line before you look at the options, such as "project folder, fork with Explore, read-only plus deny writes, manual invocation." With your own complete design already on the page, scanning the choices becomes a matching exercise rather than an open question, and a distractor that silently drops one of your axes stands out immediately. That small front-loaded effort is what converts a hard evaluate-level item into a quick comparison.

How this shows up on the exam

This evaluate-level knowledge point is where Domain 3 (20% of the exam) tests synthesis, almost always through Scenario 2 or Scenario 4. Questions present a requirement with two or three implicit constraints, shared or personal, noisy or quiet, safe or write-capable, and the best answer is the option that addresses all of them. Distractors are seductive precisely because they get one axis right and ignore another: correct folder but no fork for a verbose skill, or pre-approved tools with no deny rule for a "must not modify" requirement. Walk location, isolation, and tool scope every time, and you will pick the complete design over the partial one. This same evaluate-by-axes habit reappears across Domain 3, from convention application to CI/CD pipeline design.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Official · Anthropic AcademyOpen full lesson in Academy

Custom commands

Why watch: Deciding where a command lives based on sharing needs is the command-design scenario this KP tests.

More videos for this concept

Custom commands

Claude Code in Action · 1:44

Creating your first skill

Introduction to Agent Skills

Skills vs. other Claude Code features

Introduction to Agent Skills

Claude Code Skills vs Custom Slash Commands

Software Engineer Meets AI

Claude Certified Architect: Ep 11 | Custom Slash Commands & Skills | Full Course Series

Peace Of Code

Claude Code Skills: Build Custom Slash Commands

Alex To Go Eng

Claude Code Tutorial #6 - Slash Commands

Net Ninja