工具Cursor（六）Rules&Skill&Commands（3）commands

一、介绍

1、简介

Cursor Commands 是 Cursor IDE 中的一个强大功能，允许你创建可重用的 AI 指令模板。这些命令可以封装复杂的任务流程，让 AI 助手按照预定义的步骤和规则执行特定任务。

2、 用途

1. **标准化工作流程**：将重复性的复杂任务（如代码审查、重构、测试生成等）标准化为可重用的模板

2. **提高效率**：避免每次都要重新描述相同的任务流程和规则

3. **确保一致性**：确保相同类型的任务总是按照相同的方式执行

4. **知识共享**：团队成员可以共享最佳实践和标准流程

3、如何创建

点击进入Cursor Settings--Rules Skills Sub..，拉到下面有个commands配置

点击new，同样有两种：project级别和user级别，和rules一样，project级别会自动在当前项目生成文件。

4、如何调用 Commands

这些方法，我最喜欢使用 /{your command name}来使用。

（1）方法 1：通过聊天界面（推荐）

在 Cursor 的 AI 聊天界面中，你可以：

1. 直接提及命令名称，例如："请执行 code-review 命令"

2. 或者描述任务，AI 可能会自动识别并使用相应的命令

（2）方法 2：通过命令面板

1. 在 Cursor 中按 `Ctrl+Shift+P` (Windows/Linux) 或 `Cmd+Shift+P` (Mac) 打开命令面板

2. 输入 "Cursor: Run Command" 或类似的关键词

3. 选择要执行的命令

4. 如果需要，提供额外的参数或上下文

（3）方法 3：通过 @ 符号引用

某些情况下，你可以使用 `@commands/code-review` 这样的格式来引用命令。

二、文档格式

使用 Markdown 格式，包含以下部分：

1. YAML Front Matter（元数据）

```yaml

---

description: 命令的简短描述，用于在命令列表中显示

---

```

2. 命令内容

命令内容使用 Markdown 编写，可以包含：

• **指令说明**：告诉 AI 如何执行任务

• **步骤流程**：详细的操作步骤

• **检查清单**：需要验证的项目

• **输出格式**：期望的输出格式

• **工具使用**：应该使用的工具和 API

3. 参数支持

使用 `#$ARGUMENTS` 占位符来接收用户提供的参数：

```markdown

> #$ARGUMENTS

```

当用户调用命令时，可以提供额外的上下文或参数，这些内容会替换 `#$ARGUMENTS` 占位符。

三、demo

下面几个demo的前提：我已经配置了一些git、jira相关的mcp tool

1、code-review

---
description: Review code changes from GitLab MR, git commit, or file content
---

Review the content provided by the user and provide actionable feedback.

> #$ARGUMENTS

## First: Create Todo List

For complex reviews, use the `todo_write` tool to track progress:

1. **Fetch and understand changes** - Get the code/MR/commit details
2. **Analyze code quality** - Check against project standards
3. **Identify issues** - Bugs, security, performance concerns
4. **Provide feedback** - Post comments or respond directly

Update todo status as you progress. Skip for simple single-file reviews.

## Context

- [code-review-standards](../../docs/content/docs/guide/code-review-standards.mdx) - Code review standards and checklist
- For GitLab MR: Use `mcp_gitlab_get_merge_request` and `mcp_gitlab_get_merge_request_diffs`
- For git commit: !`git show <commit-hash>`

## Process Overview

**Step 1: Fetch and understand the changes**

- Identify the type of review (MR, commit, or file)
- Gather all relevant code changes
- Understand the intent and scope of changes

**Step 2: Analyze against checklist**

Review for the following categories:

### Code Quality

- [ ] Follows project coding standards (see CLAUDE.md)
- [ ] Proper naming conventions
- [ ] No code duplication (DRY principle)
- [ ] Appropriate abstraction level

### Correctness & Safety

- [ ] Logic is correct and handles edge cases
- [ ] Error handling is appropriate
- [ ] No potential null/undefined issues
- [ ] No security vulnerabilities (XSS, injection, etc.)

### Architecture & Design

- [ ] Follows established patterns in the codebase
- [ ] Proper separation of concerns
- [ ] Changes are cohesive (single responsibility)
- [ ] No unnecessary dependencies introduced

### Performance

- [ ] No obvious performance issues
- [ ] Appropriate use of memoization/caching where needed
- [ ] No unnecessary re-renders (for React components)

### Testing & Documentation

- [ ] Tests added/updated for new functionality
- [ ] Comments explain "why" not "what"
- [ ] API changes documented

**Step 3: Provide feedback**

Categorize findings by severity:

- `🔴 CRITICAL:` Must fix before merge (bugs, security issues)
- `🟠 IMPORTANT:` Should fix, significant quality concern
- `🟡 SUGGESTION:` Nice to have improvement

