99 lines
2.7 KiB
Markdown
99 lines
2.7 KiB
Markdown
|
---
|
||
|
|
status: legacy
|
||
|
|
note: "For maintenance of existing commands only. Prefer skills for new functionality."
|
||
|
|
model_tier:
|
||
|
|
requirements: main
|
||
|
|
design: main
|
||
|
|
implementation: haiku
|
||
|
|
---
|
||
|
|
|
||
|
|
# Workflow: Create Command (LEGACY)
|
||
|
|
|
||
|
|
> **LEGACY WORKFLOW**: This workflow is for maintaining existing slash commands. For new functionality, prefer creating skills via the `create-skill` workflow instead.
|
||
|
|
|
||
|
|
## When to use
|
||
|
|
|
||
|
|
- Creating a new slash command (legacy maintenance only)
|
||
|
|
- Concept is clear and requirements understood
|
||
|
|
|
||
|
|
## Before you start
|
||
|
|
|
||
|
|
If concept unclear, brainstorm: `references/brainstorming/workflow.md`
|
||
|
|
|
||
|
|
## Pattern consideration
|
||
|
|
|
||
|
|
See `references/tool-patterns/catalog.md`.
|
||
|
|
|
||
|
|
| Question | If Yes |
|
||
|
|
|----------|--------|
|
||
|
|
| Is command concept unclear? | Brainstorm first |
|
||
|
|
| Will command modify files? | Include verification in instructions |
|
||
|
|
| Will command wrap a skill? | Skill handles patterns; command just invokes |
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Inputs
|
||
|
|
|
||
|
|
| Input | Example |
|
||
|
|
|-------|---------|
|
||
|
|
| `command_name` | `create-backup` (kebab-case) |
|
||
|
|
| `command_purpose` | "Create a backup of the current project" |
|
||
|
|
| `target_plugin_path` | `/home/user/my-plugin` |
|
||
|
|
|
||
|
|
## Subtasks
|
||
|
|
|
||
|
|
### 1. Understand requirements
|
||
|
|
|
||
|
|
Subagent: Main with user.
|
||
|
|
|
||
|
|
**Do:**
|
||
|
|
- What should this command do?
|
||
|
|
- What tools needed? (Read, Write, Bash, etc.)
|
||
|
|
- Wrap existing skill or standalone?
|
||
|
|
- What inputs from user?
|
||
|
|
|
||
|
|
### 2. Design the command
|
||
|
|
|
||
|
|
Subagent: Main.
|
||
|
|
|
||
|
|
**Do:**
|
||
|
|
- Determine command name (kebab-case, descriptive)
|
||
|
|
- Write one-line description
|
||
|
|
- List required tools
|
||
|
|
- Outline instructions
|
||
|
|
- If modifies files: include verification step
|
||
|
|
|
||
|
|
A command file has two parts: YAML frontmatter (`description`, optional
|
||
|
|
`allowed-tools`) and a body of plain instructions the model follows when the
|
||
|
|
command is invoked. See `${CLAUDE_PLUGIN_ROOT}/commands/cc-architect.md` for
|
||
|
|
a minimal real example, and `${CLAUDE_PLUGIN_ROOT}/templates/config-command.tmpl`
|
||
|
|
for one with input parsing.
|
||
|
|
|
||
|
|
### 3. Write the command file
|
||
|
|
|
||
|
|
Subagent: haiku.
|
||
|
|
Read: `${CLAUDE_PLUGIN_ROOT}/references/layout/descriptions.md`
|
||
|
|
|
||
|
|
**Do:**
|
||
|
|
1. Generate the description using the `generate-description` workflow
|
||
|
|
(`${CLAUDE_PLUGIN_ROOT}/workflows/generate-description.md`)
|
||
|
|
- Input: type=command, name, purpose, triggers
|
||
|
|
2. Create: `{target_plugin_path}/commands/{command_name}.md`
|
||
|
|
3. Write:
|
||
|
|
- Frontmatter (`description`, `allowed-tools` if the command needs
|
||
|
|
specific tools)
|
||
|
|
- Step-by-step instructions in the body
|
||
|
|
- Any user-request parsing guidance the command needs
|
||
|
|
|
||
|
|
## Validation
|
||
|
|
|
||
|
|
- [ ] Filename matches command name
|
||
|
|
- [ ] Description follows formula: "[Action verb] [what] when [trigger]"
|
||
|
|
- [ ] Only necessary tools listed
|
||
|
|
- [ ] Instructions clear and actionable
|
||
|
|
- [ ] Command does one thing well
|
||
|
|
|
||
|
|
## Output
|
||
|
|
|
||
|
|
`{target_plugin_path}/commands/{command_name}.md`
|