Claude Code skills and slash commands: SKILL.md

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. You wrote .claude/skills/api-conventions/SKILL.md for your team's endpoint patterns, and it does the right thing when you type /api-conventions. You would rather not have to remember it: when a teammate asks Claude to add an endpoint, Claude should reach for the skill on its own. What change would most effectively get Claude to load it unprompted?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: C is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   Your answerA.Rename the skill directory under .claude/skills/ to add-routes, so the command name matches the wording people use.The directory name sets the command you type. Claude's automatic invocation is matched against the description, so renaming the folder changes the command and leaves the matching untouched.Your answerB.Give the skill a metadata map saying what it does and when to use it, putting the key use case first.metadata is a free-form YAML map for your own key-value data, such as catalog fields read by your own tooling. Claude Code does not act on its contents, so nothing there influences when a skill is chosen.The answerC.Give the skill a description saying what it does and when to use it, putting the key use case first.Automatic invocation is driven by the description field: 'What the skill does and when to use it. Claude uses this to decide when to apply the skill.Your answerD.Move the skill directory to ~/.claude/skills/, so every project on this machine loads its instructions at startup.Moving the directory to ~/.claude/skills/ changes which sessions load the skill, not whether Claude reaches for it. In any location, only the description is in context until the skill is invoked.

   Show the full explanation and doc quotes

   If omitted, uses the first paragraph of markdown content.' The docs add that the combined description and when_to_use text is truncated at 1,536 characters in the listing, so the key use case belongs first.

   Written from code.claude.com/docs/en/skills.md

2. Your /migrate-component skill takes a component name, a source language and a target language, so you invoke it as /migrate-component SearchBar JavaScript TypeScript. You are now writing the line in the skill body that has to name the target language. Which approach should you take?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: A is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   The answerA.Use $2 in the body, the shorthand form of $ARGUMENTS[2], because argument indexing is zero-based.Indexed placeholders count from zero. The documentation defines $ARGUMENTS[N] as "a specific argument by 0-based index, such as $ARGUMENTS[0] for the first argument" and $N as "shorthand for $ARGUMENTS[N], such as $0 for the first argument or $1 for the second." With SearchBar JavaScript TypeScript, the target language sits at index two.Your answerB.Use $ARGUMENTS in the body, which expands to the full argument string exactly as you typed it.$ARGUMENTS always expands to the full argument string as typed, so the body would receive all three values wherever it appears.Your answerC.Use $3 in the body, the shorthand form of $ARGUMENTS[3], because argument indexing is one-based.Indexing starts at zero, so $0 is the component name and $3 has no argument at its position. An indexed placeholder with no argument stays in the content unchanged.Your answerD.Use $language in the body, a named placeholder that maps to the third position on its own.A $name placeholder only works when the name is declared in the arguments frontmatter list, where names map to argument positions in order.

   Written from code.claude.com/docs/en/skills.md

3. Your /render-chart skill ships a helper script inside its own directory, and the body tells Claude to run it. Some teammates keep the skill under their home directory and others commit it to the repository, so its absolute path differs everywhere and every run stops for a Bash approval. What's the most effective way to pre-approve that script?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: B is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   Your answerA.Write the bare path scripts/render.sh in the body and give the skill an allowed-tools rule of Bash(scripts/render.sh *).A relative path resolves against the working directory, so the command Claude actually issues varies with where the session started and stops matching the rule.The answerB.Write the path as ${CLAUDE_SKILL_DIR}/scripts/render.sh in both the body and the skill's allowed-tools Bash rule.${CLAUDE_SKILL_DIR} names "the directory containing the skill's SKILL.md file," and Claude Code substitutes it in two places: the skill's markdown content, and Bash rules in the allowed-tools frontmatter. As the documentation puts it, "using the same variable in both places lets a skill run a bundled script without a permission prompt," because the rule then matches the exact command the body names.Your answerC.Write the path as ${CLAUDE_PROJECT_DIR}/scripts/render.sh in both the body and the skill's allowed-tools Bash rule.${CLAUDE_PROJECT_DIR} expands to the project root, the same path hooks and MCP servers receive. A personally installed skill does not live under it.Your answerD.Write the path as ${CLAUDE_PLUGIN_ROOT}/scripts/render.sh in both the body and the skill's allowed-tools Bash rule.${CLAUDE_PLUGIN_ROOT} is substituted only in plugin skills. In a personal or project skill the text is left as it stands and no rule matches.

   Written from code.claude.com/docs/en/skills.md