Your complete guide to slash commands Claude Code

If you keep pasting the same review checklist into Claude Code, turn it into a slash command. The current way to make one is a skill: a small SKILL.md file that Claude can load when it is relevant or run when you type its /name.

A slash command saves a reusable instruction, not the work itself. Claude still reads the arguments and project state, and tools still run with their normal permissions. That matters for a release check, a database task, or anything that could affect a customer.

This guide covers the skills-first setup, the frontmatter that changes a skill’s behavior, and an eesel CLI workflow for inspecting a support teammate.

What are slash commands in Claude Code?

Slash commands start with /. Built-in commands such as /help and /clear manage the Claude Code session. Your own command is usually a skill: a folder containing SKILL.md. Claude Code turns the folder name into the command name, so .claude/skills/review-pr/SKILL.md becomes /review-pr.

Skills are the preferred format for new work because a skill can include supporting files and Claude can load it automatically when its description fits the task. Existing Markdown files in .claude/commands/ and ~/.claude/commands/ still work, but they are legacy-compatible command files.

Commit a project skill when it represents a team workflow. Keep a personal preference, such as your own investigation checklist, in your home directory.

Create a useful skill

Start with one job and a clear end state. “Review a pull request and list evidence for each risk” is useful. “Make the code better” leaves too much for the command to guess.

Create .claude/skills/review-pr/SKILL.md:

---
description: Review a pull request or change set and report risks with file and line evidence.
argument-hint: [PR-number-or-scope]
---

Review $ARGUMENTS. Identify changed files, then report only actionable risks
with the relevant file and line. Do not change files unless the user asks.

Run /review-pr 482, or ask a question that matches the description. The description helps Claude decide whether the skill belongs in the task.

Pass arguments without an off-by-one error

$ARGUMENTS inserts everything after the command. For distinct inputs, $0 is the first argument, $1 the second, and so on. $ARGUMENTS[0] and $ARGUMENTS[1] are equivalent indexed forms.

---
description: Plan a narrow refactor for one component.
argument-hint: <component> <goal>
---

Inspect $0. Propose the smallest refactor that achieves $1.
List tests to run, but do not edit files.

/plan-refactor CheckoutForm "extract address validation" gives $0 the component and $1 the goal. Quote an argument when it contains spaces.

Frontmatter changes how a skill runs

Frontmatter is YAML between the opening --- markers. Use it to describe the skill, guide arguments, choose a model for one invocation, or pre-approve a narrow set of tools.

---
description: Check a specific source file for dependency risks.
argument-hint: <path>
model: sonnet
allowed-tools: Read, Grep
---

Inspect $0 for dependency and secret-handling risks. Report findings only.

model: sonnet selects the current Sonnet alias for this skill’s turn. It is not a durable model pin, and it is ignored if the organization does not make that model available. Do not copy retired full model IDs into a long-lived team skill.

allowed-tools pre-approves the listed tools only while this skill invocation runs. It does not overrule a matching ask or deny rule, and the grant is gone on the next user turn. Use permission settings when the team deliberately needs a broader session rule; keep deny rules for actions that should never run from that workspace.

Make commands safe to review

The best commands have a bounded job and a result someone can inspect. A change-review skill can collect the diff and name missing tests. A release-readiness skill can run documented checks and stop before deployment. A documentation skill can return suggested edits instead of silently changing published copy.

For credentials, customer data, or production systems, put the boundary in the skill: what it may inspect, which environment it may use, who performs a real write, and how the result is checked afterwards. A prompt does not grant access, override a deny rule, or make a risky action safe.

Use Claude Code to inspect an eesel teammate

The prompt tells Claude Code what to inspect. The eesel CLI supplies JSON-returning commands for the same teammate and workspace your support team uses in the dashboard.

The CLI is another way into the dashboard workspace, not a separate support agent. A person can use it from a terminal, a script can use its JSON output, and Claude Code, Codex, or Cursor can help with a defined check. A support lead can review the same configuration and activity in the dashboard.

Make a repeatable holiday-hours check

Consider a support team preparing for a fictional holiday closure. Its approved note says live staff return Tuesday, while self-service help remains available. The support lead wants to know whether the eesel teammate still promises a Monday human reply. A slash command can repeat this comparison for each upcoming closure without retyping the procedure.

