command-creator

Overview of command-creator skill

The command-creator skill is for people who want to turn a repeated Claude Code workflow into a reusable slash command instead of re-explaining the same steps every time. Its job is not just to draft a markdown file: it helps you choose the right command pattern, write instructions in an agent-executable style, and place the command in the right location for project-level or user-level reuse.

Who command-creator is best for

command-creator is best for developers, team leads, and Skill Authoring users who already know a workflow they repeat, such as CI fixing, PR submission, implementation planning, or review routines, and want that workflow callable with /command-name.

The real job-to-be-done

Most users do not need “a command file.” They need a command that another agent can run with less ambiguity, fewer follow-up questions, and more consistent outputs. The command-creator skill is useful because it focuses on command structure, execution clarity, and reusable workflow design rather than vague prompt writing.

What makes this different from a normal prompt

A normal prompt may produce a rough slash command quickly, but command-creator adds higher-value guidance around:

• choosing a workflow pattern
• writing imperative, tool-friendly instructions
• defining arguments and expected outputs
• deciding whether the command belongs in .claude/commands/ or ~/.claude/commands/
• avoiding common command-writing mistakes that hurt autonomous execution

When command-creator is a strong fit

Use command-creator when you say things like:

• “I keep doing this task; make it a slash command.”
• “Turn this workflow into /something.”
• “Document this multi-step process so Claude Code can run it consistently.”
• “Create a project-specific command for this repo.”
• “Create a global command I can reuse across projects.”

When it is not the right tool

Skip command-creator if you only need a one-off answer, a plain prompt with no reuse, or automation that depends more on external scripting than on a markdown command definition. It is strongest when the workflow can be expressed clearly as a repeatable sequence of analysis, actions, and reporting.

How to Use command-creator skill

Install context for command-creator

The repository is softaworks/agent-toolkit, and the skill lives at skills/command-creator. If you install skills from that toolkit, the common pattern is:

npx skills add softaworks/agent-toolkit --skill command-creator

If your environment uses a different skill loader, use the repository path above as the source of truth.

What command-creator helps you produce

The output is a Claude Code slash command: a markdown file stored in either:

• .claude/commands/ for project-specific commands
• ~/.claude/commands/ for global commands

That file is later invoked as /command-name inside Claude Code.

Read these files first before using the skill

If you want the fastest path to good results, read the repository in this order:

1. SKILL.md for the intended trigger and scope
2. references/patterns.md to choose the right command shape
3. references/best-practices.md for writing style and structure
4. references/examples.md to see full commands that already work
5. README.md if you want broader orientation

This reading order matters because most adoption blockers are not installation issues; they are design issues like using the wrong pattern or writing instructions too vaguely.

Start with the workflow, not the command name

The best command-creator usage starts from a repeated task, not from branding. Before prompting the skill, write down:

• the trigger: what problem starts the workflow
• the inputs: arguments, files, or repo state needed
• the sequence: what should happen in order
• the stop condition: what counts as success
• the report: what the command should tell the user at the end

That gives the skill enough structure to choose a command pattern instead of inventing one loosely.

Turn a rough request into a strong prompt

Weak input:

• “Make me a slash command for PRs.”

Stronger input:

• “Create a Claude Code slash command named submit-stack for this repo. It should check for .PLAN.md first, fall back to git diff if absent, generate a concise commit message, run Graphite restack and submit commands, then report PR URLs. This should be project-level, live in .claude/commands/, and accept an optional description argument.”

The stronger version improves output because it specifies context checks, fallback logic, tool actions, destination, and arguments.

Choose the right command pattern early

The references make clear that command quality improves when you pick a pattern before drafting. Common patterns include:

• Analyze → Act → Report for multi-step workflow automation
• Run → Parse → Fix → Repeat for iterative fixing tasks like CI or lint
• delegation-oriented flows when the command should route work to specialized agents
• simpler execution patterns for direct, low-branching tasks

If your command keeps failing in practice, the problem is often pattern mismatch, not wording.

Write instructions in agent-executable form

A key lesson from references/best-practices.md is that commands should use imperative, concrete instructions, not second-person advice.

Prefer:

• “Run git status to inspect modified files.”
• “Check whether .PLAN.md exists in the repository root.”
• “Report PR URLs after submission.”

Avoid:

• “You should inspect the repo.”
• “You may want to look at git status.”
• “Try to submit the PRs.”

This is one of the highest-impact details in the command-creator guide because it directly affects whether the resulting command can run autonomously.

Include expected outcomes and decision points

Good commands do more than list steps. They say what should happen and how to branch.

Useful additions:

• what file to check first
• what to do if that file is missing
• what successful output looks like
• when to stop and ask the user
• what to report back at the end

This reduces guesswork during execution and makes the command more reusable across conversations.

Decide project-level vs global placement

For command-creator for Skill Authoring, command placement is a practical decision:

• Use .claude/commands/ when the workflow depends on repo conventions, repo tools, or project files.
• Use ~/.claude/commands/ when the workflow is personally reusable across many repos.

