<快速开始> --- 描述：分析此代码的性能问题并提出优化建议 --- 分析这段代码的性能并提出三个具体的优化建议： **用法**：`/优化` 克劳德收到扩展提示并根据上下文分析代码。所有生成的斜杠命令都应在正文中使用 XML 标记（在 YAML frontmatter 之后），以保证清晰性和一致性。 <必需的标签> **`<目标>`** \- 该命令的作用及其重要性 <目标> 需要发生什么以及为什么这很重要。关于谁使用它以及它完成什么的上下文。 **`` 或 ``** \- 如何执行命令 <过程> 实现目标的顺序步骤： 1.第一步 2.第二步 3.最后一步 **``** \- 如何知道命令成功 <成功标准> 成功完成的明确、可衡量的标准。 <条件标签> **``** \- 加载动态状态或文件时 <上下文> 当前状态： ! `git 状态` 相关文件：@package.json （注：实际使用时去掉@后面的空格） **``** \- 生成需要检查的工件时 <验证> 完成之前，请验证： - 要执行的特定测试或检查 - 如何确认其有效 **``** \- 当运行测试是工作流程的一部分时 <测试> 运行测试： ! `npm 测试` 检查 linting： ! `npm 运行 lint` **``** \- 创建/修改特定文件时 <输出> 创建/修改的文件： - `./path/to/file.ext` - 描述 <结构示例> --- 名称：示例命令描述：做一些有用的事情参数提示：[输入] --- <目标> 处理 $ARGUMENTS 以实现[目标]。这有助于[谁]实现[成果]。 <上下文> 当前状态： ! `相关命令` 文件：@相关/文件 <过程> 1. 解析$ARGUMENTS 2. 执行操作 3. 验证结果 <成功标准> - 操作完成且没有错误 - 输出符合预期格式 <情报规则> **简单的命令**（单一操作，无工件）： * 必需：`<目标>`、`<过程>`、`<成功标准>` * 示例：`/check-todos`、`/first-principles` **复杂命令**（多步骤，产生工件）： * 必需：`<目标>`、`<过程>`、`<成功标准>` * 添加：``（如果正在加载状态）、``（如果创建文件）、``（创建的内容） * 示例：`/commit`、`/create-prompt`、`/run-prompt` **带有动态参数的命令**： * 在``或``标签中使用`$ARGUMENTS` * 在 frontmatter 中包含 `argument-hint` * 明确论据的目的 **生成文件的命令**： * 始终包含``标签来指定创建的内容 * 始终包含要执行的检查的“”标签 **运行测试/构建的命令**： * 包含带有特定命令的``标签 * 在 `` 中包含通过/失败标准该技能应该智能地确定斜杠命令是否需要参数。 <需要参数的命令> **用户提供具体输入：** * `/fix-issue [问题编号]` \- 需要问题编号 * `/review-pr [pr-number]` \- 需要 PR 编号 * `/optimize [file-path]` \- 需要文件进行优化 * `/commit [type]` \- 需要提交类型（可选） **模式：** 任务对用户指定的数据进行操作在 frontmatter 中包含 `argument-hint: [description]` 并在正文中引用 `$ARGUMENTS`。 <无参数命令> **独立程序：** * `/check-todos` \- 对已知文件（TO-DOS.md）进行操作 * `/first-principles` \- 对当前对话进行操作 * `/whats-next` \- 分析当前上下文 **模式：** 任务在隐式上下文上运行（当前对话、已知文件、项目状态）省略“argument-hint”并且不引用“$ARGUMENTS”。 <合并参数> **在``标签中：** <目标> 修复遵循项目约定的问题 #$ARGUMENTS。这可确保通过适当的测试系统地解决错误。 **在``标签中：** <过程> 1. 从问题跟踪器中了解问题#$ARGUMENTS 2.找到相关代码 3. 实施修复 4.添加测试 **在``标签中：** <上下文> 问题详情：@issues/$ARGUMENTS.md 相关文件： ! `grep -r "TODO.*$ARGUMENTS" src/` （注：实际使用时去掉感叹号后面的空格） <位置参数> 对于结构化输入，请使用 `$1`、`$2`、`$3`： --- 参数提示： <优先级> <受让人> --- <目标> 以优先级 $2 审查 PR #$1 并分配给 $3。 **用法：** `/review-pr 456 high alice` <文件结构> **项目命令**：`.claude/commands/` * 通过版本控制与团队共享 * 在“/help”列表中显示“(project)” **个人命令** : `~/.claude/commands/` * 适用于您的所有项目 * 在`/help`列表中显示`(user)` **文件命名** : `command-name.md` → 作为 `/command-name` 调用描述：分析此代码的性能问题并提出优化建议显示在`/help`命令列表中。允许的工具：Bash(git add:*)、Bash(git status:*)、Bash(git commit:*) **格式**： * 数组：`允许的工具：[读取、编辑、写入]` * 单一工具：`允许的工具：SequentialThinking` * Bash 限制：`允许的工具：Bash(git add:*)` 如果省略：所有可用工具 **命令文件** : `.claude/commands/fix-issue.md` --- 描述：修复遵循编码标准的问题 --- 遵循我们的编码标准修复问题#$ARGUMENTS **用法**：`/fix-issue 123 高优先级` **Claude 收到**：“按照我们的编码标准修复问题 #123 高优先级” <位置参数语法> **命令文件** : `.claude/commands/review-pr.md` --- 描述：审查 PR 的优先级和受让人 --- 以优先级 $2 审查 PR #$1 并分配给 $3 **用法**：`/review-pr 456 high alice` **Claude 收到**：“以高优先级审查 PR #456 并分配给 alice” 有关高级模式，请参阅 [references/arguments.md]()。 <动态上下文> 在提示符之前执行 bash 命令，在反引号之前使用感叹号前缀（之间没有空格）。 **注意：** 下面的示例在感叹号后面显示一个空格，以防止在技能加载期间执行。在实际的斜杠命令中，删除空格。示例： --- 描述：创建一个 git 提交允许的工具：Bash(git add:*)、Bash(git status:*)、Bash(git commit:*) --- ## 上下文 - 当前 git 状态：！ `git 状态` - 当前 git diff: ! `git diff HEAD` - 当前分支： ! `git分支--显示当前` - 最近的提交：！ `git log --oneline -10` ## 你的任务基于上述更改，创建单个 git 提交。 bash 命令执行，其输出包含在扩展提示符中。 <文件引用> 使用“@”前缀来引用特定文件： --- 描述：审查实施情况 --- 查看 @ src/utils/helpers.js 中的实现（注：实际使用时去掉@后面的空格）克劳德可以访问引用文件的内容。 <最佳实践> **1\.始终使用 XML 结构** # 所有斜杠命令都应该有 XML 结构体在 frontmatter 之后，使用 XML 标签： * `` \- 什么以及为什么（总是） * `` \- 如何做（总是） * `` \- 完成的定义（总是） * 根据需要附加标签（参见 xml_struct 部分） **2\.清晰的描述** # 好描述：分析此代码的性能问题并提出优化建议 # 不好描述：优化内容 **3\.使用动态上下文执行与状态相关的任务** 当前 git 状态： ! `git 状态` 文件已更改： ! `git diff --仅名称` **4\.适当时限制工具** # 对于 git 命令 - 防止运行任意 bash 允许的工具：Bash(git add:*)、Bash(git status:*)、Bash(git commit:*) # 用于分析 - 仅思考允许的工具：SequentialThinking **5\.使用 $ARGUMENTS 获得灵活性** 查找并修复问题#$ARGUMENTS **6\.参考相关文件** 检查 @package.json 的依赖关系分析 @src/database/* 的模式（注：实际使用时去掉@后面的空格） <常见模式> **简单分析命令**： --- 描述：检查此代码是否存在安全漏洞 --- <目标> 检查代码是否存在安全漏洞并提出修复建议。 <过程> 1.扫描代码常见漏洞（XSS、SQL注入等） 2. 确定行号的具体问题 3. 针对每个问题提出修复建议 <成功标准> - 检查所有主要漏洞类型 - 与地点相关的具体问题 - 提供了可行的修复 **带有上下文的 Git 工作流程**： --- 描述：创建一个 git 提交允许的工具：Bash(git add:*)、Bash(git status:*)、Bash(git commit:*) --- <目标> 按照存储库约定为当前更改创建 git 提交。 <上下文> - 当前状态：！ `git 状态` - 变化：！ `git diff HEAD` - 最近的提交：！ `git log --oneline -5` <过程> 1.审查已分阶段和未分阶段的变更 2.暂存相关文件 3. 按照最近的提交风格编写提交消息 4. 创建提交 <成功标准> - 所有相关变更均已上演 - 提交消息遵循存储库约定 - 提交创建成功 **参数化命令**： --- 描述：修复遵循编码标准的问题参数提示：[问题号] --- <目标> 遵循项目编码标准修复问题#$ARGUMENTS。这可确保通过适当的测试系统地解决错误。 <过程> 1. 了解票证 #$ARGUMENTS 中描述的问题 2.在代码库中找到相关代码 3. 实施解决根本原因的解决方案 4.添加适当的测试 5. 验证修复是否能解决问题 <成功标准> - 问题得到充分理解和解决 - 解决方案遵循编码标准 - 添加并通过测试 - 没有引入回归 **特定于文件的命令**： --- 描述：优化代码性能参数提示：[文件路径] --- <目标> 分析@$ARGUMENTS的性能并提出具体的优化建议。这有助于通过有针对性的改进来提高应用程序性能。 <过程> 1.检查@$ARGUMENTS中的代码是否存在性能问题 2. 识别瓶颈和低效率 3. 提出三个具体优化建议并说明理由 4. 估计每个的性能影响 <成功标准> - 明确识别性能问题 - 建议三个具体优化 - 提供实施指导 - 估计的性能影响 **用法**：`/optimize src/utils/helpers.js` 有关更多示例，请参阅 [references/patterns.md]()。 <参考指南> **参数参考**：[references/arguments.md]() * $ARGUMENTS 变量 * 位置参数 ($1, $2, $3) * 解析策略 * 示例来自官方文档 **模式参考**：[references/patterns.md]() * Git 工作流程 * 代码分析 * 文件操作 * 安全审查 * 示例来自官方文档 **工具限制**：[references/tool-restrictions.md]() * Bash 命令模式 * 安全最佳实践 * 何时限制工具 * 示例来自官方文档 <生成协议> 1. **分析用户的请求** : * 该命令的目的是什么？ * 是否需要用户输入（$ARGUMENTS）？ * 它会生成文件或工件吗？ * 是否需要验证或测试？ * 是简单（单步）还是复杂（多步）？ 2. **创建前言**： --- 名称：命令名称描述：清楚地描述它的作用 argument-hint: [input] # 仅当需要参数时 allowed-tools: [...] # 仅当需要工具限制时 --- 3. **创建 XML 结构体** : **始终包括：** * `<目标>` \- 什么以及为什么 * `` \- 如何执行（编号步骤） * `` \- 完成的定义 **相关时包括：** * `` \- 动态状态（！`命令`）或文件引用（@ 文件） * `` \- 如果创建工件则执行检查 * `` \- 测试命令（如果测试是工作流程的一部分） * `` \- 创建/修改的文件 4. **正确整合$ARGUMENTS**： * 如果需要用户输入：添加 `argument-hint` 并在标签中使用 `$ARGUMENTS` * 如果是独立的：省略 `argument-hint` 和 `$ARGUMENTS` 5. **应用情报**： * 简单的命令：保持简洁（目标+过程+成功标准） * 复杂命令：根据需要添加上下文、验证、测试 * 不要过度设计简单的命令 * 不要低估复杂的命令 6. **保存文件**： * 项目: `.claude/commands/command-name.md` * 个人：`~/.claude/commands/command-name.md` 结构良好的斜杠命令满足以下条件： **YAML 前沿问题**： * `description`字段清晰简洁 * 如果命令接受参数则存在“参数提示” * 如果需要工具限制，则指定“允许的工具” **XML 结构**： * 存在所有三个必需标签：``、``、`` * 根据复杂性适当使用条件标签 * 正文中没有原始降价标题 * 所有 XML 标签正确关闭 **参数处理**： * 当命令对用户指定的数据进行操作时使用“$ARGUMENTS” * 需要结构化输入时使用的位置参数（`$1`、`$2`等） * 自包含命令没有“$ARGUMENTS”参考 **功能**： * 命令在调用时正确扩展 * 动态上下文正确加载（bash 命令、文件引用） * 工具限制防止未经授权的操作 * 指挥可靠地完成预期目的 **质量**： * `` 标签中清晰、可操作的指令 * `` 中的可衡量完成标准 *适当的细节水平（不为简单任务过度设计） * 有益时提供的示例

创建斜杠命令

包含技能