Task 3.2: Create and configure custom slash commands and skills

• AIn a plugin published to the team's marketplace, which each developer then installs

  Incorrect

  A plugin can share skills, but each developer has to install it, and its changes are reviewed wherever the plugin lives, not with this repository.

• BIn the developer's ~/.claude/skills/, with each teammate adding that folder to their sessions with --add-dir

  Incorrect

  The folder exists only on the author's machine; teammates would have nothing to add, and nothing goes through pull requests.

• CIn a nested docs/.claude/skills/release-notes/ folder, so that it loads only when it is needed

  Incorrect

  A nested skill loads only once Claude works on files under docs/, so /release-notes would not be available from the start of a session.

• DIn .claude/skills/release-notes/SKILL.md inside the repository, committed with the rest of the code

  Correct

  Project skills load in sessions in that repository and reach the team through version control.

Skills in a repository's .claude/skills/ directory are shared with everyone who works in it; ~/.claude/skills/ is for personal skills. Older .claude/commands/ files still work the same way.

• AMove the skill's instructions into CLAUDE.md so that they are part of the context from the start

  Incorrect

  That puts the instructions in every session and does nothing about the thousands of lines the analysis produces.

• BAdd model: haiku so that the skill runs on a smaller, faster model

  Incorrect

  A different model changes cost and speed, not where the output lands; it still fills the main conversation.

• CAdd context: fork to the frontmatter so the skill runs in a subagent and only its result returns

  Correct

  A forked skill runs in an isolated subagent context, so the verbose output stays there and the main conversation receives the result.

• DAdd allowed-tools listing only Read and Grep so that the skill does less work when it runs

  Incorrect

  Changing which tools the skill uses does not keep its output out of the main conversation.

context: fork runs a skill in a separate subagent with the skill content as its task. Use it for skills with verbose or exploratory output that should not pollute the main session.

• AWith {{component}}, {{from}} and {{to}} placeholders

  Incorrect

  Skill substitution does not use that template syntax.

• BWith positional placeholders such as $0, $1 and $2

  Correct

  $ARGUMENTS[N] and its shorthand $N access individual arguments.

• COnly with $ARGUMENTS, which cannot be split into parts

  Incorrect

  $ARGUMENTS holds them all, but indexed forms address each one.

• DWith environment variables that the skill reads at runtime

  Incorrect

  Arguments are substituted directly into the skill content.

Skills receive arguments through $ARGUMENTS, indexed forms such as $ARGUMENTS[0] or $0, or named arguments declared in frontmatter.

• A/frontend:component

  Correct

  Subdirectories in .claude/commands/ become part of the name, joined by a colon.

• B/frontend/component

  Incorrect

  Slashes in the path are replaced by colons in the command name.

• C/component

  Incorrect

  The subdirectory is part of the command name.

• DNothing; files in subfolders are not loaded

  Incorrect

  Files in subdirectories of .claude/commands/ load as commands.

Command files keep working alongside skills; a file in a subdirectory of .claude/commands/ is named by its path with colons.

• AKeep the spec as a supporting file in the skill folder

  Correct

  Supporting files are loaded only when Claude needs them.

• BPut the spec in the project CLAUDE.md

  Incorrect

  That loads it into every session, skill or not.

• CSplit the spec into twenty separate skills

  Incorrect

  Many skills for one reference document adds clutter to the menu.

• DPaste the full spec into SKILL.md so it is always available

  Incorrect

  That loads the whole spec on every invocation.

Keep SKILL.md focused and place large reference material in supporting files in the skill directory, referenced from SKILL.md and loaded on demand.

• Auser-invocable: false, so that only Claude starts the loop

  Incorrect

  This changes who can invoke the skill, not which tools it can use.

• Ballowed-tools listing every tool except AskUserQuestion

  Incorrect

  Listing tools there does not take AskUserQuestion away.

• Ccontext: fork, so that the loop runs in a subagent

  Incorrect

  A separate context does not remove the tool from the loop.

• Ddisallowed-tools: AskUserQuestion, while the skill runs

  Correct

  disallowed-tools removes the listed tools from the available pool while the skill is active.

Use disallowed-tools in SKILL.md frontmatter to remove tools while a skill is active; the restriction clears when the user sends the next message.

• AMove the description into the skill body

  Incorrect

  Claude decides from the description in the listing, not the body.

• BMake the description longer so that it is more complete

  Incorrect

  Extra history pushes the useful part further toward the cut.

• CLead with what the skill does and when to use it

  Correct

  The description is how Claude decides relevance, and long listings are truncated, so the key use case goes first.

• DRename the skill folder to start with "a" so it sorts first

  Incorrect

  Ordering does not explain what the skill is for.

Put the key use case first in a skill's description: Claude uses it to choose skills, and the combined description is truncated in the listing.