How to Build Reusable Slash Commands and Skills for Your Team's Agent

Right now, your best workflow lives in your head. The exact way you brief the agent to write a release note, triage feedback, or draft a test plan. You retype it from memory every time, slightly differently each time, and the day you're on PTO nobody else can run it.

That's a workflow trapped in a person. The fix is to package it once — as a reusable command or skill — so it becomes a thing anyone on the team can invoke the same way, every time. By the end of this you'll have built your first one.

This is the oldest good idea in computing

You're not learning something new so much as applying three ideas that have been around forever.

The first is the Unix philosophy from 1978: build small tools that each do one thing well and compose cleanly. A good command is exactly that — one sharp job, reusable, snapping together with the others. The second is DRY — don't repeat yourself — software's oldest hygiene rule. Retyping the same briefing fifteen times is a copy-paste bug waiting to drift. The third is Atul Gawande's Checklist Manifesto: even brilliant surgeons and pilots make fewer fatal mistakes when the hard-won steps are written down instead of trusted to memory.

A reusable command is all three at once — a small composable tool, written once, that turns your best practice into a checklist the agent runs the same way every time. The Claude Code team leans on this hard, with shared commands and subagents doing the heavy lifting. Ops teams have called this a "runbook" for decades. Same instinct, new executor.

Step 1: Find the workflow you repeat

Don't invent one. Look at your last two weeks and find the thing you've briefed an agent to do more than three times. The repetition is the signal. Common ones:

• "Turn these merged PRs into a customer-facing release note in our voice."
• "Take this raw feedback dump and tag each item by theme and severity."
• "Draft a test plan for this feature, covering the failure modes."

Pick the most-repeated one. That's where packaging pays back fastest.

Step 2: Write down what you actually do, in order

Open a doc and write the workflow as explicit steps — the way you'd brief a sharp new hire who's never seen it. Be specific about the parts you do on autopilot:

• What input it expects.
• The steps, in order.
• The format and tone of the output.
• The rules and the don'ts. ("Never invent a feature that isn't in the input. Group by theme, not by date.")

This step feels slow, and it's the whole game. A vague command produces vague results forever. The explicitness you spend once is the quality you collect on every single run after.

Step 3: Parameterize the part that changes

A command is reusable because the workflow is fixed and only the input varies. So mark the variable — the PR list, the feedback file, the feature name — and keep everything else (steps, format, rules) constant inside the command.

This is the line between a one-off prompt and a tool. The one-off bakes today's specifics into the instructions. The command separates the stable recipe from the changing ingredients.

Step 4: Save it where your agent looks

Every agent platform has a home for this — a commands folder, a skills directory, a config file. Save your instructions there with a clear name and a one-line description of when to use it. The description matters more than people expect: it's how both your teammates and the agent decide when this command applies.

Keep names obvious. /release-note and /triage-feedback beat clever names nobody can remember under deadline.

Step 5: Test it on a real case, then harden it

Run it on a real input and read the output like a critic. It won't be perfect the first time. When it gets something wrong, don't re-explain in chat — go fix the instructions so it never makes that mistake again. That's the loop that makes a command compound instead of plateau.

It's the same instinct as building an eval: the command isn't done when it works once. It's done when it survives the messy cases too.

---

The artifact: a command your whole team can run

The deliverable is one saved command that turns a workflow you used to retype into something anyone invokes by name. So share it. The moment a teammate runs your /triage-feedback and gets your-quality output without ever learning your method, you've turned a personal skill into team infrastructure.

Do this for your top three repeated workflows and you've quietly built a small operating system for how your team works with agents. That's the real prize — not the minutes saved on one task, but your best practices becoming the default instead of the exception that left when you did.