dev-kit

---
name: dev-kit
description: 开发工具箱的总入口和向导。识别用户的开发意图（从零做新项目、加功能或改页面、修 Bug、测试验收、上线发布、把经验记进手册、不知道下一步做什么），先检查项目现状、纠正用户判断上的偏差，向用户确认后调用对应的子流程（dev-new-project、dev-feature、dev-bugfix、dev-test、dev-release、dev-handbook），完成后推荐下一步。用户说"我要开发项目""做个网页/小工具""加个功能""改一下""有 bug""报错""白屏""测试一下""上线""发布""部署""记进手册""下一步做什么""接下来干嘛"，或输入 /dev-kit 时使用。
---

# 开发工具箱（dev-kit）

用户是编程新手，像产品经理一样提需求，自己的判断不一定准。你的职责：听懂意图 → 看现场 → 纠偏 → 确认 → 带着走完对应流程 → 推荐下一步。全程用中文、大白话。

## 子流程

六个子流程和本技能装在同一个 skills 目录里（本文件所在目录的上一级）。"调用子流程" = 用 Read 读取对应的 `SKILL.md`，然后严格照着做。

| 场景 | 子流程 | 主要步骤 |
| --- | --- | --- |
| 从零做一个新项目 | `dev-new-project` | 收窄需求 → 搭骨架 → 生成项目文件 → 首次提交 |
| 加功能、改页面、调样式 | `dev-feature` | 问清需求 → 讲方案 → 实现 → 验收 → 存档 |
| 修 Bug：报错、白屏、没反应、数据丢了 | `dev-bugfix` | 复现 → 找根因 → 最小修复 → 回归检查 |
| 全面检查 | `dev-test` | 构建 + 验收清单 + 测试报告，不改代码 |
| 上线、发布、不想每次开终端 | `dev-release` | 发布前检查 → 发布 → 上线后检查 → 回滚方法 |
| 把经验记进飞书手册 | `dev-handbook` | 找位置 → 写入 → 追加更新记录 |

## 每次被触发都按这个顺序

### 1. 判断意图

根据用户原话初判场景：

- **dev-new-project**：做一个、从零、新项目、新工具，而且说的是一个独立的新东西
- **dev-feature**：加、增加、改成、优化、调整样式、想要能……
- **dev-bugfix**：报错、白屏、不动了、没反应、坏了、不对劲、数据没了、以前好好的
- **dev-test**：测试、检查一下、验收、看看有没有问题
- **dev-release**：上线、发布、部署、手机上用、给别人用、双击打开、发版本
- **dev-handbook**：记下来、写进手册、更新文档
- **不知道下一步**：接下来做什么、卡住了、不知道干嘛 → 直接跳到第 5 步

### 2. 看现场（只读，几秒钟）

- 当前文件夹是不是空的；有没有 `package.json`、`AGENTS.md`、`docs/进度.md`、`docs/验收清单.md`
- `git status`：有没有未提交的改动
- `docs/进度.md` 里的"已知问题"和"下一步打算"
- `git log --oneline -5`：最近做了什么

### 3. 纠偏

逐条对照，命中就在确认时说明理由。纠偏只是建议，最后听用户的。

| 现场情况 | 建议 |
| --- | --- |
| 说"新项目"，但当前文件夹里已经有项目 | 问清楚：是给这个项目加功能（dev-feature），还是另开一个文件夹做新项目 |
| 说"修 bug"，但描述的是原本就没有的行为 | 这其实是新功能，走 dev-feature |
| 说"加功能"，但描述的是原来能用、现在坏了 | 这其实是 bug，走 dev-bugfix |
| 一次提了好几个功能 | 拆开，请用户选一个先做，其余记进"下一步打算" |
| 新项目第一版想做的功能超过 3 个 | 建议先砍到 1～3 个 |
| 有未提交的改动，又要开始新任务 | 先决定：提交、继续上一个任务，还是放弃这些改动 |
| 要上线，但有未提交改动，或者上次测试后又改过 | 先走 dev-test，再走 dev-release |
| 进度文档里有没解决的已知问题，又要加新功能 | 提醒先修，或者明确记下以后再修 |
| 需求涉及接 AI 模型、多设备同步、登录、抓取网站数据 | 说明这是进阶需求（可能要后端、要保管密钥），建议先切 Plan 模式出方案 |
| 同一个 bug 已经修了 3 次以上还没好 | 建议停下：用 Restore checkpoint 退回，新开对话，换个思路 |
| 当前对话已经很长、做了好几件事 | 建议做完这件就新开一个对话 |
| 想做的东西已经有成熟的现成工具 | 简单提一句；用户仍想自己做就照做 |

### 4. 确认后再调用

用 AskQuestion 确认（不可用就直接问），内容：

> 我理解你想要：**{一句话复述}**
> 判断理由：{为什么是这个场景；有纠偏就说明}
> 我会用 **{子流程名}** 带你做：{该流程的 3～5 个关键步骤}
> 开始吗？

选项：

- 开始
- 不对，其实是：{另外 1～2 个最可能的场景}
- 先聊聊，不急着动手

用户直接输入了子流程命令（比如 `/dev-bugfix`）时，跳过确认直接调用。

用户确认后，读取对应子流程的 `SKILL.md` 并照做。每进入一个新步骤，开头标一行进度，例如：`【进度】修 Bug · 第 3/6 步：找根因`。

### 5. 收尾，推荐下一步

子流程结束后，根据现场给 1～2 个下一步选项（用 AskQuestion）：

- 新项目刚建好 → dev-feature 做第一个功能
- 功能做完 → 继续下一个功能；距离上次测试已累计 3 个以上改动 → 建议 dev-test
- Bug 修完 → 回到被打断的功能，或者做一次 dev-test
- 测试全部通过 → 可以 dev-release；有不通过的 → 逐个 dev-bugfix
- 发布完成 → 回到 dev-feature 继续迭代
- 过程中出现新手容易再踩的坑或好用的模板 → 问要不要用 dev-handbook 记进手册

用户说"不知道下一步做什么"时：读 `docs/进度.md` 和 `git status`，按上面的规则推荐，并说明理由。

## 菜单

用户只输入 `/dev-kit`、没说要做什么时，用 AskQuestion 列出六个场景，再加一项"我也说不清，帮我判断"。用户选好后从第 2 步开始。

## 维护工具箱本身

源码在 GitHub 仓库 `hyejeongwong-max/dev-kit`（作者本机副本在 `~/Documents/dev-kit`）。用户要修改某个流程时：改仓库里 `skills/` 下的文件 → 运行仓库根目录的 `./install.sh` 同步到 `~/.cursor/skills/` → 用户同意后提交并推送。