How to build Claude Code slash commands for PM work

Which prompt deserves to become a command?

The one you have pasted three times and edited slightly each time. Not because retyping is slow, but because the edits are where the quality drifts. The version of your weekly update prompt that said "name every slipped date explicitly" existed in week one and quietly disappeared by week five, and nobody noticed until a stakeholder asked why a date had moved twice without being mentioned.

A slash command fixes the drift, not the typing. Everything you decided about how this artifact should read gets written down once and applied every time.

For the prompting craft underneath, the glossary entry on prompt engineering covers the patterns. This page is about making one of them permanent.

Where does the file go, and what does it become?

A slash command is a single markdown file, and its filename is the command name. A file at .claude/commands/standup.md inside a repository gives everyone who clones it /standup. The same file at ~/.claude/commands/standup.md gives it to you in every project on your machine.

Subdirectories become namespaces, with the slash replaced by a colon. .claude/commands/launch/checklist.md becomes /launch:checklist, which is how a team ends up with a coherent /launch: family rather than nine commands competing for short names.

What does a real product command look like?

Here is the weekly stakeholder update, written once.

---
description: Draft the weekly stakeholder update for one team. Use on Thursday, before the Friday send.
argument-hint: [team]
allowed-tools: Bash(git log:*) Read Grep
disable-model-invocation: true
---

## What shipped in the last seven days
!`git log --since="7 days ago" --oneline --no-merges`

## Current scope
@docs/product/this-quarter.md

Draft this week's update for the $1 team, using the two sections above.

Rules:
- Open with the one decision the reader has to make this week.
  If there is no decision, say that in the first line.
- Three bullets maximum under what shipped, written as outcomes,
  not as commit messages.
- Name every date that slipped, with its new date. Never write
  "slightly delayed" or "on track for soon".
- End with the open question you most need answered, and who owns it.
- Under 200 words.

The rules block is the whole point. That is the editorial standard your updates are supposed to meet, and previously it lived in your head on good weeks and nowhere on bad ones. The injected git log means the command arrives already holding the week's facts, so the drafting step is not also a remembering step.

Which arguments actually matter?

Most commands need one, and many need none. The test is whether the value genuinely changes between runs in a way the command cannot work out for itself.

Team name changes, so it is an argument. The date range does not really change, because it is always the last seven days, which means hardcoding it is more reliable than typing it. The output format never changes, so making it an argument would just be an invitation to break your own standard under time pressure.

A useful ordering when you are deciding:

• One argument for the thing that names the subject: a team, a feature, a file path.
• Zero arguments for anything the command can compute, such as a date window or the current branch.
• Nothing for the parts that define quality. A word cap or a required section belongs in the file, not in a flag you can drop when you are in a hurry.

Set argument-hint in the front matter so autocomplete shows what the command expects. It costs one line and removes the moment two weeks later where you cannot remember whether the team name comes first.

What does the injected context buy you?

Two things a plain prompt never has: freshness and honesty. Prefixing a backticked shell command with an exclamation mark runs it before the content reaches Claude, and the output replaces the placeholder, so the draft is written against what actually happened rather than what you remember. Referencing a file with an at sign pulls that file's content in the same way, which is how the current scope document ends up in front of the model without you pasting it.

There is a deliberate strictness here worth knowing: if an injected command fails, the whole invocation aborts rather than proceeding without that data. That is the right default. A stakeholder update generated from a git log that silently returned nothing would read exactly like a quiet week.

How do you test one before the team gets it?

Keep it personal first. Write the file in ~/.claude/commands/, run it for three or four real weeks, and only move it into .claude/commands/ in the repository once you have stopped editing it. A command that lands in version control on day one gets adopted before it is right, and the corrections then arrive as pull requests rather than as two seconds of editing.

While you iterate, watch two things. The allowed-tools list should be as narrow as the command actually needs, because the grant it gives skips the permission prompt for that turn; Bash(git log:*) is a different proposition from Bash. And keep injected commands fast. Each one runs under a two-minute timeout, and a command that reaches across the network to a slow dashboard turns a five-second draft into a coffee break. Appending a fallback so a non-zero exit does not abort the run is worth it for anything optional.

This is also the point where a command stops being a shortcut and becomes a step in a repeatable process, which the glossary entry on agentic workflows covers as a pattern rather than a file.

Should this be a command file or a skill folder?

Custom commands have been merged into skills, so a file at .claude/commands/standup.md and a folder at .claude/skills/standup/SKILL.md both produce /standup and work the same way. Pick by shape rather than by feature.

A single file is right when the instructions fit in one screen and there is nothing else to carry. A folder is right when the command needs reference material beside it, such as a list of how your company defines each guardrail metric, because supporting files in a skill folder stay out of context until they are actually needed. The glossary entry on agent skills covers that structure.

What a command will not fix

It will not improve a prompt that was never good. A command makes a prompt repeatable, which is excellent when the prompt encodes a real standard and unhelpful when it encodes a habit. Run the prompt by hand two or three times first, keep the edits that improved the output, and only then commit the file. Anything else is automating the version you happened to have on the day you got organised.

The second limit is ownership. A command committed to a repository is now a team artifact, and an editorial standard nobody revisits becomes last year's standard applied with total consistency. Put the review in the same place you review everything else, at the end of a quarter, and delete the commands nobody ran.

Builders Camp teaches the surrounding system rather than the syntax. Building with Claude Code, taught by Guilherme Salgueiro, covers skills, agents and memory alongside context architecture and automation pipelines, across 1 week with 2 live sessions and 9 microlessons. 10x Productivity with AI takes the same compounding idea outside the terminal, into writing, meeting notes, research synthesis and the safe usage habits that stop a personal system creating new risk, across 1 week with 2 live sessions and 8 microlessons. Automate Workflows with AI goes further again, into workflow mapping, human approvals and the monitoring that keeps an automation dependable.

The command is a decision you stop remaking

Count what you actually saved after a month and the keystrokes are trivial. What changed is that the hard editorial calls, the word cap, the refusal to write "slightly delayed", the requirement to name an owner, now happen on the weeks you are tired, travelling or three deadlines deep. That is the only week they ever mattered.

See the Building with Claude Code bootcamp for the systems layer, 10x Productivity with AI for the personal workflow version, or Automate Workflows with AI when the repetitive work you want to kill lives across several tools rather than in one file.