## Output Format

### For GitLab MR

1. **Inline comments** for specific code issues:
    - Use `mcp_gitlab_create_merge_request_thread` for line-level feedback
    - Include code suggestions when applicable
    - Reference the severity level

2. **Summary comment** on the MR:
    - Overall assessment (Approve / Request Changes / Comment)
    - High-level feedback and patterns noticed
    - Positive observations (what was done well)

### For Commit/File

Provide the review directly in response with:

- Summary of changes understood
- List of findings with severity
- Specific code suggestions using markdown code blocks

---

## Quick Reference

| Review Type | Tools to Use                         | Output Method             |
| ----------- | ------------------------------------ | ------------------------- |
| GitLab MR   | `mcp_gitlab_get_merge_request_diffs` | Inline comments + Summary |
| Git commit  | `git show`                           | Direct response           |
| File/code   | Read file directly                   | Direct response           |

| Severity      | When to Use                              |
| ------------- | ---------------------------------------- |
| 🔴 CRITICAL   | Blocks merge - bugs, security, data loss |
| 🟠 IMPORTANT  | Should fix - significant quality issues  |
| 🟡 SUGGESTION | Could improve - better patterns exist    |

Begin your review now.

2、自动提交并创建MR

（1）基础版

---
name: /git-nice.md
id: git-nice
category: dev-tool
description: 根据要求提交本地改动内容并创建 Merge Request
---

你将作为资深 Git 提交助手执行一次提交准备流程，目标是：排除 .DS_Store、生成严格符合 Conventional Commits 的高质量 commit message，并在提交前给出变更摘要与确认提示。提交成功后，可选择创建 Merge Request。

硬性约束：
- **必须携带 JIRA ID**：使用该命令时必须提供 JIRA ID（格式：task-12345），否则拒绝执行
  - 如果当前分支名中包含 task-12345 格式，则从分支名中提取作为 JIRA ID，此时不强制要求用户手动提供
- commit message 最前方必须携带 JIRA ID，格式：`task-12345: <type>(<scope>)< !?>: <subject>`
- 永远排除 .DS_Store（无论 tracked/untracked）
- commit message 必须来自 staged diff 的"代码语义"，不得仅根据文件名/路径猜测
- 生成 Conventional Commits：<type>(<scope>)< !?>: <subject>
  - subject：祈使语气、首字母小写、不加句号，尽量 <= 72 字符
  - body：使用项目符号，说明"做了什么 + 为什么"，每条 bullet 必须能在 diff 中找到依据
  - 若检测到破坏性变更：必须使用 ! 或 footer `BREAKING CHANGE: ...`
- commit message 必须使用英文描述，
- 提交前必须展示：
  1) git diff --cached --stat
  2) 生成的 commit message
  3) 询问确认 (y/N)
- 除非用户明确要求自动提交，否则不得直接 commit

流程：
0) **检查并验证 JIRA ID**：
   a) **提取 JIRA ID**（按优先级顺序）：
      - 首先尝试从当前分支名中提取 JIRA ID（格式：task-12345）
        - 运行 `git branch --show-current` 获取当前分支名
        - 使用正则表达式 `task-\d+` 从分支名中提取 JIRA ID
      - 如果分支名中未找到，则从用户输入中提取 JIRA ID（格式：task-12345）
      - 如果仍未找到，输出错误信息并拒绝执行："错误：必须提供 JIRA ID（格式：task-12345），可通过分支名或用户输入提供"
   
   b) **验证 JIRA ID 格式**：
      - 验证 JIRA ID 格式是否正确（task-后跟数字）
      - 格式不正确则拒绝执行
   
   c) **验证 JIRA 是否存在**：
      - 调用 MCP 工具 `get_jira_issue`，传入提取到的 JIRA ID（如 task-12345）
      - 如果 JIRA 不存在或调用失败，输出错误信息并拒绝执行："错误：JIRA {JIRA_ID} 不存在或无法访问"
   
   d) **验证 JIRA 归属**：
      - 调用 MCP 工具 `get_current_user` 获取当前用户信息
      - 从 `get_jira_issue` 返回结果中获取 JIRA 的 assignee 或 reporter 字段
      - 检查 JIRA 的 assignee 或 reporter 是否与当前用户匹配
      - 如果不匹配，输出警告信息："警告：JIRA {JIRA_ID} 不属于当前用户，是否继续？(y/N)"
      - 用户确认后才继续，否则拒绝执行
   
   e) **验证通过后继续**：
      - 所有验证通过后，保存 JIRA ID 供后续步骤使用
      - 继续执行步骤 1 及后续流程
1) 运行 `git status` 并展示关键结论（modified/new/deleted 数量）。
2) 暂存全部改动并移除 .DS_Store：
   - git add -A
   - git reset HEAD .DS_Store 2>/dev/null || true
   - git restore --staged .DS_Store 2>/dev/null || true
