--- title: Let Claude write your Claude Code commands author: FractionalSkill category: Claude Code ---

Let Claude write your Claude Code commands

Most operators spend real time crafting custom commands from scratch. They stare at a blank file, struggle to phrase the prompt precisely, and ship something mediocre. There is a better approach: teach Claude Code to generate its own commands.

This is called a meta-command. One command whose sole job is to produce new commands. It sounds recursive, but the mechanics are straightforward and the payoff compounds the longer you use Claude Code.

What a meta-command actually does

Custom commands in Claude Code live in a .claude/commands/ folder inside your project. Each command is a Markdown file. When you type /your-command-name in a session, Claude reads that file and uses its contents as the prompt.

The meta-command pattern works like this: you create a single command file called create-command.md. When you run /create-command followed by a plain-English description, Claude reads your description, then writes and saves a new command file to the right location with the right format. You review it, tweak it if needed, and it's ready to deploy.

.claude/
  commands/
    create-command.md      ← the meta-command
    open-pr.md             ← generated by the meta-command
    weekly-status.md       ← generated by the meta-command
    client-brief.md        ← generated by the meta-command

You're not replacing your judgment. You're skipping the blank-page problem.

How to build the create-command file

Create the file at .claude/commands/create-command.md. The file needs two things: a way to accept your plain-English description as input, and clear instructions that tell Claude how to format the command it creates.

Here is the structure that works:

# create-command

You are given the following context: $ARGUMENTS

## Instructions

Your task is to create a new custom command for use with Claude Code.

Create the file at the following path:
.claude/commands/[command-name].md

Format the command as follows:

# [command-name]

You are given the following context: $ARGUMENTS

[command instructions here]

The $ARGUMENTS variable is what gets replaced when you type your description after the slash command. Claude receives your full description as context, then writes a complete, structured command file at the correct path.

A few things to note about this structure:

• The file path matters. Claude needs the exact path so the new command lands in the right folder automatically.
• The format block tells Claude what to produce. The triple-backtick section is a template. Claude fills in the command name and writes the instructions based on what you described.
• Every generated command inherits $ARGUMENTS. This means commands Claude creates will also accept arguments, making them reusable across different inputs.

> After creating or editing any command file, restart your Claude Code session. Commands load at session start. The new command won't appear until you do /exit and reopen.

Running it for the first time

Start a new Claude Code session after saving your create-command.md file. Type /create-command and hit Tab. Your cursor moves to the argument position. Describe what you need in plain English.

You: /create-command open a new pull request on GitHub, including a 
     summary of changes and a link to the relevant issue

Claude reads your description, writes the command file, and asks permission to create it. Review the proposed file path and content before approving. If the naming convention is off (Claude might generate open-pr when you prefer open_pr), you can reject and add a naming example to your meta-command's instructions.

Once approved, the file appears in .claude/commands/. Restart your session and the new command is live.

You: /open-pr This fixes the duplicate invoice bug. Related to issue #47.

Where this fits in a multi-client workflow

The real value shows up when you're managing three or four client engagements at once. Every engagement has repeatable tasks: weekly status updates, competitive snapshots, kickoff briefs, retro summaries. Each one is a candidate for a command.

Without a meta-command, creating those commands is friction. With it, the process is:

1. Finish a task in Claude Code 2. Recognize you'll do it again for another client 3. Run /create-command [describe what you just did, generalized] 4. Review and approve the generated file 5. That workflow is now reusable across every engagement

The gap widens for complex commands because you can reference your current session. Tell Claude to "look at what we just did in this conversation and turn it into a reusable command." It reads the history and builds from what actually happened, not from a description you wrote from memory.

> Reference the session, not your memory. When creating a command for a workflow you just completed, tell Claude to pull from the conversation history. The prompt it produces will be more accurate than anything you'd write from scratch.

What to put in your meta-command instructions

The default template above gets you started. As you build more commands, you'll want to add style preferences so generated commands match how you work.

Common additions to the meta-command instructions:

• Naming convention. "Use kebab-case for all command names" or "Use underscore-separated names."
• Example format. Paste one of your best existing commands into the meta-command as a reference. Claude will match the structure.
• Default sections. If every command you write includes a "Context" section and a "Steps" section, document that pattern. Claude will reproduce it.
• Scope note. "Commands should be written for a professional services context. Assume the reader manages multiple client engagements."

The more specific your instructions, the less editing generated commands need. Most operators find they iterate on the meta-command two or three times in the first week, then it stays stable.

---

The constraint on building a command library has never been knowing what commands to make. You already know which tasks repeat. The constraint is the time cost of writing good prompts. A meta-command removes that friction and makes your command library grow at the pace of your work, not the pace of your writing sessions.