菜单
Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/glittercowboy/taches-cc-resources --skill create-slash-commands命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Search The Pirate Bay for torrents and extract magnet links via the apibay.org JSON API. Use when asked to "find a torrent", "search pirate bay", "get a magnet link", "download torrent", "find seeders", "top torrents", or any torrent search task. Can operate via CLI tool or direct API calls.
Set up and configure Geoffrey Huntley's original Ralph Wiggum autonomous coding loop in any directory with proper structure, prompts, and backpressure.
Create Model Context Protocol (MCP) servers that expose tools, resources, and prompts to Claude. Use when building custom integrations, APIs, data sources, or any server that Claude should interact with via the MCP protocol. Supports both TypeScript and Python implementations.
正在显示 SKILL.md
基于 SOC 职业分类
| name | create-slash-commands |
| description | Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration. |
<quick_start>
1. Create `.claude/commands/` directory (project) or use `~/.claude/commands/` (personal) 2. Create `command-name.md` file 3. Add YAML frontmatter (at minimum: `description`) 4. Write command prompt 5. Test with `/command-name [args]` **File**: `.claude/commands/optimize.md`
---
description: Analyze this code for performance issues and suggest optimizations
---
Analyze the performance of this code and suggest three specific optimizations:
Usage: /optimize
Claude receives the expanded prompt and analyzes the code in context. </quick_start>
<xml_structure> All generated slash commands should use XML tags in the body (after YAML frontmatter) for clarity and consistency.
<required_tags>
<objective> - What the command does and why it matters
<objective>
What needs to happen and why this matters.
Context about who uses this and what it accomplishes.
</objective>
<process> or <steps> - How to execute the command
<process>
Sequential steps to accomplish the objective:
1. First step
2. Second step
3. Final step
</process>
<success_criteria> - How to know the command succeeded
<success_criteria>
Clear, measurable criteria for successful completion.
</success_criteria>
</required_tags>
<conditional_tags>
<context> - When loading dynamic state or files
<context>
Current state: ! `git status`
Relevant files: @ package.json
</context>
(Note: Remove the space after @ in actual usage)
<verification> - When producing artifacts that need checking
<verification>
Before completing, verify:
- Specific test or check to perform
- How to confirm it works
</verification>
<testing> - When running tests is part of the workflow
<testing>
Run tests: ! `npm test`
Check linting: ! `npm run lint`
</testing>
<output> - When creating/modifying specific files
<output>
Files created/modified:
- `./path/to/file.ext` - Description
</output>
</conditional_tags>
<structure_example>
---
name: example-command
description: Does something useful
argument-hint: [input]
---
<objective>
Process $ARGUMENTS to accomplish [goal].
This helps [who] achieve [outcome].
</objective>
<context>
Current state: ! `relevant command`
Files: @ relevant/files
</context>
<process>
1. Parse $ARGUMENTS
2. Execute operation
3. Verify results
</process>
<success_criteria>
- Operation completed without errors
- Output matches expected format
</success_criteria>
</structure_example>
<intelligence_rules>
Simple commands (single operation, no artifacts):
<objective>, <process>, <success_criteria>/check-todos, /first-principlesComplex commands (multi-step, produces artifacts):
<objective>, <process>, <success_criteria><context> (if loading state), <verification> (if creating files), <output> (what gets created)/commit, /create-prompt, /run-promptCommands with dynamic arguments:
$ARGUMENTS in <objective> or <process> tagsargument-hint in frontmatterCommands that produce files:
<output> tag specifying what gets created<verification> tag with checks to performCommands that run tests/builds:
<testing> tag with specific commands<success_criteria>
</intelligence_rules>
</xml_structure><arguments_intelligence> The skill should intelligently determine whether a slash command needs arguments.
<commands_that_need_arguments>
User provides specific input:
/fix-issue [issue-number] - Needs issue number/review-pr [pr-number] - Needs PR number/optimize [file-path] - Needs file to optimize/commit [type] - Needs commit type (optional)Pattern: Task operates on user-specified data
Include argument-hint: [description] in frontmatter and reference $ARGUMENTS in the body.
</commands_that_need_arguments>
<commands_without_arguments>
Self-contained procedures:
/check-todos - Operates on known file (TO-DOS.md)/first-principles - Operates on current conversation/whats-next - Analyzes current contextPattern: Task operates on implicit context (current conversation, known files, project state)
Omit argument-hint and don't reference $ARGUMENTS.
</commands_without_arguments>
<incorporating_arguments>
In <objective> tag:
<objective>
Fix issue #$ARGUMENTS following project conventions.
This ensures bugs are resolved systematically with proper testing.
</objective>
In <process> tag:
<process>
1. Understand issue #$ARGUMENTS from issue tracker
2. Locate relevant code
3. Implement fix
4. Add tests
</process>
In <context> tag:
<context>
Issue details: @ issues/$ARGUMENTS.md
Related files: ! `grep -r "TODO.*$ARGUMENTS" src/`
</context>
(Note: Remove the space after the exclamation mark in actual usage) </incorporating_arguments>
<positional_arguments>
For structured input, use $1, $2, $3:
---
argument-hint: <pr-number> <priority> <assignee>
---
<objective>
Review PR #$1 with priority $2 and assign to $3.
</objective>
Usage: /review-pr 456 high alice
</positional_arguments>
</arguments_intelligence>
<file_structure>
Project commands: .claude/commands/
(project) in /help listPersonal commands: ~/.claude/commands/
(user) in /help listFile naming: command-name.md → invoked as /command-name
</file_structure>
<yaml_frontmatter>
description: Analyze this code for performance issues and suggest optimizations
Shown in the /help command list.
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
Formats:
allowed-tools: [Read, Edit, Write]allowed-tools: SequentialThinkingallowed-tools: Bash(git add:*)If omitted: All tools available </yaml_frontmatter>
Command file: .claude/commands/fix-issue.md
---
description: Fix issue following coding standards
---
Fix issue #$ARGUMENTS following our coding standards
Usage: /fix-issue 123 high-priority
Claude receives: "Fix issue #123 high-priority following our coding standards" </all_arguments_string>
<positional_arguments_syntax>
Command file: .claude/commands/review-pr.md
---
description: Review PR with priority and assignee
---
Review PR #$1 with priority $2 and assign to $3
Usage: /review-pr 456 high alice
Claude receives: "Review PR #456 with priority high and assign to alice"
See references/arguments.md for advanced patterns. </positional_arguments_syntax>
<dynamic_context>
Execute bash commands before the prompt using the exclamation mark prefix directly before backticks (no space between).
Note: Examples below show a space after the exclamation mark to prevent execution during skill loading. In actual slash commands, remove the space.
Example:
---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---
## Context
- Current git status: ! `git status`
- Current git diff: ! `git diff HEAD`
- Current branch: ! `git branch --show-current`
- Recent commits: ! `git log --oneline -10`
## Your task
Based on the above changes, create a single git commit.
The bash commands execute and their output is included in the expanded prompt. </dynamic_context>
<file_references>
Use @ prefix to reference specific files:
---
description: Review implementation
---
Review the implementation in @ src/utils/helpers.js
(Note: Remove the space after @ in actual usage)
Claude can access the referenced file's contents. </file_references>
<best_practices>
1. Always use XML structure
# All slash commands should have XML-structured bodies
After frontmatter, use XML tags:
<objective> - What and why (always)<process> - How to do it (always)<success_criteria> - Definition of done (always)2. Clear descriptions
# Good
description: Analyze this code for performance issues and suggest optimizations
# Bad
description: Optimize stuff
3. Use dynamic context for state-dependent tasks
Current git status: ! `git status`
Files changed: ! `git diff --name-only`
4. Restrict tools when appropriate
# For git commands - prevent running arbitrary bash
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
# For analysis - thinking only
allowed-tools: SequentialThinking
5. Use $ARGUMENTS for flexibility
Find and fix issue #$ARGUMENTS
6. Reference relevant files
Review @ package.json for dependencies
Analyze @ src/database/* for schema
(Note: Remove the space after @ in actual usage) </best_practices>
<common_patterns>
Simple analysis command:
---
description: Review this code for security vulnerabilities
---
<objective>
Review code for security vulnerabilities and suggest fixes.
</objective>
<process>
1. Scan code for common vulnerabilities (XSS, SQL injection, etc.)
2. Identify specific issues with line numbers
3. Suggest remediation for each issue
</process>
<success_criteria>
- All major vulnerability types checked
- Specific issues identified with locations
- Actionable fixes provided
</success_criteria>
Git workflow with context:
---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---
<objective>
Create a git commit for current changes following repository conventions.
</objective>
<context>
- Current status: ! `git status`
- Changes: ! `git diff HEAD`
- Recent commits: ! `git log --oneline -5`
</context>
<process>
1. Review staged and unstaged changes
2. Stage relevant files
3. Write commit message following recent commit style
4. Create commit
</process>
<success_criteria>
- All relevant changes staged
- Commit message follows repository conventions
- Commit created successfully
</success_criteria>
Parameterized command:
---
description: Fix issue following coding standards
argument-hint: [issue-number]
---
<objective>
Fix issue #$ARGUMENTS following project coding standards.
This ensures bugs are resolved systematically with proper testing.
</objective>
<process>
1. Understand the issue described in ticket #$ARGUMENTS
2. Locate the relevant code in codebase
3. Implement a solution that addresses root cause
4. Add appropriate tests
5. Verify fix resolves the issue
</process>
<success_criteria>
- Issue fully understood and addressed
- Solution follows coding standards
- Tests added and passing
- No regressions introduced
</success_criteria>
File-specific command:
---
description: Optimize code performance
argument-hint: [file-path]
---
<objective>
Analyze performance of @ $ARGUMENTS and suggest specific optimizations.
This helps improve application performance through targeted improvements.
</objective>
<process>
1. Review code in @ $ARGUMENTS for performance issues
2. Identify bottlenecks and inefficiencies
3. Suggest three specific optimizations with rationale
4. Estimate performance impact of each
</process>
<success_criteria>
- Performance issues clearly identified
- Three concrete optimizations suggested
- Implementation guidance provided
- Performance impact estimated
</success_criteria>
Usage: /optimize src/utils/helpers.js
See references/patterns.md for more examples. </common_patterns>
<reference_guides>
Arguments reference: references/arguments.md
Patterns reference: references/patterns.md
Tool restrictions: references/tool-restrictions.md
<generation_protocol>
Analyze the user's request:
Create frontmatter:
---
name: command-name
description: Clear description of what it does
argument-hint: [input] # Only if arguments needed
allowed-tools: [...] # Only if tool restrictions needed
---
Create XML-structured body:
Always include:
<objective> - What and why<process> - How to do it (numbered steps)<success_criteria> - Definition of doneInclude when relevant:
<context> - Dynamic state (! commands) or file references (@ files)<verification> - Checks to perform if creating artifacts<testing> - Test commands if tests are part of workflow<output> - Files created/modifiedIntegrate $ARGUMENTS properly:
argument-hint and use $ARGUMENTS in tagsargument-hint and $ARGUMENTSApply intelligence:
Save the file:
.claude/commands/command-name.md~/.claude/commands/command-name.md
</generation_protocol><success_criteria> A well-structured slash command meets these criteria:
YAML Frontmatter:
description field is clear and conciseargument-hint present if command accepts argumentsallowed-tools specified if tool restrictions neededXML Structure:
<objective>, <process>, <success_criteria>Arguments Handling:
$ARGUMENTS used when command operates on user-specified data$1, $2, etc.) used when structured input needed$ARGUMENTS reference for self-contained commandsFunctionality:
Quality:
<process> tag<success_criteria>