- 云原生
- 微服务
- 运维
- DevOps
【免费下载链接】meshery
Meshery, the cloud native manager
这篇指南以 meshery 仓库中打包的 Command Creator 技能 为骨架，系统讲解如何在 Claude Code 中把重复性工作流沉淀为以/command-name调用的可复用斜杠命令（Slash Command），并覆盖位置决策、四种命令模式、六步创建流程、Agent 优化指令写法与质量清单。读完你将能够独立把一个高频重复流程（PR 提交、CI 修复、代码评审等）转成"结构清晰、可自主执行、可测试迭代"的斜杠命令，并在项目级与全局两级正确落盘。
斜杠命令是什么：一种展开成提示词的 Markdown 文件
斜杠命令本质上是一个 Markdown 文件，存储在.claude/commands/（项目级）或~/.claude/commands/（全局/用户级）下，调用时其内容会被展开为提示词注入当前对话，从而让 Agent 按既定流程自主执行。它尤其适合：
- 重复性工作流（代码评审、PR 提交、CI 修复）；
- 需要一致性的多步骤流程；
- Agent 委派（Agent Delegation）类任务；
- 项目专属的自动化。
标准结构
--- description: Brief description shown in /help (required) argument-hint: <placeholder> (optional, if command takes arguments) --- # Command Title [Detailed instructions for the agent to execute autonomously]description：必填，显示在/help输出中；argument-hint：可选，仅当命令接收参数时存在，用于提示参数格式；- 正文：Agent 需要自主执行的详细指令。
调用方式与存储位置
/command-name [arguments]| 层级 | 路径 | 生效范围 |
|---|---|---|
| 项目级 | .claude/commands/my-command.md | 仅当前项目 |
| 全局/用户级 | ~/.claude/commands/my-command.md | 所有项目 |
何时调用该技能
当出现以下需求时即可触发 Command Creator 技能：从零创建新斜杠命令、自动化重复执行的工作流、把多步骤流程固化为一致执行、将手工流程转为自动化命令、为团队工作流创建项目级命令、为个人效率构建全局命令。
官方建议的触发短语包括："create a command"、"make a slash command"、"add a command"、"I keep doing X, can we make a command for it?"、"automate this workflow"、"create a reusable command"。在本仓库中，command-creator技能的元数据定义在 .agents/skills/command-creator/SKILL.md 的 frontmatter 中，其中description字段即被用于技能发现。
技能核心能力
1. 智能位置检测
根据当前目录的 git 仓库状态、用户显式偏好以及命令的作用域与目的，自动判定命令应落位于项目级还是全局。
2. 基于模式的设计
引导用户从四种经过验证的命令模式中选择：工作流自动化、迭代修复、Agent 委派、简单执行。
3. Agent 优化指令
生成的命令可被 Agent 自主执行：祈使/不定式动词开头的指令、显式工具使用说明、清晰的成功标准、具体的错误处理、明确的预期结果。
4. 质量保障
内置命名约定（强制 kebab-case）、参数处理与提示、工具限制指引、错误恢复策略、进度上报模式等最佳实践。
5. 捆绑参考文档
随技能附带三份完整参考文件，分别对应模式设计、真实命令实现与质量检查清单。
六步创建工作流
第 1 步：确定存放位置
自动检测逻辑如下：
- 检查当前目录是否位于 git 仓库内：
git rev-parse --is-inside-work-tree 2>/dev/null - 默认规则：在 git 仓库内 → 项目级
.claude/commands/；不在 git 仓库内 → 全局~/.claude/commands/ - 允许用户覆盖：显式提到 "global"/"user-level" 用全局；显式提到 "project"/"project-level" 用项目级
进入下一步前必须将所选位置告知用户。
第 2 步：展示命令模式
向用户呈现四种模式帮助框定需求，并询问"哪种模式最接近你想创建的命令"：
- 工作流自动化：分析 → 行动 → 报告（如 submit-stack）
- 迭代修复：运行 → 解析 → 修复 → 重复（如 ensure-ci）
- Agent 委派：上下文 → 委派 → 迭代（如 create-implementation-plan）
- 简单执行：带参数运行命令（如 codex-review）
详细设计指引见 .agents/skills/command-creator/references/patterns.md。
第 3 步：收集命令信息
通过问答收集四类信息：
A. 命令名称与用途
- 名称（作为文件名）；名称必须为 kebab-case（
my-command正确，my_command错误）； - 用于
/help输出的描述；描述应简洁、动作导向； - 文件名与命令名一一对应：
my-command.md→ 调用为/my-command。
B. 参数
- 是否接收参数？必填还是可选？参数代表什么？
- 若接收参数，在 frontmatter 中增加
argument-hint: <placeholder>； - 必填参数用尖括号
<...>，可选参数用方括号[...]。
C. 工作流步骤
- 具体步骤及执行顺序、使用的工具或命令；
- 需覆盖：初始分析或检查、主要动作、结果处理方式、成功标准、错误处理方式。
D. 工具限制与引导
- 是否使用特定 Agent 或工具？应避免哪些操作？是否需要读取特定文件作为上下文？
第 4 步：生成优化命令
依据 .agents/skills/command-creator/references/best-practices.md 中的模板结构、Agent 执行最佳实践、写作风格与质量清单生成命令。核心原则：使用祈使/不定式（动词开头）、表述具体明确、包含预期结果、给出具体示例、定义清晰的错误处理。
第 5 步：创建命令文件
- 确定完整文件路径：项目级为
.claude/commands/[command-name].md，全局为~/.claude/commands/[command-name].md； - 确保目录存在：
mkdir -p [directory-path]； - 用 Write 工具写入命令文件；
- 向用户确认：报告文件位置、概括命令功能、说明调用语法
/command-name [arguments]。
第 6 步：测试与迭代
- 建议用户运行测试：
/command-name [arguments]； - 等待用户反馈；
- 根据结果迭代改进；
- 将优化写回文件。
四种命令模式详解
模式一：工作流自动化（分析 → 行动 → 报告）
适用场景：需要分析后行动、有清晰顺序、产出特定结果（提交、PR、报告）的多步骤流程。
示例（提交 PR stack）：
1. Analyze git history to identify commit stack 2. Create PRs for each commit with proper dependencies 3. Report created PRs with links and status关键特征：带依赖的连续步骤、行动前有清晰的分析阶段、全面的最终报告。
模式二：迭代修复（运行 → 解析 → 修复 → 重复）
适用场景：需要反复执行直到满足成功条件的任务（lint、测试、CI），有明确通过/失败判据。
示例（确保 CI 通过）：
1. Run tests and capture output 2. Parse failures and errors 3. Fix identified issues 4. Repeat until all tests pass关键特征：循环直到成功条件、解析错误指导修复、跨迭代跟踪进度。建议设置安全上限：最大迭代 10 次、同一错误连续出现 3 次即停止、使用 TodoWrite 跟踪迭代进度。
模式三：Agent 委派（上下文 → 委派 → 迭代）
适用场景：需要专业 Agent 专长的复杂任务、多阶段流程、需要人审的任务。
示例（创建实施计划）：
1. Gather context (requirements, codebase) 2. Delegate to subagent agent 3. Iterate on plan with user feedback 4. Save final plan to .PLAN.md关键特征：使用 Task 工具调用专业 Agent、向被委派 Agent 传递相关上下文、对专业 Agent 的输出进行迭代。
模式四：简单执行（解析参数 → 执行 → 返回输出）
适用场景：单步命令、现有工具的包装命令、直接运行并上报的命令。
示例（代码评审）：
1. Run codex review on specified files 2. Present results to user关键特征：最少逻辑、直接执行、参数透传给底层工具、快速反馈回路。
模式选择速查
| 需求 | 对应模式 |
|---|---|
| 基于分析创建提交/PR | 工作流自动化 |
| 迭代修复直到通过 | 迭代修复 |
| 创建计划或委派给专家 | Agent 委派 |
| 运行工具并展示结果 | 简单执行 |
| 协调多个 Agent | 多 Agent 编排 |
| 检查多个上下文文件 | 上下文文件优先级 |
| 按复杂度选择方案 | 条件工具选择 |
| 运行 make 目标 | Makefile 集成 |
| 从简开始按需展开 | 渐进式披露 |
命令通常组合多种模式，例如 submit-stack 组合了上下文文件优先级（检查 .PLAN.md）、工作流自动化（分析→提交→提交 PR）与条件工具选择。
位置策略：项目级还是全局
项目级命令（.claude/commands/）
适用场景：命令与项目工作流强相关、需要项目特定上下文或文件、需要团队共享、自动化与项目结构绑定。例如/submit-stack（项目的 PR 提交流程）、/ensure-ci（项目的测试套件）、/deploy-staging（项目的部署流程）。
优势：随项目纳入版本控制、团队共享、支持项目级定制。
全局命令（~/.claude/commands/）
适用场景：跨项目通用、个人生产力工具、通用工作流自动化、无项目依赖。例如/codex-review（评审任意文件）、/create-implementation-plan（通用规划）、/git-cleanup（任意仓库的 git 维护）。
优势：处处可用、支持个人定制、与具体项目解耦。
捆绑参考资源
技能在references/目录下附带三份互补的参考文件，写作时按需加载：
| 文件 | 内容 | 加载时机 |
|---|---|---|
| .agents/skills/command-creator/references/patterns.md | 四种模式的详细设计指引、各模式适用时机、工具使用建议、真实示例 | 设计命令工作流、选择合适模式时 |
| .agents/skills/command-creator/references/examples.md | /submit-stack、/ensure-ci、/create-implementation-plan等完整源码、关键决策注释、最佳实践示例 | 需要具体命令的结构范例时 |
| .agents/skills/command-creator/references/best-practices.md | 命令模板结构、Agent 优化写作风格、常见陷阱、质量检查清单、工具限制模式、错误处理策略、命名约定 | 最终定稿前保证质量 |
实战示例
示例一：创建项目级 CI 修复命令
用户诉求："I keep fixing CI failures manually. Can we make a command for this?"
技能流程：检测到项目级（在 git 仓库内）→ 建议"迭代修复"模式 → 收集信息（名称ensure-ci、描述 "Iteratively fix CI failures until all tests pass"、无参数、步骤为 运行测试 → 解析失败 → 修复问题 → 重复）→ 使用 Bash 工具运行 pytest 生成命令 → 创建.claude/commands/ensure-ci.md→ 用户以/ensure-ci调用。
示例二：创建全局代码评审命令
用户诉求："Create a global command to review code with Codex"
技能流程：检测到全局（用户显式要求）→ 建议"简单执行"模式 → 收集信息（名称codex-review、描述 "Review code files using Codex"、必填参数<files>、步骤为 运行 codex 评审 → 展示结果）→ 生成命令 → 创建~/.claude/commands/codex-review.md→ 用户以/codex-review src/app.py src/utils.py调用。
示例三：创建 PR 提交工作流
用户诉求："Make a command that analyzes my commits and creates a PR stack"
技能流程：检测到项目级 → 建议"工作流自动化"模式 → 收集信息（名称submit-stack、描述 "Create PR stack from commit history"、可选参数[base-branch]默认 main、步骤为 分析提交 → 创建 PR → 报告结果）→ 使用 git 分析与 gh CLI 生成命令 → 创建.claude/commands/submit-stack.md→ 用户以/submit-stack或/submit-stack develop调用。
编写最佳实践
命名约定
必须使用 kebab-case（连字符而非下划线）：正确submit-stack、ensure-ci、create-from-plan；错误submit_stack、ensure_ci、create_from_plan。
参数提示
- 必填参数用
<angle-brackets>：argument-hint: <file-path> - 可选参数用
[square-brackets]：argument-hint: [base-branch] - 混合形式：
argument-hint: <command> [args...]
Agent 优化指令
- 用祈使/不定式：正确 "Run pytest to execute tests"；错误 "You should run pytest to execute tests"。
- 显式说明工具：正确 "Use the Bash tool to run
pytest tests/"；错误 "Run the tests"。 - 定义成功标准：正确 "Continue until all tests pass (exit code 0)"；错误 "Fix the tests"。
- 包含错误处理：正确 "If pytest fails, parse the output to identify failing tests, then fix each one"；错误 "Fix any test failures"。
- 给出真实示例：避免 foo/bar 占位符，例如
git commit -m 'Add user authentication with OAuth2'。 - 包含预期结果：例如 "Run git status - this should show modified files in src/ directory"。
工具限制
Bash 工具用于：pytest、pyright、ruff、prettier、make、npm、yarn、gt（git-town 命令）。
Task 工具用于：专业 Agent（subagent、subagents）、长时间运行或复杂的委派任务。
命令中应避免：交互式提示（命令必须自主执行）、用户确认循环（除非模式明确要求）、需要解释的模糊指令。
常见陷阱
- 模糊指令：错误 "Fix any errors that appear"；正确分类型给出修复动作（
make fix、make format、Edit 工具手工修复）。 - 缺少错误处理：应写明"若退出码为 0 则成功；非 0 则解析输出、针对性修复、再次验证、同一错误连续 3 次则停止"。
- 条件分支含糊：应使用明确的 if/else 结构，如检查
.PLAN.md存在与否的分支。 - 批量操作：不要"先修完所有错误再统一标记 todo"，应每修完一类错误立即标记对应 todo 完成。
- 工具混淆：明确 "Use Bash tool to run make commands"，不要含糊地说"use an agent to run make"。
- 缺少上下文：先检查
.PLAN.md、git status、git diff HEAD再行动。 - 描述质量差：
/help中显示的 description 要清晰、动作导向，例如 "Run make all-ci and iteratively fix issues until all checks pass"。
质量检查清单（定稿前核对）
- 结构：名称具描述性且为 kebab-case；描述简洁动作导向；frontmatter 含
description（必填）；必要时含argument-hint；有用户向摘要 "What This Command Does"；有编号的 "Implementation Steps"。 - 内容：步骤编号且顺序清晰；每步含具体可执行指令；显式指定工具；文件检查给出代码示例；条件逻辑为清晰 if/else；用 "NEVER"/"DO NOT" 标出反模式；错误处理定义具体动作；成功标准明确。
- 写作风格：祈使/不定式；具体不模糊；包含预期结果；真实示例。
- 位置：项目级/全局判断合适；目录已存在或将创建；文件路径正确。
- 测试：用户知道调用方式
/command-name [arguments]；尽可能已测试；迭代已纳入用户反馈。
常见应用场景
- 开发工作流：提交 PR（分析提交、按依赖创建 PR stack）、修复 CI（迭代运行测试、解析失败、修复）、代码评审（运行 linter、formatter、静态分析）、部署（构建、测试、部署到 staging/production）。
- 项目自动化：初始化（搭建项目结构、安装依赖）、文档（从代码生成文档、更新 README）、测试（运行全量测试套件并出覆盖率报告）、发布（升级版本、生成 changelog、打 tag）。
- 个人效率：Git 清理（删除已合并分支、修剪远端）、代码库分析（生成架构图、依赖图）、重构（跨文件统一模式）、规划（为功能创建实施计划）。
- 团队协作：新成员入职（搭建开发环境、克隆仓库）、标准执行（代码风格、提交信息格式）、知识沉淀（记录架构决策、补充示例）、评审（人工评审前的自动化评审检查）。
在 meshery 仓库中的落地形态
该技能并非孤立文档，而是仓库 Agent 工具链的一部分。[.agents/README.md](https://link.gitcode.com/i/ba70577ec1865c75da97f81b405035d0)说明.agents/skills/是该仓库所有打包工作流的单一事实来源，每个技能一个目录并含SKILL.md；Claude Code 通过.claude/skills（指向../.agents/skills的相对符号链接）发现技能，Codex 与 OpenCode 则原生扫描.agents/skills，因此技能内容一律通过.agents/skills/...规范路径自引用自身文件，绝不依赖符号链接解析。仓库根目录的 AGENTS.md 进一步要求：技能只登记在.agents/skills/下、不得在 AGENTS.md 中逐个枚举、.claude/skills只能是符号链接。作为通用型技能，Command Creator 不依赖仓库特定代码，其模式与示例同样适用于 Meshery 自身的 Go 后端（make golangci）、Next.js 前端（make ui-lint）与 mesheryctl（go test ./...）等重复性检查流程——例如可以将"运行make golangci并迭代修复直到通过"封装为一条迭代修复型命令。
小结与上手路径
一份高质量的斜杠命令应当：可靠（无需人工干预即可自主执行）、可维护（结构清晰、文档完善）、可复用（项目级或全局可用）、优化（为任务选用恰当工具与 Agent）。上手路径为：识别一个想自动化的重复工作流 → 调用/command-creator技能 → 按引导工作流创建命令 → 基于结果测试与迭代 → 团队共享（项目级）或个人使用（全局）。启动命令只需输入/command-creator，或直接说 "I want to create a command that [does something]"。
- 云原生
- 微服务
- 运维
- DevOps
【免费下载链接】meshery
Meshery, the cloud native manager
相关推荐
Claude Code 斜杠命令实战：用 Quick Plan 一键生成可执行的工程实施计划（claude-code-hooks-mastery）
Claude Code 斜杠命令实战：用 Quick Plan 一键生成可执行的工程实施计划（claude code hooks mastery） 在 Clau
claude-howto 实战：用 Claude Code `/commit` 斜杠命令打造带上下文的智能 Git 提交
claude howto 实战：用 Claude Code /commit 斜杠命令打造带上下文的智能 Git 提交 导读 /commit 是 claude h
教程文档Claude Code 斜杠命令实战：用 label-issue 自动为 GitHub Issue 打标签
Claude Code 斜杠命令实战：用 label issue 自动为 GitHub Issue 打标签 本篇技术指南围绕 claude code actio
AI AgentCI/CD代码智能体开发者工具
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