3) **检查暂存区和未 push 的 commit**：
   - 如果暂存区为空：
     a) 检查是否有未 push 到远程的 commit：
        - 运行 `git branch --show-current` 获取当前分支名（保存为 branchName）
        - 运行 `git ls-remote --heads origin {branchName}` 检查远程分支是否存在
        - **判断**：
          - 如果远程分支存在：
            - 运行 `git rev-list --count origin/{branchName}..HEAD` 获取未 push 的 commit 数量
            - 如果返回值为 0 或命令失败，说明没有未 push 的 commit
            - 如果返回值 > 0，说明有未 push 的 commit（数量为返回值）
          - 如果远程分支不存在：
            - 运行 `git rev-list --count HEAD` 或 `git log --oneline | wc -l` 检查本地 commit 数量
            - 如果返回值为 0，说明没有本地 commit，因此没有未 push 的 commit
            - 如果返回值 > 0，说明有未 push 的 commit（因为远程分支不存在，所有本地 commit 都是未 push 的）
     b) **判断**：
        - 如果有未 push 的 commit：
          - 输出："当前分支没有待提交的改动，但检测到未 push 的 commit，将直接创建 Merge Request"
          - 跳转到步骤 10（创建 Merge Request），标记为"从步骤3跳转"
        - 如果没有未 push 的 commit：
          - 输出"无可提交改动"并结束
   - 如果暂存区不为空，继续执行步骤 4
4) 变更分析（只基于 staged）：
   - 先展示 `git diff --cached --stat` 与 `git diff --cached --name-status`
   - 阅读 `git diff --cached`，并做结构化提取：
     A. 行为变化（新增/修改功能、修复 bug）
     B. API/路由/配置/数据结构变化（导出、endpoint、schema、字段）
     C. 错误处理与边界条件
     D. 测试覆盖变化（新增断言说明的行为）
     E. 仅重构/格式化/构建脚本/依赖更新
   - 识别"主变更主题"与"次要伴随变更"
   - 若出现多个不相关主题（例如 feat + fix + docs 混杂且跨模块），提出拆分提交建议（但不要自动拆分）。
5) type 选择规则（按行为主导，不按路径武断判定）：
   - fix：修复错误、异常处理、纠正逻辑、修复回归
   - feat：新增对用户/调用方可见能力
   - docs：仅文档，且不影响运行逻辑
   - test：仅测试相关
   - chore：配置、工具、依赖、CI、脚本、非功能性调整
   （如你项目允许，可额外使用 refactor/build/style/perf；否则归入 chore）
6) scope 生成规则：
   - 从代码语义推断模块/子系统（如 api/auth, ui/modal, db/migrations, config 等）
   - 不确定则省略 scope（不要乱写）
7) 输出 commit message：
   - **格式**：`<JIRA_ID>: <type>(<scope>)< !?>: <subject>`
   - subject：一句话概括"主变更主题"
   - body：3--8 条 bullets，覆盖关键行为变化、原因/影响面，最后一条写统计：`- stats: X files changed, +A -D`
   - 示例：`task-12345: fix(router): correct queue assignment logic`
7.5) **AI Code Review**：
   a) **获取待审查的文件列表**：
      - 运行 `git diff --cached --name-only` 获取暂存区的所有文件路径
      - 过滤出代码文件（Java、Kotlin、Python、JavaScript、TypeScript 等，排除配置文件、文档等）
   
   b) **执行代码检查**：
      - 使用 `read_lints` 工具检查所有暂存区文件的 linter 错误
      - 读取每个变更的代码文件，分析代码逻辑：
        - 潜在的 bug（空指针、数组越界、逻辑错误等）
        - 性能问题（不必要的循环、资源泄漏等）
        - 安全问题（敏感信息泄露、注入风险等）
        - 代码规范问题（违反项目编码规范）
        - 错误处理缺失或不完善
        - 边界条件处理
   
   c) **生成审查报告**：
      - 如果发现问题：
        - 列出所有发现的问题，按严重程度分类：
          - **错误（Error）**：编译错误、语法错误、linter 错误
          - **警告（Warning）**：潜在的 bug、代码规范问题
          - **建议（Suggestion）**：代码优化建议、最佳实践
        - 对每个问题提供：
          - 问题描述
          - 问题位置（文件路径和行号）
          - 修改建议（具体的代码修改方案）
          - 问题影响（可能导致的后果）
      - 如果没有发现问题：
        - 输出："代码审查通过，未发现明显问题"
   
   d) **处理审查结果**：
      - 如果发现问题：
        - 输出完整的审查报告
        - 询问用户："发现 {N} 个问题，是否修复？(y/N/skip)"
          - y/Y：修复所有问题
          - N：不修复，继续提交（需要用户明确确认）
          - skip：跳过修复，直接继续（等同于 N，但更明确）
        - **如果用户选择修复（y/Y）**：
          - 按照修改建议修复所有问题
          - 修复后重新暂存文件：`git add {修复的文件路径}`
          - 重新执行步骤 4-7（重新分析变更、生成 commit message）
          - 修复完成后，再次执行步骤 7.5（code review），确保问题已解决
        - **如果用户选择不修复（N/skip）**：
          - 输出警告："警告：代码存在问题但未修复，继续提交可能导致问题"
          - 询问用户："确认继续提交？(y/N)"
          - 如果用户确认（y/Y），继续执行步骤 8
          - 如果用户不确认（N），停止流程
      - 如果没有发现问题：
        - 直接继续执行步骤 8
