Claude Code 自訂 slash command 設計器：把重複貼的指令變成一鍵 /command

Design a reusable Claude Code slash command for the workflow described below, then create the file(s) and explain how to use it.

Workflow I keep repeating: {{WORKFLOW_DESCRIPTION}}
What I'd type to trigger it: /{{COMMAND_NAME}}
Arguments it should accept (if any): {{ARGUMENTS}}
Live context it should pull in automatically (shell commands whose output should be injected, e.g. `git diff HEAD`, `gh pr diff`): {{LIVE_CONTEXT}}
Tools it legitimately needs (e.g. Read, Grep, Bash(git *)): {{TOOLS_NEEDED}}

Follow these steps:

1. CHOOSE THE FORMAT (state your choice and why).
   - Simplest: a single markdown file at `.claude/commands/{{COMMAND_NAME}}.md`. The filename becomes `/{{COMMAND_NAME}}`. This still works and is the lightest option.
   - Recommended if it needs supporting files, a subagent, or auto-invocation: a skill at `.claude/skills/{{COMMAND_NAME}}/SKILL.md`. Same `/` invocation, but supports a directory of helper files.
   Default to the commands/ file unless the workflow clearly needs the extra features.

2. WRITE THE FRONTMATTER (YAML between --- markers). Use only fields that earn their place:
   - `description:` — one line, written so a teammate reading the `/` menu knows exactly what it does and when to use it.
   - `argument-hint:` — if it takes args, show them, e.g. `[issue-number]` or `[component] [from] [to]`.
   - `allowed-tools:` — list ONLY the tools this command should run without asking, scoped tightly. A lint command listing `Bash(npm run lint:*)` and nothing else cannot accidentally edit files. Do not grant broad Bash or Edit unless the workflow truly needs it.
   - `disable-model-invocation: true` — add this ONLY for commands with side effects you want to control timing on (deploy, commit, send-message), so Claude never fires them on its own.

3. WRITE THE BODY (the instructions). Make it a precise, ordered procedure, not prose. Rules:
   - Reference arguments with `$ARGUMENTS` (everything after the command) or by position with `$1`, `$2`, or `$ARGUMENTS[0]`. Wrap multi-word arg values in quotes when invoking.
   - To inject live state, put `` !`<shell command>` `` on its own line (or after whitespace). Claude Code runs the command BEFORE the model sees the file and replaces the line with the output — so the model receives real data (e.g. the actual diff), not the command. Use this for {{LIVE_CONTEXT}}. For multi-line, use a fenced ```! block.
   - Spell out acceptance criteria: what 'done' looks like, and what to do on the empty/error case (e.g. 'if the diff is empty, say there are no changes').
   - Keep it tight — once invoked, the body stays in context for the rest of the session, so every line is a recurring token cost.

4. CREATE the file(s) with the content you designed.

5. EXPLAIN: show me exactly what to type to run it (with a realistic example using my arguments), confirm whether teammates get it automatically (yes, if committed under .claude/), and note that project-level commands/skills require accepting the workspace-trust dialog before `allowed-tools` takes effect.

Constraints: do not invent frontmatter fields that don't exist. Do not put `allowed-tools` permissions broader than the workflow needs. If part of the workflow is genuinely risky (e.g. it deploys), call that out and set `disable-model-invocation: true`.

把方括號 [ ] 內的變數換成你的內容，丟進 Claude Code。

Design a reusable Claude Code slash command for the workflow described below, then create the file(s) and explain how to use it.

Workflow I keep repeating: {{WORKFLOW_DESCRIPTION}}
What I'd type to trigger it: /{{COMMAND_NAME}}
Arguments it should accept (if any): {{ARGUMENTS}}
Live context it should pull in automatically (shell commands whose output should be injected, e.g. `git diff HEAD`, `gh pr diff`): {{LIVE_CONTEXT}}
Tools it legitimately needs (e.g. Read, Grep, Bash(git *)): {{TOOLS_NEEDED}}

Follow these steps:

1. CHOOSE THE FORMAT (state your choice and why).
   - Simplest: a single markdown file at `.claude/commands/{{COMMAND_NAME}}.md`. The filename becomes `/{{COMMAND_NAME}}`. This still works and is the lightest option.
   - Recommended if it needs supporting files, a subagent, or auto-invocation: a skill at `.claude/skills/{{COMMAND_NAME}}/SKILL.md`. Same `/` invocation, but supports a directory of helper files.
   Default to the commands/ file unless the workflow clearly needs the extra features.

2. WRITE THE FRONTMATTER (YAML between --- markers). Use only fields that earn their place:
   - `description:` — one line, written so a teammate reading the `/` menu knows exactly what it does and when to use it.
   - `argument-hint:` — if it takes args, show them, e.g. `[issue-number]` or `[component] [from] [to]`.
   - `allowed-tools:` — list ONLY the tools this command should run without asking, scoped tightly. A lint command listing `Bash(npm run lint:*)` and nothing else cannot accidentally edit files. Do not grant broad Bash or Edit unless the workflow truly needs it.
   - `disable-model-invocation: true` — add this ONLY for commands with side effects you want to control timing on (deploy, commit, send-message), so Claude never fires them on its own.

3. WRITE THE BODY (the instructions). Make it a precise, ordered procedure, not prose. Rules:
   - Reference arguments with `$ARGUMENTS` (everything after the command) or by position with `$1`, `$2`, or `$ARGUMENTS[0]`. Wrap multi-word arg values in quotes when invoking.
   - To inject live state, put `` !`<shell command>` `` on its own line (or after whitespace). Claude Code runs the command BEFORE the model sees the file and replaces the line with the output — so the model receives real data (e.g. the actual diff), not the command. Use this for {{LIVE_CONTEXT}}. For multi-line, use a fenced ```! block.
   - Spell out acceptance criteria: what 'done' looks like, and what to do on the empty/error case (e.g. 'if the diff is empty, say there are no changes').
   - Keep it tight — once invoked, the body stays in context for the rest of the session, so every line is a recurring token cost.

4. CREATE the file(s) with the content you designed.

5. EXPLAIN: show me exactly what to type to run it (with a realistic example using my arguments), confirm whether teammates get it automatically (yes, if committed under .claude/), and note that project-level commands/skills require accepting the workspace-trust dialog before `allowed-tools` takes effect.

Constraints: do not invent frontmatter fields that don't exist. Do not put `allowed-tools` permissions broader than the workflow needs. If part of the workflow is genuinely risky (e.g. it deploys), call that out and set `disable-model-invocation: true`.