| name | custom-command-creator |
| description | This skill must be used when users want to create custom slash commands. Activates with phrases like "create a command", "make a slash command", "add custom command", "create command for", or "automate with a command". |
Custom Command Creator
This skill guides the creation of custom Amp commands accessible via the Command Palette (Cmd/Alt-Shift-A in VS Code or Ctrl-O in CLI).
What Custom Commands Do
Custom commands append their output to the prompt input when invoked. They provide reusable prompts and automated workflows:
- Markdown commands (.md files) — Static prompt templates inserted directly
- Executable commands — Scripts that run and output dynamic content (can accept arguments)
Command Locations
Commands are discovered from various locations:
- Workspace-local:
.agents/commands/in the current workspace - Global:
~/.config/amp/commands(or$XDG_CONFIG_HOME/amp/commandsif set) - Claude Code-compatible workspace:
.claude/skills/ - Claude Code-compatible global:
~/.claude/skills/
Choose a location based on whether it is specific to the workspace, or would apply across workspaces. Only use the Claude code-compatible locations if the user specifically indicates they want it to work for all agents, not just Amp.
The command name is derived from the filename (without extension).
Command Types
Type 1: Markdown Commands
Static prompt templates that insert their contents directly.
When to use:
- Consistent prompts reused across sessions
- System prompts, personas, or instruction sets
- Review templates with fixed structure
Structure:
# Command Title
## SYSTEM (optional)
System-level instructions for Claude's behavior.
## ASSISTANT RULES (optional)
Specific rules for how Claude should respond.
## OUTPUT FORMAT (optional)
Expected structure of Claude's response.
[Main prompt content...]
Type 2: Executable Commands
Scripts that generate dynamic prompts based on context, arguments, or external data.
When to use:
- Commands that need runtime data (API calls, git state, file contents)
- Commands accepting user arguments
- Integration with external tools (Linear, GitHub, Jira)
Requirements:
- Must be executable (chmod +x) OR have shebang on first line
- Output goes to stdout (combined with stderr, max 50k chars)
- Can accept arguments passed at invocation
Shebang examples:
#!/bin/bash
#!/usr/bin/env python3
#!/usr/bin/env node
Creation Process
Step 1: Determine Command Type
Ask clarifying questions:
- "Should this command be static (same every time) or dynamic (changes based on context)?"
- "Does it need to accept arguments?"
- "Does it need to fetch data from external APIs or tools?"
Decision matrix:
| Need | Type |
|---|---|
| Static prompt | Markdown |
| Accepts arguments | Executable |
| Fetches external data | Executable |
| Uses git/file state | Executable |
Step 2: Determine Scope
- Workspace-local (
.agents/commands/) — Project-specific commands - Global (
~/.config/amp/commands) — Commands available everywhere
Step 3: Create the Command
For Markdown Commands
- Create the file at the appropriate location
- Write clear, actionable instructions
- Use sections (SYSTEM, ASSISTANT RULES, OUTPUT FORMAT) for complex prompts
For Executable Commands
- Create the script with proper shebang
- Handle arguments via
$1,$2, etc. (bash) orsys.argv(Python) - Output the prompt to stdout
- Make executable:
chmod +x <command-file>
Step 4: Test the Command
Instruct the user to:
- Open Command Palette (Cmd/Alt-Shift-A or Ctrl-O)
- Find and invoke the command
- Verify the output appears in prompt input
Best Practices
Markdown Commands
- Use clear section headers for organization
- Include examples of expected output format
- Keep system instructions concise but complete
- Use fenced code blocks for structured output examples
Executable Commands
- Always validate required arguments exist
- Provide helpful usage messages for missing args
- Handle API errors gracefully with meaningful messages
- Use environment variables for secrets (never hardcode)
- Load .env files from project root when needed
- Exit with non-zero code on errors
General
- Name commands descriptively:
pr-review,work-on-issue,daily-standup - Document any required setup (API keys, dependencies)
- Keep prompts focused on a single workflow
Helper Script
To initialize a new command with boilerplate, use:
scripts/init_command.py <command-name> --type <markdown|bash|python> [--scope <local|global>]
See references/command-examples.md for complete working examples including:
- PR review template (Markdown)
- Linear issue integration (Bash executable)