8) 询问确认：
   - 显示"是否提交这些改动？(y/N)"
   - y/Y 才执行 git commit -m "..."; 否则停止
9) 提交后输出：
   - git log -1 --pretty=format:"%H%n%an <%ae>%n%ad%n%n%s%n%n%b" --date=format:"%Y-%m-%d %H:%M:%S"
10) **创建 Merge Request（可选）**：
    a) **判断是否需要创建 MR**：
       - **判断**：
         - 如果是从步骤 3 跳转过来的（无可提交改动但有未 push commit）：
           - 直接继续执行后续步骤，无需询问用户
         - 如果是提交成功后进入此步骤：
           - 询问用户："是否创建 Merge Request？(y/N)"
           - 如果用户选择 N 或未响应，跳过此步骤
           - 如果用户选择 y/Y，继续执行后续步骤
    
    b) **获取分支和 commit 信息**：
       - 运行 `git branch --show-current` 获取当前分支名（sourceBranch）
       - 运行 `git log -1 --pretty=format:"%s"` 获取最新 commit 的 subject（用于 MR title）
       - 运行 `git log -1 --pretty=format:"%b"` 获取最新 commit 的 body（用于 MR description）
       - 运行 `git remote get-url origin` 获取远程仓库信息，解析出 repository（格式：group/project）
         - 示例：`git@git.task.us:wtyy/my-service-task.git` → `wtyy/my-service-task`
         - 示例：`https://git.task.us/wtyy/my-service-task.git` → `wtyy/my-service-task`
    
    c) **确定 target 分支**：
       - 检查当前分支名是否包含以下关键词：`_rl`、`release`、`rel`
       - 如果包含：targetBranch = `release`
       - 否则：targetBranch = `master`
    
    d) **Push 分支到远程**：
       - 运行 `git push origin {sourceBranch}`
       - 检查 push 输出中是否包含 MR 地址（通常包含 "merge_requests" 或 "merge request" 关键词）
       - **判断**：
         - 如果 push 输出中包含 MR 地址：
           - 提取并输出 MR URL："检测到已存在的 Merge Request: {MR_URL}"
           - 输出"MR 已存在，跳过创建步骤"
           - 流程结束
         - 如果 push 失败：
           - 检查错误信息，如果是分支已存在且需要 force push，询问用户："分支已存在，是否使用 --force-with-lease 强制推送？(y/N)"
           - 如果用户确认，运行 `git push origin {sourceBranch} --force-with-lease`
           - 再次检查 push 输出是否包含 MR 地址，如果包含则跳过创建
           - 如果其他错误，输出错误信息并询问是否继续创建 MR
         - 如果 push 成功且未检测到 MR 地址，继续下一步
    
    e) **创建 Merge Request**：
       - 调用 MCP 工具 `submit_merge_request`，参数如下：
         - repository: 从步骤 b) 解析得到的 repository（如 `wtyy/my-service-task`）
         - title: `{JIRA_ID}: {commit message subject}`（完整保留 commit message 的 subject 部分，包含 JIRA ID 前缀）
         - sourceBranch: 当前分支名
         - targetBranch: 根据步骤 c) 确定的 target 分支（`master` 或 `release`）
         - description: commit message 的 body 部分（如果有，保留原有的 bullet points 格式）
         - gitlabInstance: `default`（使用 git.task.us）
       - 如果创建成功，输出 MR 信息：
         - MR ID、标题、源分支、目标分支、仓库、URL
       - 如果创建失败，输出错误信息并提示用户手动创建

（2）进阶版

支持交互式确认，更能节省 token，一次 request 点点点即可

---
name: /git-nice.md
id: git-nice
category: dev-tool
description: 根据要求提交本地改动内容并创建 Merge Request
---

你将作为资深 Git 提交助手执行一次提交准备流程，目标是：排除 .DS_Store、生成严格符合 Conventional Commits 的高质量 commit message，并在提交前给出变更摘要与确认提示。提交成功后，可选择创建 Merge Request。

