提交 a1303c1e authored 作者: 陈泽健's avatar 陈泽健

chore(config): 添加 Claude Code 技能配置

- 创建 .claude/skills/ 目录结构
- 复制 GitCommit、CreateCMD、prd-code、prd-plan 技能
- 添加 CLAUDE.md 项目配置文件
Co-Authored-By: 's avatarClaude <noreply@anthropic.com>
上级 023f2e65
---
name: CreateCMD
description: 在当前目录打开指定数量的CMD窗口
---
在当前工作目录下打开指定数量的 CMD 命令提示符窗口。
## Usage
/CreateCMD [数量]
## Description
根据用户输入的数量,在当前工作目录下打开对应数量的 CMD 窗口。
**功能:**
- 询问用户需要打开的 CMD 窗口数量
- 在当前工作目录下打开指定数量的 CMD 窗口
- 每个窗口独立运行,互不影响
**示例:**
```
/CreateCMD 3 # 在当前目录打开 3 个 CMD 窗口
/CreateCMD # 会询问需要打开的数量,然后执行
```
**执行步骤:**
1. 如果用户未提供数量参数,使用 AskUserQuestion 询问用户需要打开几个 CMD 窗口(提供 1、2、3、4 作为常见选项,也可输入其他数量)
2. 获取当前工作目录路径(Windows 形式,如 `E:\GithubData\ubains-module-test`
3. **定位 claude 的完整路径**:在 bash 中运行 `which claude`,得到形如 `/e/nodejs/claude` 的路径,转换成 Windows 形式并补 `.cmd`,即 `E:\nodejs\claude.cmd`。原因是 `E:\nodejs` 不在 Windows PATH 里,新开的 cmd 窗口直接敲 `claude` 会报"不是内部或外部命令",必须用完整路径。
4. **生成一个临时批处理文件**(如 `E:\GithubData\ubains-module-test\.claude\skills\CreateCMD\_run_claude.bat`),内容分两行,避免 `&&` 复合命令在引号传递时被截断:
```bat
@echo off
cd /d <当前目录>
<claude 完整路径> --permission-mode bypassPermissions
```
5. **用真正的 Windows cmd `start` 打开 N 个窗口运行该 bat**。在 bash 中通过 `cmd.exe /c start` 调用(注意:bash 里直接写 `start` 会走 `/usr/bin/start` 这个 MSYS 封装脚本,它会把 `"cd ... && claude"` 这种复合命令的引号传坏,导致 claude 不执行):
```bash
for i in $(seq 1 N); do
MSYS_NO_PATHCONV=1 cmd.exe /c start "Claude $i" cmd /k "<bat 完整路径>"
done
```
6. 确认并告知用户已成功打开的窗口数量
**注意事项(两个坑,务必遵守):**
- **不要用裸 `start`**:bash 里的 `start` 解析为 `/usr/bin/start`(MSYS 封装),会损坏 `&&` 复合命令的引号,表现为窗口打开、cd 成功但 claude 不执行。必须用 `cmd.exe /c start` 走 Windows 原生 `start`,并加 `MSYS_NO_PATHCONV=1` 防止 MSYS 路径转换。
- **不要用裸 `claude`**`E:\nodejs` 不在 Windows PATH,cmd 窗口里找不到。必须用 `which claude` 推导出的 `claude.cmd` 完整路径。
- **用 .bat 文件承载命令序列**,而不是 `"cd ... && claude ..."` 单行,可彻底规避复合命令引号丢失问题。
- `/k` 参数确保窗口执行完命令后保持打开;工作目录设为 Claude Code 的当前工作目录。
- 数量上限建议不超过 10 个,避免系统资源占用过高。
@echo off
cd /d E:\github\ubains-module-test\develop
E:\nodejs\claude.cmd --permission-mode bypassPermissions
---
name: git-commit
description: 代码提交辅助 - 审查待提交文件、自动生成 Conventional Commits 信息、执行 git add/commit
---
代码提交辅助工具。审查当前工作区所有改动文件,过滤无关/临时文件,与用户确认提交范围后自动生成符合 Conventional Commits 规范的提交信息,执行提交。
## Usage
```
/git-commit # 审查所有改动并提交
/git-commit 仅审查 # 仅审查文件,不执行提交
```
## 执行流程
### 阶段 1:扫描与分类
1. **收集改动**:执行 `git status --porcelain``git diff --stat`,获取所有 staged 和 unstaged 文件
2. **获取变更摘要**:对每个改动文件,执行 `git diff` / `git diff --cached` 获取具体变更内容摘要
3. **分类标记**
| 分类 | 判定标准 | 标记 |
|------|----------|------|
| ✅ 应提交 | 源码/配置/文档/脚本/技能文件,有实质改动 | `✅` |
| ⚠️ 可疑 | 临时脚本(poll_*/ssh*/run_*.sh)、调试日志(.log)、一次性辅助脚本、重复文件(如 phase9_v2 与 phase9_robust 功能重复) | `⚠️` |
| ❌ 不应提交 | 编译产物、.pyc、node_modules、IDE 配置、系统文件(.DS_Store)、本地临时文件 | `❌` |
**关键判断规则:**
- 新 skill 目录(`.claude/skills/<name>/`)→ 如果是完整的功能 skill,✅;如果是空的或测试的,⚠️
- `AuxiliaryTool/ScriptTool/` 下的脚本 → 如果是已有脚本的重复/调试版本(如 `diag_*``check_*``fix_*`),⚠️ 提醒用户
- `AuxiliaryTool/ScriptTool/` 下的新目录 → 如果是独立功能模块,✅
- `.log` 文件 → ❌
-`_` 开头的文件 → 检查内容,可能是临时文件
- 中文路径文件 → 正常判断,不作为排除依据
### 阶段 2:展示与确认
以结构化表格展示所有文件及其分类:
```
====== 📋 待提交文件审查 ======
✅ 应提交(N 个):
| # | 文件 | 状态 | 变更概要 |
|---|------|------|----------|
| 1 | .gitignore | M | 新增 xxx 忽略规则 |
| 2 | ... | A | ... |
⚠️ 可疑(M 个):
| # | 文件 | 状态 | 原因 |
|---|------|------|------|
| 1 | phase9_fix_output.log | ?? | 调试日志,通常不提交 |
| 2 | ... | ?? | 临时诊断脚本 |
❌ 不应提交(K 个):
| # | 文件 | 原因 |
|---|------|------|
💡 建议排除的可疑文件:
- xxx(原因)
- yyy(原因)
是否按建议范围提交?(是/否/自定义)
```
使用 `AskUserQuestion` 让用户确认:
1. 是否按建议范围提交?
2. 如果有可疑文件,是否要包含某些可疑文件?
### 阶段 3:生成 Commit Message
根据用户确认的文件列表和变更内容,自动生成符合 [Conventional Commits](https://www.conventionalcommits.org/) 规范的提交信息。
**类型判定规则:**
| 类型 | 适用场景 |
|------|----------|
| `feat` | 新增功能、新脚本、新 skill、新工具 |
| `fix` | Bug 修复、脚本错误修正 |
| `docs` | 纯文档改动(PRD、README、注释) |
| `refactor` | 代码重构,不改变功能 |
| `chore` | 配置变更、依赖更新、构建脚本 |
| `test` | 测试相关 |
| `style` | 格式调整(不影响逻辑) |
| `perf` | 性能优化 |
**范围(scope)自动推断:**
| 范围 | 匹配规则 |
|------|----------|
| `deploy` | 文件在 `AuxiliaryTool/ScriptTool/RemoteDeploy/``自动化部署脚本/` |
| `docker` | 文件在 DM8-Docker 相关目录 |
| `monitor` | 文件在 `AuxiliaryTool/ScriptTool/ServiceMonitor/` 或定时脚本 |
| `skills` | 文件在 `.claude/skills/` |
| `middleware` | 文件在 `MiddlewareVerify/` |
| `config` | `.gitignore``config.json` 等配置文件 |
| `docs` | `Docs/` 目录 |
| `test` | 测试脚本 |
**生成格式:**
```
<type>(<scope>): <简短中文描述>
<详细说明(可选,列出每个主要变更)>
Co-Authored-By: Claude <noreply@anthropic.com>
```
**多类型混合**:如果改动涉及多种类型,使用主体类型 + 详细说明中列出其他改动。
**示例:**
```
feat(skills): 新增 git-commit 代码提交辅助技能
新增 .claude/skills/GitCommit/SKILL.md,提供文件审查、commit message 自动生成、交互式提交流程
Co-Authored-By: Claude <noreply@anthropic.com>
```
### 阶段 4:执行提交(🚨 双重确认门控,不可跳过)
**两道确认门,任何一道未通过都不执行 git 操作:**
- **门 1(范围确认)**:阶段 2 已确认提交哪些文件 —— 用户明确点头"按此范围提交"才进入下一步
- **门 2(message 确认)**:展示完整 commit message,**必须用 `AskUserQuestion` 让用户选择**
- ✅ 确认提交
- ✏️ 修改 message(用户给出修改意见后重新生成,再确认)
- ❌ 取消提交
**门 2 用户选"确认提交"后,才执行:**
1. `git add <确认的文件列表>`**逐文件 add,不使用 `git add -A` 或 `git add .`**
2. `git commit -m "<生成的 message>"`
3. **不要自动 push**:提交成功后告知用户,并询问是否需要 `git push`(push 也需用户明确同意才执行)
**推送规则(🚨 分支安全确认,不可跳过):**
在执行 `git push` 之前,必须执行以下检查:
1. **获取当前分支信息**:执行 `git branch --show-current` 获取当前分支名
2. **获取远程关联信息**:执行 `git remote -v` 获取远程仓库地址
3. **向用户确认**:使用 `AskUserQuestion` 展示以下信息并让用户确认:
- 当前分支名:`<branch-name>`
- 远程仓库:`<remote-url>`
- 推送目标:`origin <branch-name>`
- 确认选项:✅ 确认推送 / ❌ 取消推送
4. **只有用户明确确认后**,才执行 `git push origin <当前分支名>`**推送的目标分支必须与当前分支同名,不得推送到其他分支**
**禁止行为:**
- ❌ 跳过分支确认直接 push
- ❌ 将当前分支推送到非当前分支的远程分支(如从 `feature-a` 推送到 `master`
- ❌ 使用 `git push` 不带参数(依赖默认行为可能推错分支)
- ❌ 使用 `git push --force``git push -f`
- ❌ 把"提交 + push"打包执行,两者必须分别确认
**禁止行为:**
- ❌ 跳过任一确认门直接 add/commit
- ❌ 把"未明确拒绝"当作"同意"——必须用户主动确认才执行
- ❌ 一次性把"提交 + push"打包执行,两者必须分别确认
- ❌ 推送前不显示分支信息
- ❌ 推送到与当前分支不同的远程分支
## 注意事项
- **🚨 推送分支安全确认(最高优先级)**:push 前必须显示当前分支名和推送目标,用户明确确认后才能执行 `git push origin <当前分支名>`
- **🚨 禁止推送到非当前分支**:只能推送 `origin <当前分支>`,不能推送到其他分支
- **🚨 禁止使用 `git push` 不带参数或 `git push --force`**
- **绝不使用 `git add .` 或 `git add -A`**:必须逐文件 add,只添加用户确认的文件
- **不自动 push**:push 需用户明确指令
- **不修改 .gitignore**:如需添加忽略规则,提醒用户自行添加
- **commit message 末尾必须有 `Co-Authored-By: Claude <noreply@anthropic.com>`**
- **中文描述优先**:commit 摘要使用中文,与仓库已有提交风格保持一致
- **避免宽泛描述**:如"更新代码"、"修复bug",应具体到"修复 phase9 权限绑定后菜单不刷新问题"
- **审查优先于提交**:可疑文件宁可多确认,不可误提交
---
name: prd-code
description: 解析执行计划文档,生成或更新代码
---
Parse an execution plan document and generate or update code.
## Usage
/prd-code <执行计划文档路径>
## Description
解析执行计划文档,生成或更新代码。
**功能:**
- 读取指定的执行计划文档
- 分析任务分解和实施步骤
- 根据计划生成或更新对应的代码文件
**示例:**
```
/prd-code "Docs/PRD/服务自检/_PRD_服务自检需求文档_计划执行.md"
```
**执行步骤:**
1. 读取执行计划文档
2. 分析实施计划(任务分解、脚本文件、代码位置、配置参数、验收标准)
3. 检查现有代码
4. 生成或更新代码(新增功能、修改功能、遵循代码规范、添加注释)
5. 验证并输出修改摘要
**安全规则:**
- 不修改文件路径以外的任何文件
- 遵循现有代码风格和命名规范
- 添加必要的错误处理
- 不引入安全漏洞
---
name: prd-plan
description: 解析 PRD 需求文档,生成执行计划文档
---
Parse a PRD document and generate an execution plan.
## Usage
/prd-plan <需求文档路径>
## Description
解析 PRD 需求文档,生成执行计划文档。
**功能:**
- 读取指定的 PRD 需求文档
- 分析需求内容,提取关键任务和验收标准
- 生成对应的执行计划文档
**输出:**
- 执行计划文档命名为:`<需求文档名>_计划执行.md`
- 保存位置:与需求文档相同目录
**示例:**
```
/prd-plan "Docs/PRD/服务自检/_PRD_服务自检需求文档.md"
```
**执行步骤:**
1. 读取需求文档
2. 分析需求内容(项目背景、执行目标、任务模块、配置要求、验收标准)
3. 生成执行计划文档(包含:执行概述、任务分解与实施计划、验收标准、测试计划、风险评估、实施记录、后续工作、附录)
4. 显示生成的执行计划文档路径和摘要
# Troubleshoot AI Assistant
问题排查分析助手项目。
## 项目结构
```
skill/ # Claude Skills 源代码
├── code/web/ # Web 服务代码
└── **/SKILL.md # 技能定义文件
deploy/ # 部署相关文件
docs/ # 文档
config/ # 配置文件
```
## 可用技能
- `/git-commit` - 代码提交辅助
- `/CreateCMD` - 创建 CMD 窗口
- `/prd-code` - PRD 代码生成
- `/prd-plan` - PRD 计划执行
## 环境配置
`.env.example` 文件,使用环境变量管理敏感信息。
Markdown 格式
0%
您添加了 0 到此讨论。请谨慎行事。
请先完成此评论的编辑!
注册 或者 后发表评论