claude-code [Feature] Expose custom slash commands as tools

Better integration across subagents and anything that is scoped to tools. Makes code more DRY since we can have user facing commands that subagents can also use as tools.

Aug 12 '25 15:08 gburch

Found 1 possible duplicate issue:

https://github.com/anthropics/claude-code/issues/5510

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Aug 12 '25 15:08 github-actions[bot]

Found 1 possible duplicate issue:

[Question] Can "mcp serve" expose its slash commands? #5510

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead

To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is similar but this is not about mcp serve but more about giving subagents access to slash commands through the mcp tools. In the end the implementation may address both but as stated I would say this is different.

Currently I find myself starting off with a custom slash command and then turning that into an agent later and removing the slash command and instead referencing the agent. The reason this happens is because I have a lot of orchestration where slash commands would be useful but the sub-agents won't run them. I have had some success referencing them with full paths and bypassing permissions (@ reference doesn't work, especially for user scoped commands) but this is not consistent or maintainable.

Aug 13 '25 13:08 gburch

Here is a breakdown of the workflow before and after implementing this feature, using a practical example.

Scenario: Your team has a standard way to create new React components. The process involves creating three files: a component file (.tsx), a test file (.spec.tsx), and a Storybook file (.stories.tsx).

Before: Disconnected and Repetitive Workflow

In the old workflow, user-facing commands and agent capabilities were entirely separate, forcing you to duplicate the same logic in two different places.

1. For the User: Create a Slash Command

To make this easy for developers, you create a project-level slash command: .claude/commands/new-component.md.

The user can simply type: > /new-component UserProfile

The new-component.md file contains a detailed prompt that tells Claude how to perform the scaffolding task:

Create a new React component named $ARGUMENTS.

Follow these steps precisely:
1.  **Create the Component File**: Create a file at `src/components/$ARGUMENTS/$ARGUMENTS.tsx`. It should be a basic functional component.
2.  **Create the Test File**: Create a file at `src/components/$ARGUMENTS/$ARGUMENTS.spec.tsx`. Include a simple test that checks if the component renders without crashing.
3.  **Create the Storybook File**: Create a file at `src/components/$ARGUMENTS/$ARGUMENTS.stories.tsx`. Include a default story for the component.

This works great for manual, user-driven actions.

2. For the AI Agent: Duplicate the Logic

Now, you want to create a subagent called feature-builder-agent that can automatically build out features, including creating new components.

The Problem: The subagent cannot use the /new-component command. It's not a "tool." To give the agent this skill, you must copy and paste the entire prompt from new-component.md into the subagent's system prompt.

The agent's definition file, .claude/agents/feature-builder-agent.md, would look like this:

---
name: feature-builder-agent
description: An agent that can build new features.
tools: Read, Write, Edit, Bash
---

You are an expert React developer who builds new features.

When asked to create a new component, you must follow these steps precisely:
1.  **Create the Component File**: Create a file at `src/components/COMPONENT_NAME/COMPONENT_NAME.tsx`. It should be a basic functional component.
2.  **Create the Test File**: Create a file at `src/components/COMPONENT_NAME/COMPONENT_NAME.spec.tsx`. Include a simple test that checks if the component renders without crashing.
3.  **Create the Storybook File**: Create a file at `src/components/COMPONENT_NAME/COMPONENT_NAME.stories.tsx`. Include a default story for the component.

(...other instructions for the agent...)

The developer would then invoke it like this: > use the feature-builder-agent to create a new UserProfile component

Pain Points of the "Before" Workflow

Logic Duplication: The component creation instructions exist in two separate files (new-component.md and feature-builder-agent.md).
Maintenance Nightmare: If your team's component standard changes (e.g., you switch to a new testing library), you must remember to update the logic in both files. Forgetting one leads to inconsistent behavior.
Lack of Modularity: The agent's skills are hardcoded in a monolithic system prompt. It's not easy to add or remove capabilities.

After: Modular and DRY (Don't Repeat Yourself) Workflow

With the new feature, the slash command itself becomes a reusable tool. The logic is defined only once.

1. For the User and Agent: Define the Tool Once

You create the same slash command as before: .claude/commands/new-component.md. This file is now the single source of truth for this workflow.

The user's workflow is unchanged and just as simple: > /new-component UserProfile

2. For the AI Agent: Grant Access to the Tool

Now, to give the feature-builder-agent the same skill, you no longer copy the prompt. You simply grant it permission to use the slash command as a tool.

The agent's definition file, .claude/agents/feature-builder-agent.md, is now much cleaner and more modular:

---
name: feature-builder-agent
description: An agent that can build new features by using our standard tools.
tools: Read, Write, Edit, Bash, slash__new-component
---

You are an expert React developer who builds new features. When you need to create a component, use the `slash__new-component` tool.

When the developer runs > use the feature-builder-agent to create a new UserProfile component, the subagent understands that it has a specialized tool, slash__new-component, which it will invoke with "UserProfile" as the argument.

Key Benefits of the "After" Workflow

Single Source of Truth: The component creation logic lives in exactly one place.
Effortless Maintenance: Update the new-component.md file, and both the user's manual command and the agent's programmatic tool are updated simultaneously.
True Modularity: Agents are built by composing a set of tools. Giving an agent a new, complex skill is as simple as adding one line to its tools list in the frontmatter.
Clear Separation of Concerns: Slash command files define what a task does. Agent files define the agent's high-level goal and which tools it can use to achieve it.

Aug 14 '25 03:08 coygeek

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Dec 04 '25 10:12 github-actions[bot]

Auto-close bots are harmful to community contributions:

Auto-closing without proper resolution is disrespectful to the original reporter and anyone else who contributed to the report.
It just sweeps the issue under the carpet, blindly hoping that it will magically fix itself. (The fact that this can sometimes happen doesn't justify doing it in all the other cases.)
When issues or feature requests are marked as closed without resolution, then people are more likely to miss them, resulting in duplicate reports and consequently fragmented information.
People searching for ways to contribute are much more likely to miss closed issues too.
Long-standing bugs are less likely to get resolved. Here's an example of a success story when bugs were allowed to persist for a long time.