交互式执行要求（Click-only，多轮对话）：
- 本命令必须支持"一次触发 request"，后续所有需要用户决策的步骤都必须通过 Cursor 的可点击选项对话框完成（不要让用户在聊天框里输入 y/N/skip 或任何自由文本）。
- 任何确认/选择必须使用结构化多选/单选问题（例如 AskQuestion），并提供明确选项按钮。
- 若必须提供但无法从环境自动推断的信息（例如 JIRA ID）缺失，则必须引导用户通过"点击选项"来终止流程，并给出下一步操作（例如重命名分支以包含 JIRA ID）；不要要求用户在对话框里手动输入字符串。
- 需要调用 MCP 工具时，必须遵循项目 MCP 约束：先读取对应工具 schema/descriptor，再调用 MCP 工具。

硬性约束：
- **必须携带 JIRA ID**：使用该命令时必须提供 JIRA ID（格式：wtyy-12345），否则拒绝执行
  - 如果当前分支名中包含 wtyy-12345 格式，则从分支名中提取作为 JIRA ID，此时不强制要求用户手动提供
- commit message 最前方必须携带 JIRA ID，格式：`wtyy-12345: <type>(<scope>)< !?>: <subject>`
- 永远排除 .DS_Store（无论 tracked/untracked）
- commit message 必须来自 staged diff 的"代码语义"，不得仅根据文件名/路径猜测
- 生成 Conventional Commits：<type>(<scope>)< !?>: <subject>
  - subject：祈使语气、首字母小写、不加句号，尽量 <= 72 字符
  - body：使用项目符号，说明"做了什么 + 为什么"，每条 bullet 必须能在 diff 中找到依据
  - 若检测到破坏性变更：必须使用 ! 或 footer `BREAKING CHANGE: ...`
- commit message 必须使用英文描述，
- 提交前必须展示：
  1) git diff --cached --stat
  2) 生成的 commit message
  3) 通过可点击选项询问确认（禁止 y/N 文本交互）
- 除非用户明确要求自动提交，否则不得直接 commit

流程：
0) **检查并验证 JIRA ID**：
   a) **提取 JIRA ID**（按优先级顺序）：
      - 首先尝试从当前分支名中提取 JIRA ID（格式：wtyy-12345）
        - 运行 `git branch --show-current` 获取当前分支名
        - 使用正则表达式 `wtyy-\d+` 从分支名中提取 JIRA ID
      - 如果分支名中未找到：
        - 必须弹出可点击选项对话框（单选），仅允许：
          - 终止流程，并提示用户将分支重命名为包含 `wtyy-12345` 的格式（示例：`git branch -m feature/wtyy-12345-something`）
          - 终止流程（不继续）
        - 不允许要求用户在聊天框手动输入 JIRA ID（因为本命令要求 click-only）
   
   b) **验证 JIRA ID 格式**：
      - 验证 JIRA ID 格式是否正确（wtyy-后跟数字）
      - 格式不正确则拒绝执行
   
   c) **验证 JIRA 是否存在**：
      - 调用 MCP 工具 `get_jira_issue`，传入提取到的 JIRA ID（如 wtyy-12345）
      - 如果 JIRA 不存在，输出错误信息并拒绝执行："错误：JIRA {JIRA_ID} 不存在或无法访问"
      - 如果 MCP 工具调用因"工具能力/参数传递限制/临时故障"而失败（非确定性地证明 JIRA 不存在）：
        - 必须输出警告："警告：无法通过 MCP 验证 JIRA 是否存在（工具调用失败），将进入降级流程"
        - 必须弹出可点击选项对话框（单选）：
          - 终止（abort，recommended）
          - 继续但跳过 JIRA 存在性校验（continue without JIRA validation）
        - 若用户选择继续，后续 commit/MR 仍必须保留 JIRA 前缀，但需要在总结中提示本次未完成 JIRA 校验
   
   d) **验证 JIRA 归属**：
      - 调用 MCP 工具 `get_current_user` 获取当前用户信息
      - 从 `get_jira_issue` 返回结果中获取 JIRA 的 assignee 或 reporter 字段
      - 检查 JIRA 的 assignee 或 reporter 是否与当前用户匹配
      - 如果不匹配，必须弹出可点击选项对话框（单选）：
        - 继续（continue）
        - 终止（abort）
   
   e) **验证通过后继续**：
      - 所有验证通过后，保存 JIRA ID 供后续步骤使用
      - 继续执行步骤 1 及后续流程
1) 运行 `git status` 并展示关键结论（modified/new/deleted 数量）。
2) 暂存全部改动并移除 .DS_Store：
   - 在执行暂存前，必须弹出可点击选项对话框（单选）：
     - 继续暂存并清理（stage and continue）
     - 终止（abort）
   - git add -A
   - git reset HEAD .DS_Store 2>/dev/null || true
   - git restore --staged .DS_Store 2>/dev/null || true