A project-specific command is usually the safer default because most useful workflows depend on local conventions.

Build arguments around real variation

Add arguments only when they change execution meaningfully. Good candidates are:

• a user-provided description
• a target file or path
• a mode like quick vs full
• an environment or scope selector

Do not add parameters just because commands “should be flexible.” Too many optional arguments can make the command less reliable and harder for an agent to interpret.

Practical workflow for first-time use

A practical command-creator install and usage path looks like this:

1. Install or load the skill from softaworks/agent-toolkit
2. Read SKILL.md and references/patterns.md
3. Pick one repeated workflow only
4. Describe the workflow with inputs, branching, and expected output
5. Ask command-creator to draft the slash command
6. Compare the draft against references/best-practices.md
7. Test the command in Claude Code on a realistic case
8. Tighten any vague steps, missing preconditions, or weak reporting

Repository signals that matter most

The highest-value files here are the references, not helper scripts. This skill ships with pattern, example, and best-practice documents, which is useful because command authoring fails more often from unclear design than from missing code. That makes this skill especially helpful for people designing reusable markdown commands rather than tool-heavy automations.

command-creator skill FAQ

Is command-creator worth using if I can already write prompts?

Yes, if your goal is reusable command authoring rather than one-off prompting. command-creator gives you structure for slash commands, especially around command patterns, imperative writing, and expected outputs. That usually produces a command another agent can execute more reliably than a quickly improvised prompt.

Is command-creator beginner-friendly?

Mostly yes, if you already understand the workflow you want to automate. You do not need to know every slash command convention up front, but you will get much better results if you can clearly explain the task, inputs, and success criteria.

What does command-creator not do for me?

It does not magically infer a messy workflow from a vague sentence. If your process has hidden assumptions, missing tool names, or unclear stop conditions, the generated command will inherit those gaps.

How is it different from copying an example command?

Examples help, but command-creator usage is stronger when your workflow needs adaptation. The included examples show working patterns, while the skill helps you map your specific process onto those patterns instead of blindly cloning one example and hoping it fits.

Should I use command-creator for simple tasks?

Only if the task is repeated often enough to justify a slash command. For a tiny one-off action, plain prompting is faster. For a recurring team or repo workflow, command-creator skill becomes more valuable.

Does command-creator help with project-specific commands?

Yes. In fact, that is one of its best use cases. The skill is well suited to commands that depend on repository files, local conventions, or a standard sequence of checks and actions.

When should I not install command-creator?

Do not prioritize command-creator install if your real need is external automation code, shell scripting, or CI configuration rather than a Claude Code slash command. This skill is about authoring the command definition, not replacing every other automation layer.

How to Improve command-creator skill

Give command-creator better source material

The fastest way to improve command-creator output is to provide the workflow in a structured form:

• goal
• trigger
• required tools
• file checks
• branching logic
• final deliverable

Even a short bullet list beats a vague sentence like “make a command for releases.”

Show repository-specific context

If the command is project-level, include repo details such as:

• important files the command should read first
• standard commands like make test or pnpm lint
• naming conventions
• commit or PR norms
• tools such as Graphite, pytest, or custom scripts

This helps the skill produce a command that fits the repo instead of a generic template.

Name the failure modes up front

Tell command-creator what commonly goes wrong:

• missing context files
• dirty working tree
• flaky tests
• partial output from tools
• cases where the command should stop rather than continue

This leads to better branching and safer instructions.

Ask for explicit preconditions and outputs

One common failure mode is a command that says what to do but not what success looks like. Ask the skill to include:

• preflight checks
• expected outputs after each major step
• final reporting format
• escalation points when the workflow cannot continue safely

That usually makes the command more executable on the first try.

Tighten vague language after the first draft

If the first result uses words like “check,” “review,” or “fix” without enough detail, revise them into concrete actions:

• what command should run
• what file should be read
• what condition should be verified
• what output should be returned

This is one of the best ways to improve command-creator for Skill Authoring because ambiguity is the main reason slash commands underperform.

Reuse the bundled references strategically

Use each reference for a different improvement pass:

• references/patterns.md to correct the overall structure
• references/examples.md to compare your command against realistic working examples
• references/best-practices.md to tighten phrasing and execution detail

This is more effective than rereading SKILL.md repeatedly.

Test with a real invocation, not just a static read-through

A command that looks good in markdown can still fail during use. Test it with a real /command-name scenario using realistic arguments and repo state. Then fix:

• unclear assumptions
• missing file checks
• weak fallback logic
• poor reporting
• unnecessary optionality

Improve command scope before adding complexity

If your first command feels brittle, reduce scope before expanding features. A smaller command with one clear workflow usually outperforms a “smart” command trying to handle many edge cases. Once the base path is stable, add arguments or branches deliberately.

Use command-creator as a design aid, not a final authority

The best way to improve command-creator skill results is to treat the first draft as a design artifact. Review whether it matches how you actually work, then edit for your repo, tools, and constraints. The skill is strongest when it removes guesswork, not when it replaces judgment.