Create command
Skill richfrem/agent-plugins-skills/plugins/agent-scaffolders/skills/create-command
Scaffolds a new slash command in an existing plugin. NOT for creating event-driven hooks (use `create-hook`) and NOT for standard skills (use `create-skill`).From its SKILL.md
npx -y skills add richfrem/agent-plugins-skills --skill create-commandAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
12.3 KB, ~3.1k tokens by cl100k_base, as published. Nobody here has run it
Dependencies
This skill requires Python 3.8+ and standard library only. No external packages needed.
To install this skill's dependencies:
pip-compile ./requirements.in
pip install -r ./requirements.txt
See ../../requirements.txt for the dependency lockfile (currently empty — standard library only).
Slash Command Designer
Slash commands are reusable Markdown prompts that Claude executes when invoked with
/command-name. They provide consistency, efficiency, and shareability for common
workflows. Commands can be simple prompts or powerful multi-step workflows using dynamic
arguments, file references, bash execution, and integration with agents and skills.
Reference files for deep dives:
references/frontmatter-reference.md-- full list of all frontmatter fieldsreferences/interactive-commands.md-- AskUserQuestion, conditional logicreferences/advanced-workflows.md-- multi-step, multi-component patternsreferences/plugin-features-reference.md-- ${CLAUDE_PLUGIN_ROOT}, bash execution syntaxreferences/examples/simple-commands.md-- copy-ready simple command templatesreferences/examples/plugin-commands.md-- copy-ready plugin command templates
The Most Important Rule
Commands are instructions FOR Claude, not messages TO the user.
When /command-name is invoked, the command body becomes Claude's instructions. Write
what Claude should DO, not what the user will see.
# CORRECT -- tells Claude what to do:
Review this code for security vulnerabilities:
- SQL injection
- XSS attacks
- Authentication bypass
Provide specific line numbers and severity ratings.
# WRONG -- addresses the user, not Claude:
This command will review your code for security issues.
You will receive a report with vulnerability details.
Step 1: Understand the Use Case
Extract from context first. Ask only what is unclear.
Core questions:
-
What workflow should this automate? One command, one purpose.
-
Which command type fits?
- Simple: Static prompt, no arguments, no bash -- just a great reusable instruction
- Dynamic: Uses
$ARGUMENTS,$1/$2positional args, or file references (@$1) - Bash-powered: Inline
!`` ```` bash commands to gather dynamic context before Claude runs - Multi-component: Coordinates skills, agents, and scripts in a workflow
-
Where should it live?
.claude/skills/<name>/SKILL.md-- recommended for new work (supports supporting files, cross-agent portability, inline hooks). The directory name becomes the slash command..claude/commands/<name>.md-- flat file, still works, simpler but no supporting files. Note: confirmed macOS discovery bug (GitHub #13906) with.claude/commands/in some Claude Code versions. Preferskills/or a local plugin for reliability.~/.claude/skills/<name>/SKILL.md-- personal commands available in all projectsplugin-name/skills/<name>/SKILL.md-- distributed with plugin, namespaced as/plugin-name:<name>-- always use the full namespaced form in agent files
-
Does it need arguments? Use
$ARGUMENTS(all as one string) or$1,$2(positional). -
Does it need to read files? Use
@file-pathor@$1for dynamic file args. -
Tool restrictions needed? Set
allowed-toolsto restrict scope (e.g.Bash(git:*)notBash(*)).
Step 2: Choose the Right Pattern
Pattern A: Simple static command
---
description: Review code for security vulnerabilities
allowed-tools: Read, Grep
---
Review the current file for security vulnerabilities including:
- SQL injection risks
- XSS attack vectors
- Authentication bypass
- Insecure data handling
Provide specific line numbers and severity (critical/high/medium/low).
Pattern B: Dynamic arguments with $ARGUMENTS
---
description: Fix GitHub issue by number
argument-hint: [issue-number]
---
Fix issue #$ARGUMENTS following our coding standards and writing tests for all changes.
Pattern C: Positional arguments $1, $2
---
description: Review PR with priority and assignee
argument-hint: [pr-number] [priority] [assignee]
---
Review pull request #$1 with $2 priority.
After review, assign to $3 for follow-up action.
Pattern D: File reference
---
description: Generate documentation for a source file
argument-hint: [source-file]
---
Generate comprehensive documentation for @$1 including:
- Function/class descriptions and parameter docs
- Return value descriptions with types
- Usage examples with edge cases
Pattern E: Bash context injection
---
description: Review code changes
allowed-tools: Read, Bash(git:*)
---
Files changed: !`git diff --name-only HEAD~1`
Current branch: !`git branch --show-current`
Review each changed file for:
1. Code quality and style consistency
2. Potential bugs or regressions
3. Test coverage gaps
4. Documentation needs
Provide specific feedback per file.
Pattern F: Plugin command with ${CLAUDE_PLUGIN_ROOT}
---
description: Run plugin analyzer on target file
argument-hint: [file-path]
allowed-tools: Bash(node:*), Read
---
Run analysis: !`node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1`
Load rules: @${CLAUDE_PLUGIN_ROOT}/config/rules.json
Review results and report findings by severity.
Step 3: Scaffold and Write
Default scaffold: skills/ directory (recommended)
# Project command (as skill directory)
mkdir -p .claude/skills/<name>
touch .claude/skills/<name>/SKILL.md
# optionally: mkdir -p .claude/skills/<name>/evals
# optionally: touch .claude/skills/<name>/acceptance-criteria.md
# Personal command
mkdir -p ~/.claude/skills/<name>
touch ~/.claude/skills/<name>/SKILL.md
# Plugin command (namespaced as /plugin-name:<name>)
mkdir -p plugin-name/skills/<name>
touch plugin-name/skills/<name>/SKILL.md
Simple mode: flat .md file (still supported)
mkdir -p .claude/commands
touch .claude/commands/<name>.md
Use for one-liner prompts with no supporting files. For anything more complex, prefer
the skills/ directory so you can add references/, evals/, and inline hooks later.
YAML frontmatter complete reference
| Field | Purpose | Default | Example |
|---|---|---|---|
name | Required. Slash command name. Kebab-case. | — | name: deploy |
description | Text in /help. Hard limit 1024 chars. Keep under 150 words. | — | description: Deploy to target env. |
argument-hint | Autocomplete hint for arguments | — | argument-hint: "[env: dev|staging|prod]" |
allowed-tools | Restrict tool access (least privilege) | All | allowed-tools: Read(*), Bash(git *) |
disable-model-invocation | true = user-only, blocks auto-invoke | false | disable-model-invocation: true |
user-invocable | false = background knowledge, not user-typed | true | user-invocable: false |
model | Override model for this command | session default | model: claude-haiku-4-5-20251001 |
effort | Override effort level | medium | effort: low |
maxTokens | Cap token budget for this command | model default | maxTokens: 4096 |
hooks | Inline hooks scoped to this skill's lifetime | — | see create-hook |
isolation | Run in isolated git worktree | none | isolation: worktree |
No frontmatter is needed for the simplest commands -- omit the --- block entirely.
Argument handling rules
$ARGUMENTS-- all user-supplied text as one string (use for simple single-arg commands)$1,$2,$3-- positional (use when multiple distinct args needed)- Mix:
$1for first,$ARGUMENTSfor "everything after" - Always document with
argument-hintand handle the missing-arg case in the prompt
Bash inline execution syntax
!`command` -- executes, output injected before Claude processes
!`git diff HEAD~1` -- inject git diff
!`cat package.json` -- inject file contents (alternative to @syntax)
Use allowed-tools: Bash(git:*) to scope permissions. See references/plugin-features-reference.md
for full bash execution details and edge cases.
File references
@path/to/file.md -- static file reference, Claude reads before processing
@$1 -- dynamic file reference using first argument
@${CLAUDE_PLUGIN_ROOT}/templates/report.md -- plugin-relative file
Argument validation pattern
---
argument-hint: [environment]
---
Validate: !`echo "$1" | grep -E "^(dev|staging|prod)$" && echo "valid" || echo "invalid"`
If $1 is a valid environment (dev/staging/prod):
Deploy to $1 environment
Otherwise:
Explain valid environments and show usage: /deploy [dev|staging|prod]
Multi-component workflow pattern (agent + skill + script)
---
description: Comprehensive review workflow
argument-hint: [file]
allowed-tools: Bash(node:*), Read
---
Target: @$1
Phase 1 - Static analysis:
!`node ${CLAUDE_PLUGIN_ROOT}/scripts/lint.js $1`
Phase 2 - Deep review:
Launch the code-reviewer agent for detailed analysis.
Phase 3 - Standards check:
Use the coding-standards skill for validation.
Phase 4 - Report:
Template: @${CLAUDE_PLUGIN_ROOT}/templates/review.md
Compile findings following the template structure.
Step 4: Organize Commands
Naming convention
- Use verb-noun:
review-pr,fix-issue,deploy-staging - Avoid generics:
test,run,build(conflict-prone) - Hyphens for multi-word, no underscores
Namespacing with subdirectories
commands/
├── ci/
│ ├── build.md # /build (project:ci)
│ ├── test.md # /test (project:ci)
│ └── lint.md
├── git/
│ ├── commit.md
│ └── review-pr.md
└── docs/
└── generate.md
Use subdirectories when you have 15+ commands or clear logical categories.
Inline documentation
<!--
Usage: /deploy [staging|production] [version]
Requires: AWS credentials configured
Example: /deploy staging v1.2.3
-->
Deploy application to $1 environment using version $2...
Step 5: Validate
Checklist:
- Command body written as instructions TO Claude (not messages to user)
-
namefield present (required — without it the command silently fails to register) -
descriptionclear, under 150 words, hard limit 1024 chars -
argument-hintdocuments all arguments -
allowed-toolsrestricts to only what's needed -
$ARGUMENTSused for single-arg commands;$1/$2for multiple distinct args -
@filereferences use valid paths - Bash commands scoped:
Bash(git *)notBash(*)where possible - Plugin commands use
${CLAUDE_PLUGIN_ROOT}not hardcoded paths - Plugin commands referenced from agents/skills use full namespaced form:
/plugin-name:command - Command is in
skills/directory (preferred) orcommands/(flat, simple only)
Test the command:
/command-name arg1 arg2
If the command isn't showing up, work through this in order:
[ ] 1. YAML syntax: open SKILL.md, check frontmatter manually.
`---` markers must be on their own lines, no leading spaces.
[ ] 2. name field: must be present.
[ ] 3. Plugin namespace: if installed as plugin, use /plugin-name:command not /command.
[ ] 4. Scope: is it in ~/.claude/skills/ (always) or .claude/skills/ (this project only)?
[ ] 5. Budget: run /context -- are skills excluded? Fix: SLASH_COMMAND_TOOL_CHAR_BUDGET=200000
[ ] 6. Platform: macOS + .claude/commands/ has a known bug (#13906). Migrate to skills/.
[ ] 7. Reload: run /reload-plugins after editing.
[ ] 8. Health: run /doctor for failures.
[ ] 9. Verify: run /help -- does the command appear with correct namespace?
Run audit:
audit-plugin -- validates full plugin structure including commands
Next Actions
- Refine: Run
continuous-skill-optimizerto benchmark trigger optimization - Extend: Add interactivity with
AskUserQuestion-- seereferences/interactive-commands.md - Distribute: Add to a plugin for team sharing -- see
references/examples/plugin-commands.md - Audit: Run
audit-pluginto validate structure
What ships with it: 86 files
7.9 KB alongside SKILL.md
assets/
evals/
- evals.json880 B
- results.tsv417 B
references/
- acceptance-criteria.md42 B
- advanced-workflows.md41 B
- fallback-tree.md36 B
- frontmatter-reference.md44 B
- hitl-interaction-design.md46 B
- interactive-commands.md43 B
- pattern-decision-matrix.md46 B
- patterns/action-forcing-output-with-deadline-attribution.md82 B
- patterns/adversarial-objectivity-constraint.md69 B
- patterns/anti-pattern-vaccination.md59 B
- patterns/anti-symptom-triage.md54 B
- patterns/artifact-embedded-execution-audit-trail.md74 B
- patterns/artifact-generation-xss-compliance-gate.md74 B
- patterns/artifact-lifecycle.md53 B
- patterns/artifact-state-interrogative-routing.md71 B
- patterns/asynchronous-benchmark-metric-capture.md72 B
- patterns/audience-segmented-information-filtering.md75 B
- patterns/category-calibrated-benchmark-anchoring.md74 B
- patterns/category-semantic-deferred-tool-binding.md74 B
- patterns/chained-command-invocation.md61 B
- patterns/chained-commands.md51 B
- patterns/client-side-compute-sandbox-constraint.md73 B
- patterns/complexity-tiered-output.md59 B
- patterns/conditional-step-inclusion.md61 B
- patterns/connector-placeholders.md57 B
- patterns/cyclical-state-propagation-contract.md70 B
- patterns/delegated-constraint-verification-loop.md73 B
- patterns/dual-mode-degradation.md56 B
- patterns/dual-mode-meta-skill.md55 B
- patterns/dual-register-communication-enforcement.md74 B
- patterns/dynamic-specification-fetching.md65 B
- acceptance-criteria.md464 B
- fallback-tree.md1.4 KB
46 more files not listed here. See all 86 in the repository.