3) **检查暂存区和未 push 的 commit**：
   - 如果暂存区为空：
     a) 检查是否有未 push 到远程的 commit：
        - 运行 `git branch --show-current` 获取当前分支名（保存为 branchName）
        - 运行 `git ls-remote --heads origin {branchName}` 检查远程分支是否存在
        - **判断**：
          - 如果远程分支存在：
            - 运行 `git rev-list --count origin/{branchName}..HEAD` 获取未 push 的 commit 数量
            - 如果返回值为 0 或命令失败，说明没有未 push 的 commit
            - 如果返回值 > 0，说明有未 push 的 commit（数量为返回值）
          - 如果远程分支不存在：
            - 运行 `git rev-list --count HEAD` 或 `git log --oneline | wc -l` 检查本地 commit 数量
            - 如果返回值为 0，说明没有本地 commit，因此没有未 push 的 commit
            - 如果返回值 > 0，说明有未 push 的 commit（因为远程分支不存在，所有本地 commit 都是未 push 的）
     b) **判断**：
        - 如果有未 push 的 commit：
          - 输出："当前分支没有待提交的改动，但检测到未 push 的 commit，将直接创建 Merge Request"
          - 跳转到步骤 10（创建 Merge Request），标记为"从步骤3跳转"
        - 如果没有未 push 的 commit：
          - 输出"无可提交改动"并结束
   - 如果暂存区不为空，继续执行步骤 4
4) 变更分析（只基于 staged）：
   - 先展示 `git diff --cached --stat` 与 `git diff --cached --name-status`
   - 阅读 `git diff --cached`，并做结构化提取：
     A. 行为变化（新增/修改功能、修复 bug）
     B. API/路由/配置/数据结构变化（导出、endpoint、schema、字段）
     C. 错误处理与边界条件
     D. 测试覆盖变化（新增断言说明的行为）
     E. 仅重构/格式化/构建脚本/依赖更新
   - 识别"主变更主题"与"次要伴随变更"
   - 若出现多个不相关主题（例如 feat + fix + docs 混杂且跨模块）：
     - 必须提出拆分提交建议（但不要自动拆分）
     - 并弹出可点击选项对话框（单选）：
       - 继续单提交（proceed as single commit）
       - 终止以便手动拆分（abort to split commits）
5) type 选择规则（按行为主导，不按路径武断判定）：
   - fix：修复错误、异常处理、纠正逻辑、修复回归
   - feat：新增对用户/调用方可见能力
   - docs：仅文档，且不影响运行逻辑
   - test：仅测试相关
   - chore：配置、工具、依赖、CI、脚本、非功能性调整
   （如你项目允许，可额外使用 refactor/build/style/perf；否则归入 chore）
6) scope 生成规则：
   - 从代码语义推断模块/子系统（如 api/auth, ui/modal, db/migrations, config 等）
   - 不确定则省略 scope（不要乱写）
7) 输出 commit message：
   - **格式**：`<JIRA_ID>: <type>(<scope>)< !?>: <subject>`
   - subject：一句话概括"主变更主题"
   - body：3--8 条 bullets，覆盖关键行为变化、原因/影响面，最后一条写统计：`- stats: X files changed, +A -D`
   - 示例：`wtyy-12345: fix(router): correct queue assignment logic`
7.5) **AI Code Review**：
   - 在执行代码审查前，必须弹出可点击选项对话框（单选）：
     - 执行代码审查（run review, recommended）
     - 跳过代码审查（skip review）
   - 若用户选择跳过，直接进入步骤 8

   a) **获取待审查的文件列表**：
      - 运行 `git diff --cached --name-only` 获取暂存区的所有文件路径
      - 过滤出代码文件（Java、Kotlin、Python、JavaScript、TypeScript 等，排除配置文件、文档等）
   
   b) **执行代码检查**：
      - 使用 `ReadLints` 工具检查所有暂存区文件的 linter 错误
      - 读取每个变更的代码文件，分析代码逻辑：
        - 潜在的 bug（空指针、数组越界、逻辑错误等）
        - 性能问题（不必要的循环、资源泄漏等）
        - 安全问题（敏感信息泄露、注入风险等）
        - 代码规范问题（违反项目编码规范）
        - 错误处理缺失或不完善
        - 边界条件处理
   
   c) **生成审查报告**：
      - 如果发现问题：
        - 列出所有发现的问题，按严重程度分类：
          - **错误（Error）**：编译错误、语法错误、linter 错误
          - **警告（Warning）**：潜在的 bug、代码规范问题
          - **建议（Suggestion）**：代码优化建议、最佳实践
        - 对每个问题提供：
          - 问题描述
          - 问题位置（文件路径和行号）
          - 修改建议（具体的代码修改方案）
          - 问题影响（可能导致的后果）
      - 如果没有发现问题：
        - 输出："代码审查通过，未发现明显问题"
   
   d) **处理审查结果**：
      - 如果发现问题：
        - 输出完整的审查报告
        - 必须弹出可点击选项对话框（单选）：
          - 修复并继续（fix and continue）
          - 忽略问题继续（continue without fixing）
          - 终止（abort）
        - **如果用户选择修复并继续**：
          - 按照修改建议修复所有问题
          - 修复后重新暂存文件：`git add {修复的文件路径}`
          - 重新执行步骤 4-7（重新分析变更、生成 commit message）
          - 修复完成后，再次执行步骤 7.5（code review），确保问题已解决
        - **如果用户选择忽略问题继续**：
          - 输出警告："警告：代码存在问题但未修复，继续提交可能导致问题"
          - 再次弹出可点击选项对话框（单选）：
            - 确认继续（confirm continue）
            - 终止（abort）
      - 如果没有发现问题：
        - 直接继续执行步骤 8