The CLI needs Node.js 18.17 or newer. Log in and check the workspace first:

npx @eesel/cli login
npx @eesel/cli whoami

Stop if the workspace is wrong. EESEL_API_URL and EESEL_API_TOKEN, when set, override the saved login; never copy their values into a skill or report. Run npx @eesel/cli agents and select the actual intended ID. Then set the variable below, replacing its placeholder:

EESEL_HOURS_AGENT='selected-agent-id'
npx @eesel/cli status --agent "$EESEL_HOURS_AGENT"
npx @eesel/cli instructions --agent "$EESEL_HOURS_AGENT"
npx @eesel/cli automations --agent "$EESEL_HOURS_AGENT"

JSON is the default output, with lists printed one object per line. instructions can reveal a standing reply-time promise; automations shows configured event, scheduled, or webhook work that the owner may need to inspect. Neither tells you what every future customer reply will say.

Save this as .claude/skills/check-support-hours/SKILL.md:

---
description: Compare an approved closure note with eesel support configuration.
argument-hint: [approved-note-path] [eesel-agent-id]
disable-model-invocation: true
---
Read $0 as the approved closure note. After the operator confirms the
workspace with `npx @eesel/cli whoami`, inspect agent $1 explicitly.
Read status, instructions, and automations through eesel CLI.
Compare human reply-time promises with the note. Separate standing-rule
conflicts from automation details the owner must review. Cite the output
fields behind each finding. Do not edit, approve actions, or send chat.

Invoke /check-support-hours ./holiday-note.md selected-agent-id with your real values. The resulting report might flag a Monday promise for review, or say no such promise was present in the inspected output. It must not infer holiday handling from an automation's name alone. A support lead can review the same configuration in the dashboard.

Add a write only after the owner reviews it

If the owner approves adding that exact closure note as knowledge, check files upload --help, then preview the supported write:

npx @eesel/cli files upload ./holiday-note.md --agent "$EESEL_HOURS_AGENT" --dry-run

--dry-run prints the server call without sending it; it is not a test of holiday handling. After the owner approves it, the authorized operator can remove --dry-run, then read files ls --agent "$EESEL_HOURS_AGENT". An upload does not itself fix a conflicting standing instruction or automation. Propose those changes separately, inspect each command's --help, and read back any owner-approved change.

approvals --agent "$EESEL_HOURS_AGENT" shows held actions, not all possible permissions or proof that every automation is safe. Claude Code tool permissions and the eesel teammate's action settings are separate controls.

Test without confusing a test for production

Get approval for billed chat before evaluation. Authenticate to the approved test workspace, confirm it with whoami, and choose a separate non-production teammate with consequential actions Disabled. Set its actual ID below:

EESEL_TEST_AGENT='approved-non-production-agent-id'
npx @eesel/cli new --name "holiday-hours-check" --agent "$EESEL_TEST_AGENT"
npx @eesel/cli chat "Can a staff member reply on Monday?" --agent "$EESEL_TEST_AGENT"

Prepare the approved note and any approved test configuration on that test teammate first. Compare the reply with Tuesday staffing, then start another fresh conversation to ask whether self-service help remains available. Inspect activity and held approvals with the same explicit test target. A fresh chat separates earlier context; it does not make actions harmless. If the note is supplied directly in the prompt, the result tests that supplied context, not persistent source ingestion. Record source status and observed answer separately.

For CI, use securely supplied workspace credentials and an explicit target instead of relying on someone's saved default. For an MCP client, npx @eesel/cli mcp token --agent "$EESEL_HOURS_AGENT" prints connection details and a Claude Code setup line. Recheck the intended workspace before running it, review the connection's permissions, and keep the generated credentials private.

When a slash command is the wrong tool

A skill is useful for repeatable reasoning and short, safe checks. It is not a replacement for access design, a test plan, or an owner who understands the consequence of a write. Keep commands small enough that a teammate can read the instructions, inspect the output, and explain why the next action is safe.

Try eesel CLI for your next support-hours review

Create a reusable check for your team's next closure with eesel CLI. Claude Code follows the skill, the CLI returns configuration to compare, and the support owner reviews any change in the same workspace. Try eesel.