Claude Code Slash Command Designer: One-Click Custom /commands
Turns the checklist or multi-step process you re-paste every time into a custom slash command (.claude/commands/<name>.md, or the newer .claude/skills), with correct frontmatter, $ARGUMENTS parameters, live context pre-injected via `!cmd` (git diff, PR content), and permissions scoped down with allowed-tools.
See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.claude/skills/slash-command-designer/SKILL.md and every future session can use it automatically.
mkdir -p ~/.claude/skills/slash-command-designer && mv ~/Downloads/SKILL.md ~/.claude/skills/slash-command-designer/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\slash-command-designer" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\slash-command-designer\SKILL.md"[When to use] The third time you catch yourself pasting the same 'help me do X' steps into Claude Code. [Why it works] (1) It first helps you pick the right container—use .claude/commands/<name>.md for lightweight needs (the filename is the command name, and this format still works), and only upgrade to .claude/skills/<name>/SKILL.md when you need attached scripts, subagents, or auto-triggering; (2) the frontmatter keeps only fields that genuinely matter: `description` so teammates understand it in the / menu, `allowed-tools` scoped exactly right (e.g., a lint command given only `Bash(npm run lint:*)` simply cannot accidentally edit files), and `disable-model-invocation: true` added for anything with side effects (deploy/commit) so Claude can't decide to run it on its own initiative; (3) it teaches you to use 'execution injection' like `!git diff` to stuff live state in before the model even reads the prompt, so the model receives an actual diff rather than a one-line instruction. [Tips] Commit the command file into `.claude/` so the whole team automatically shares it; project-level `allowed-tools` only takes effect after accepting the workspace-trust dialog. Use `$ARGUMENTS` to capture everything, `$1`/`$2` for individual positional arguments, and remember to quote multi-word arguments.
Chosen format: .claude/commands/summarize-changes.md (lightweight, no supporting files needed) --- description: Summarize uncommitted changes and flag risks. Use when asked what changed or for a commit message. allowed-tools: Bash(git diff:*) Bash(git status:*) --- ## Current changes !`git diff HEAD` ## Task Summarize the diff above in 2-3 bullets, then list risks (missing error handling, hardcoded values, tests to update). If the diff is empty, say there are no uncommitted changes. How to run: /summarize-changes Teammates get it automatically once .claude/commands/ is committed. Project-level allowed-tools activates after you accept the workspace-trust dialog.
[WORKFLOW_DESCRIPTION]你重複在做的流程,講清楚步驟與目的,例如「總結未提交的改動並標出風險、給 commit message」
[COMMAND_NAME]想用的指令名(kebab-case),例如 summarize-changes、fix-issue、review-pr
[ARGUMENTS]指令要吃的參數(沒有就寫『無』),例如「issue 編號」或「元件名 來源框架 目標框架」
[LIVE_CONTEXT]要自動注入的即時上下文 shell 指令(沒有就寫『無』),例如 `git diff HEAD`、`gh pr diff`、`git status --short`
[TOOLS_NEEDED]這指令合理需要、且希望免按同意的工具,盡量收窄,例如 Read、Grep、Bash(git add *) Bash(git commit *)
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
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`.Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.