8) 询问确认：
   - 必须弹出可点击选项对话框（单选）：
     - 提交（commit now）
     - 不提交（abort / stop）
   - 只有用户选择"提交"才允许执行 `git commit -m "..."`；否则停止
9) 提交后输出：
   - git log -1 --pretty=format:"%H%n%an <%ae>%n%ad%n%n%s%n%n%b" --date=format:"%Y-%m-%d %H:%M:%S"
10) **创建 Merge Request（可选）**：
    a) **判断是否需要创建 MR**：
       - **判断**：
         - 如果是从步骤 3 跳转过来的（无可提交改动但有未 push commit）：
           - 直接继续执行后续步骤，无需询问用户
         - 如果是提交成功后进入此步骤：
           - 必须弹出可点击选项对话框（单选）：
             - 创建 Merge Request（create MR）
             - 跳过（skip）
    
    b) **获取分支和 commit 信息**：
       - 运行 `git branch --show-current` 获取当前分支名（sourceBranch）
       - 运行 `git log -1 --pretty=format:"%s"` 获取最新 commit 的 subject（用于 MR title）
       - 运行 `git log -1 --pretty=format:"%b"` 获取最新 commit 的 body（用于 MR description）
       - 运行 `git remote get-url origin` 获取远程仓库信息，解析出 repository（格式：group/project）
         - 示例：`git@git.wtyy.us:my/my-service-wtyy.git` → `my/my-service-wtyy`
         - 示例：`https://git.wtyy.us/my/my-service-wtyy.git` → `my/my-service-wtyy`
    
    c) **确定 target 分支**：
       - 检查当前分支名是否包含以下关键词：`_rl`、`release`、`rel`
       - 如果包含：targetBranch = `release`
       - 否则：targetBranch = `master`
    
    d) **Push 分支到远程**：
       - 运行 `git push origin {sourceBranch}`
       - 检查 push 输出中是否包含 MR 地址（通常包含 "merge_requests" 或 "merge request" 关键词）
       - **判断**：
         - 如果 push 输出中包含 MR 地址：
           - 提取并输出 MR URL："检测到已存在的 Merge Request: {MR_URL}"
           - 输出"MR 已存在，跳过创建步骤"
           - 流程结束
         - 如果 push 失败：
           - 检查错误信息，如果是分支已存在且需要 force push，必须弹出可点击选项对话框（单选）：
             - 使用 `--force-with-lease` 重试 push（force-with-lease）
             - 终止（abort）
           - 如果用户选择重试，运行 `git push origin {sourceBranch} --force-with-lease`
           - 再次检查 push 输出是否包含 MR 地址，如果包含则跳过创建
           - 如果其他错误，必须弹出可点击选项对话框（单选）：
             - 重试 push（retry push）
             - 跳过创建 MR（skip MR creation）
             - 终止（abort）
           - 若用户选择重试 push，则再次执行 `git push origin {sourceBranch}` 并重复本步骤判断逻辑
         - 如果 push 成功且未检测到 MR 地址，继续下一步
    
    e) **创建 Merge Request**：
       - 调用 MCP 工具 `submit_merge_request`，参数如下：
         - repository: 从步骤 b) 解析得到的 repository（如 `my/my-service-wtyy`）
         - title: `{JIRA_ID}: {commit message subject}`（完整保留 commit message 的 subject 部分，包含 JIRA ID 前缀）
         - sourceBranch: 当前分支名
         - targetBranch: 根据步骤 c) 确定的 target 分支（`master` 或 `release`）
         - description: commit message 的 body 部分（如果有，保留原有的 bullet points 格式）
         - gitlabInstance: `default`（使用 git.wtyy.us）
       - 如果创建成功，输出 MR 信息：
         - MR ID、标题、源分支、目标分支、仓库、URL
       - 如果创建失败，输出错误信息并提示用户手动创建

3、自动创建Git分支

---
name: /git-check.md
id: git-check
category: dev-tool
description: Create and checkout development branches based on JIRA issue fixVersion
---

You will act as a Git branch management assistant to create and checkout development branches based on JIRA issue information.

Hard constraints:
- **Must provide JIRA ID**: The command requires a JIRA ID parameter (format: wtyy-12345)
- Branch names follow the pattern: `dev/{username}_{version}_{JIRA_ID}` and `dev/{username}_{version}_{JIRA_ID}_rl`
- If local branches exist, checkout directly; if there are uncommitted changes, stash them first
- Always pull latest code from origin/master and origin/release before creating branches

Process:
1) **Validate JIRA ID**:
   a) Extract JIRA ID from user input (format: wtyy-12345)
   b) Validate JIRA ID format (wtyy- followed by numbers)
   c) Call MCP tool `get_jira_issue` with the JIRA ID
   d) If JIRA doesn't exist or call fails, output error and abort: "Error: JIRA {JIRA_ID} does not exist or cannot be accessed"

2) **Extract fixVersion**:
   a) From `get_jira_issue` result, get the `fixVersions` field
   b) Extract version number from fixVersion (e.g., "wtyy 1.1.0" -> "1.1.0")
   c) If fixVersion is not found or empty, output error and abort: "Error: JIRA {JIRA_ID} does not have a fixVersion"
   d) Version extraction rules:
      - Look for patterns like "wtyy 1.1.0", "1.1.0", "v1.1.0", etc.
      - Extract the semantic version number (major.minor.patch format)
      - If multiple fixVersions exist, use the first one

3) **Get current user**:
   a) Call MCP tool `get_current_user` to get current user information
   b) Extract user name (e.g., "wtyy")
   c) Convert user name to branch-friendly format:
      - Extract the first name (before the first space)
      - Convert to lowercase
      - Example: "wtyywtyy" -> "wtyy"

4) **Check for uncommitted changes**:
   a) Run `git status --porcelain` to check for uncommitted changes
   b) If there are uncommitted changes:
      - Output: "Warning: Uncommitted changes detected. Stashing changes..."
      - Run `git stash push -m "Auto-stash before checkout: {JIRA_ID}"`
      - Confirm stash was successful

5) **Create/checkout master branch**:
   a) Branch name: `dev/{username}_{version}_{JIRA_ID}`
      Example: `dev/wtyy_1.1.0_wtyy-12345`
   b) Fetch latest from origin/master: `git fetch origin master`
   c) Check if local branch exists:
      - Run `git show-ref --verify --quiet refs/heads/{branch_name}`
      - If exists: checkout the branch, then pull latest: `git checkout {branch_name} && git pull origin master`
      - If not exists: Create and checkout branch from origin/master: `git checkout -b {branch_name} origin/master`

6) **Create/checkout release branch**:
   a) Branch name: `dev/{username}_{version}_{JIRA_ID}_rl`
      Example: `dev/wtyy_1.1.0_wtyy-12345_rl`
   b) Fetch latest from origin/release: `git fetch origin release`
   c) Check if local branch exists:
      - Run `git show-ref --verify --quiet refs/heads/{branch_name}`
      - If exists: checkout the branch, then pull latest: `git checkout {branch_name} && git pull origin release`
      - If not exists: Create and checkout branch from origin/release: `git checkout -b {branch_name} origin/release`

7) **Final checkout**:
   a) By default, checkout the master branch (without _rl suffix)
   b) Output summary:
      - JIRA ID: {JIRA_ID}
      - Version: {version}
      - User: {username}
      - Master branch: {master_branch_name} (current)
      - Release branch: {release_branch_name}
      - If changes were stashed, remind user: "Uncommitted changes were stashed. Use 'git stash pop' to restore them."

Example usage:
- Input: `git-checkout wtyy-12345`
- Output:
  ```
  JIRA ID: wtyy-12345
  Version: 1.1.0
  User: wtyy
  Master branch: dev/wtyy_1.1.0_wtyy-12345 (current)
  Release branch: dev/wtyy_1.1.0_wtyy-12345_rl
  ```

4、生成代码

比如我有一套逻辑数据文件（二）yml--使用demo_yaml文件demo-CSDN博客

新增字段需要修改这些文件：yml、xxxDTO.java、SettingBitEnum 布特枚举等，那么就可以创建一个command一键生成。

我曾经尝试过这些方法：

给一个之前的MR，告诉cursor按照这个MR新增xxx字段，结果cursor拿MR和我本地文件diff，把本地多余的文件都删除了。

后来我给cusor描述：我在yml文件配置了xxx字段，你仿照这个文件的其他字段帮我生成剩下的代码，这会带来几个问题：1是生成的结果可能还要微调；2是每次都需要我输入类似的prompt。所以不如一劳永逸写一个command，根据生成的代码微调这个command的prompt，做到一键生成代码。