| name | code-generator |
| description | 根据开发步骤文档生成代码的开发工具。当用户需要根据开发步骤实现功能、编写代码、开发功能时使用此技能。触发词包括：生成代码、实现功能、开发、写代码、根据步骤开发等。此技能强制使用 Plan 模式，确保代码质量和符合项目规范。开发完成后会自动使用 Playwright MCP 进行功能和 UI 测试，并自动调用 dev-steps-generator、prd-writer、tech-discussion-guide、test-case-generator 技能同步更新关联文档。 |
代码生成器技能
根据开发步骤文档，按照项目规范生成高质量代码。
核心规则
- 必须使用 Plan 模式：生成代码前必须先创建计划，用户批准后才能写代码
- 必须学习代码规范：开发前必须查看项目现有代码，学习开发规范
- 必须验收检查：开发完成后必须对照开发步骤进行验收检查
- 必须 Playwright 测试：验收通过后必须使用 Playwright MCP 进行功能和 UI 测试
- 必须同步文档：开发完成后必须调用相关技能同步更新关联文档（开发步骤、PRD、技术方案、测试用例）
- 全中文沟通：所有沟通内容使用中文
- 技术栈约束：
- 必须使用指定技术栈：生成的代码必须使用用户提供的技术方案文档中的技术栈
- 禁止随意使用其他技术：不可随意使用技术方案文档中未提及的技术栈
- 需要用户同意：如果需要使用技术方案文档之外的技术栈，必须先征得用户同意
必需参数
用户调用时必须提供：
- 开发步骤文档：具体的开发步骤文档路径（如
步骤1-xxx.md）
- 技术方案文档（推荐）：技术方案文档的完整路径，用于约束代码的技术栈
技术栈使用规范
基本原则
在生成代码时，所有代码必须严格遵循用户提供的技术方案文档中的技术栈。
工作流程
-
读取技术方案文档
- 如果用户提供了技术方案文档路径，必须先读取该文档
- 提取文档中明确的技术栈选型（框架、库、工具等）
- 记录技术栈的版本要求和使用约束
-
代码生成规则
- ✅ 允许：使用技术方案文档中明确提及的技术栈
- ❌ 禁止：随意使用技术方案文档中未提及的技术栈
- ⚠️ 需确认：如果需要使用文档外的技术，必须先询问用户
-
技术栈冲突处理
- 如果发现需要使用技术方案文档之外的技术栈，立即暂停生成
- 向用户说明原因和替代方案
- 等待用户确认后再继续
示例场景
场景 1：技术方案明确指定
技术方案文档：Next.js 16 + Sequelize + PostgreSQL
代码生成：✅ 使用 Sequelize 操作数据库
代码生成：❌ 使用 Prisma 操作数据库（未经用户同意）
场景 2：需要额外技术栈
技术方案文档：Next.js 16 + Sequelize
需求：实现图片上传和压缩功能
处理方式：
1. 检查技术方案文档中是否有图片处理库
2. 如果没有，询问用户："检测到需要图片处理功能，技术方案文档中未指定图片处理库。
建议使用 sharp 库，是否同意？或者您有其他选择？"
3. 等待用户确认后再生成代码
场景 3：未提供技术方案文档
如果用户未提供技术方案文档：
1. 提醒用户："建议提供技术方案文档路径，以确保代码使用正确的技术栈"
2. 基于开发步骤文档和现有代码推断技术栈
3. 在生成代码前，向用户确认推断的技术栈是否正确
工作流程
阶段一：准备阶段
1.1 读取开发步骤文档
- 读取用户提供的开发步骤文档
- 提取关键信息：
- 步骤目标
- 需求说明
- 涉及的文件列表
- 技术实现指引
- 验收标准
1.2 读取技术方案文档
如果用户提供了技术方案文档路径，必须先读取该文档：
- 完整阅读技术方案文档
- 提取技术栈选型：
- 前端框架和版本（如 Next.js 16）
- 后端框架和版本
- 数据库和 ORM（如 PostgreSQL + Sequelize）
- 状态管理库
- UI 组件库
- 其他关键依赖库
- 记录技术约束和架构决策
- 在后续代码生成中严格遵循这些技术栈
如果用户未提供技术方案文档：
- 提醒用户："建议提供技术方案文档路径，以确保代码使用正确的技术栈"
- 基于开发步骤文档和现有代码推断技术栈
- 在计划阶段向用户确认推断的技术栈是否正确
1.3 学习项目代码规范
在开发前，必须查看项目现有代码以学习开发规范：
-
查看 CLAUDE.md
- 读取项目根目录的 CLAUDE.md 文件
- 了解项目架构和开发约定
-
查看相关模块的现有代码
- 根据开发步骤中涉及的文件，查看同目录下的其他文件
- 学习代码风格：命名规范、注释风格、缩进方式
- 学习组件结构：模板结构、脚本组织、样式写法
- 学习 API 调用方式：请求封装、错误处理、数据处理
-
总结代码规范
阶段二：计划阶段（Plan 模式）
必须调用 EnterPlanMode 工具进入计划模式。
2.1 创建开发计划
在计划文件中详细说明：
# 开发计划：[步骤名称]
## 一、开发步骤概述
- 步骤目标：[从开发步骤文档提取]
- 涉及文件：[列出所有需要修改/新增的文件]
## 二、技术栈遵循
基于技术方案文档，本次开发将使用以下技术栈：
- 前端框架：[具体技术和版本]
- 后端框架：[具体技术和版本]
- 数据库/ORM：[具体技术和版本]
- 状态管理：[具体技术]
- UI 组件库：[具体技术]
- 其他依赖：[列出关键依赖]
**技术栈约束确认**：
- ✅ 所有代码将严格使用上述技术栈
- ⚠️ 如需使用其他技术，将先征得用户同意
## 三、代码规范遵循
基于对现有代码的分析，本次开发将遵循以下规范：
- 命名规范：[具体规范]
- 组件结构：[具体规范]
- 样式写法：[具体规范]
- API 调用：[具体规范]
## 四、实现方案
### 4.1 [文件1名称]
- 修改类型：[新增/修改]
- 修改内容：[详细说明]
- 使用技术：[明确使用的技术栈]
- 关键代码设计：[伪代码或关键逻辑]
### 4.2 [文件2名称]
...
## 五、验收对照表
| 验收项 | 实现方案 |
|-------|---------|
| [验收标准1] | [对应实现] |
| [验收标准2] | [对应实现] |
...
2.2 等待用户批准
- 使用
ExitPlanMode 工具提交计划
- 等待用户审核并批准计划
- 如用户有修改意见，根据反馈调整计划
阶段三：开发阶段
只有在用户批准计划后才能进入此阶段。
3.1 按计划实现代码
- 按照计划中的顺序逐个文件实现
- 严格遵循阶段二确定的代码规范
- 严格遵循阶段二确定的技术栈，不使用未经批准的技术
- 每完成一个文件，简要说明完成情况
3.2 开发过程中的注意事项
- 不要过度工程：只实现开发步骤要求的功能
- 保持代码简洁：不添加额外的"优化"或"改进"
- 遵循现有模式：使用项目中已有的工具函数和组件
- 遵循技术栈约束：只使用技术方案文档中批准的技术栈
3.3 技术栈冲突处理
如果在开发过程中发现需要使用技术方案文档之外的技术：
- 立即暂停代码生成
- 向用户说明情况：
- 说明为什么需要使用新技术
- 提供替代方案（如果有）
- 说明使用新技术的影响
- 等待用户确认：
- 用户同意：记录新技术并继续开发
- 用户拒绝：使用替代方案或调整实现方式
阶段四：验收阶段
开发完成后，必须进行验收检查。
4.1 对照验收标准检查
逐项检查开发步骤文档中的验收标准：
## 验收检查报告
### 验收标准检查
| 序号 | 验收标准 | 检查结果 | 说明 |
|-----|---------|---------|-----|
| 1 | [标准1] | ✅/❌ | [具体说明] |
| 2 | [标准2] | ✅/❌ | [具体说明] |
...
### 检查总结
- 通过项：X 项
- 未通过项：X 项
- 总体结论：[通过/需要修复]
4.2 代码复查
检查生成的代码是否：
- 符合项目代码规范
- 严格遵循技术方案文档中的技术栈
- 没有引入安全漏洞
- 没有遗漏必要的错误处理
- 没有硬编码或魔法数字
技术栈合规性检查：
- 检查所有依赖库是否在技术方案文档中
- 检查是否使用了未经批准的技术
- 如有偏离，记录原因和用户批准情况
4.3 处理未通过项
如有验收标准未通过：
- 列出未通过的具体原因
- 提出修复方案
- 询问用户是否需要立即修复
阶段五：Playwright MCP 测试
验收检查通过后，必须使用 Playwright MCP 进行功能和 UI 测试。
5.1 启动开发服务器
- 使用 Bash 工具在后台启动开发服务器：
npm run dev
- 等待服务器启动完成（通常需要几秒钟）
5.2 使用 Playwright MCP 进行测试
使用 Playwright MCP 工具进行以下测试：
功能测试：
- 使用
mcp__playwright__browser_navigate 导航到开发的页面
- 使用
mcp__playwright__browser_snapshot 获取页面快照，检查页面结构
- 根据开发步骤文档中的验收标准，验证功能是否正常：
- 检查页面元素是否存在
- 检查交互功能是否正常
- 检查数据展示是否正确
UI 样式测试：
- 使用
mcp__playwright__browser_screenshot 截取页面截图
- 检查 UI 样式是否符合设计要求：
- 布局是否正确（响应式布局检查）
- 颜色和字体是否符合设计规范
- 组件样式是否一致
- 如有 UI 设计稿，对比截图与设计稿的差异
5.3 测试报告
生成测试报告：
## Playwright 测试报告
### 测试环境
- 测试 URL：[页面 URL]
- 浏览器：Chromium
- 视口大小：[宽度] x [高度]
### 功能测试结果
| 测试项 | 预期结果 | 实际结果 | 状态 |
|-------|---------|---------|------|
| [功能1] | [预期] | [实际] | ✅/❌ |
| [功能2] | [预期] | [实际] | ✅/❌ |
...
### UI 样式测试结果
| 检查项 | 预期样式 | 实际样式 | 状态 |
|-------|---------|---------|------|
| [样式1] | [预期] | [实际] | ✅/❌ |
| [样式2] | [预期] | [实际] | ✅/❌ |
...
### 截图记录
[附上关键页面截图路径]
### 测试总结
- 功能测试：[X] 项通过，[Y] 项失败
- UI 测试：[X] 项通过，[Y] 项失败
- 总体结论：[通过/需要修复]
5.4 问题修复
如果测试发现问题：
-
功能问题：
-
UI 样式问题：
- 分析样式差异
- 调整 CSS/Tailwind 类名
- 重新截图验证
-
修复后重新测试：
- 所有修复完成后，重新执行完整测试流程
- 确保所有测试项通过
5.5 Playwright MCP 工具使用指南
常用的 Playwright MCP 工具：
| 工具名称 | 用途 |
|---|
mcp__playwright__browser_navigate | 导航到指定 URL |
mcp__playwright__browser_snapshot | 获取页面可访问性快照 |
mcp__playwright__browser_screenshot | 截取页面截图 |
mcp__playwright__browser_click | 点击页面元素 |
mcp__playwright__browser_type | 在输入框中输入文本 |
mcp__playwright__browser_select_option | 选择下拉选项 |
mcp__playwright__browser_hover | 悬停在元素上 |
mcp__playwright__browser_evaluate | 执行 JavaScript 代码 |
测试流程示例：
1. browser_navigate → 打开页面
2. browser_snapshot → 检查页面结构
3. browser_screenshot → 截取 UI 截图
4. browser_click → 测试交互功能
5. browser_snapshot → 验证交互结果
阶段六：完成报告
输出最终完成报告：
## 开发完成报告
### 完成概况
- 开发步骤：[步骤名称]
- 涉及文件：[X] 个
- 验收结果：[全部通过/部分通过]
- Playwright 测试：[全部通过/部分通过]
### 文件变更清单
| 文件路径 | 操作类型 | 变更说明 |
|---------|---------|---------|
| [路径1] | 新增/修改 | [说明] |
...
### 后续建议
- [如有需要后续步骤或注意事项]
阶段七：生成开发结果文档
开发完成后，必须生成开发结果文档并保存到用户指定的位置。
7.1 询问保存位置
向用户询问开发结果文档的保存位置：
"开发已完成。请问你希望将开发结果文档保存到哪个文件夹？例如：docs/开发结果"
7.2 生成开发结果文档
文档命名规则：[步骤名称].md，例如 步骤1-扩展支付方式选择组件.md
文档内容模板：
# [步骤名称] 开发结果
## 一、完成的修改
### 1. [文件名1]（修改/新增）
**文件路径**：`[完整路径]`
**修改内容**：
- [修改点1]
- [修改点2]
...
**新增 Props/参数**（如适用）：
| 名称 | 类型 | 默认值 | 说明 |
|------|------|--------|------|
| [名称] | [类型] | [默认值] | [说明] |
...
### 2. [文件名2]（修改/新增）
...
## 二、使用示例
```vue/js/...
[提供完整的使用示例代码]
三、验收对照
| 验收项 | 状态 |
|---|
| [验收标准1] | ✅/❌ |
| [验收标准2] | ✅/❌ |
| ... | |
四、后续步骤
[列出后续需要进行的开发步骤，或标注"无"]
#### 7.3 保存文档
1. 使用 Write 工具将文档保存到用户指定的文件夹
2. 确认保存成功并告知用户文档路径
### 阶段八：开发步骤同步检查
**开发完成后，检查是否需要同步更新开发步骤总览文档。**
#### 8.1 检查开发步骤总览
1. 读取开发步骤总览文档（通常位于 `docs/开发步骤/开发步骤总览.md`）
2. 检查当前完成的步骤在总览中的状态
#### 8.2 更新总览文档
如果总览文档存在，更新当前步骤的状态：
1. 将已完成步骤的状态从 `待开发` 更新为 `已完成`
2. 添加完成日期
3. 如有必要，更新后续步骤的依赖状态
**更新示例**：
```markdown
| 步骤 | 状态 | 完成日期 |
|-----|------|---------|
| 步骤1-xxx | ✅ 已完成 | 2024-01-15 |
| 步骤2-xxx | 🔄 开发中 | - |
| 步骤3-xxx | ⏳ 待开发 | - |
8.3 提示后续步骤
完成同步后，提示用户：
- 当前步骤已完成并同步到总览
- 下一个待开发的步骤是什么
- 询问用户是否继续开发下一个步骤
阶段九：关联文档同步更新
开发完成后，必须自动调用相关技能来同步更新项目文档，确保文档与代码保持一致。
9.1 同步更新流程
代码开发完成并通过验收后，依次调用以下技能更新对应文档：
-
调用 dev-steps-generator 技能
- 目的：同步更新开发步骤文档，确保步骤描述与实际代码实现一致
- 重点：更新已完成步骤中的文件路径、技术细节、代码示例等
-
调用 prd-writer 技能
- 目的：同步更新 PRD 文档，反映已实现的功能变更
- 重点：更新功能描述、接口变更、新增/删除的功能点
-
调用 tech-discussion-guide 技能
- 目的：同步更新技术方案文档，记录实际采用的技术决策
- 重点：更新技术选型、架构变更、新增依赖等
-
调用 test-case-generator 技能
- 目的：同步更新测试用例文档，补充新功能的测试用例
- 重点：为新增/修改的功能生成对应的测试用例
9.2 调用方式
使用 Skill 工具依次调用每个技能，并传递本次开发的上下文信息：
调用顺序：
1. Skill: dev-steps-generator → 传入本次修改的开发步骤文档路径
2. Skill: prd-writer → 传入对应的 PRD 文档路径
3. Skill: tech-discussion-guide → 传入技术方案文档路径
4. Skill: test-case-generator → 传入 PRD 文档路径
9.3 同步规则
- 仅更新已存在的文档：如果某类文档不存在，跳过该技能的调用
- 增量更新：只更新与本次开发相关的部分，不重写整个文档
- 保持一致性：确保所有文档中的文件路径、技术栈、功能描述保持一致
- 记录变更：在每个文档的更新中注明本次同步的原因和变更内容
9.4 同步完成确认
所有文档同步完成后，向用户报告：
## 文档同步报告
| 文档类型 | 技能 | 同步状态 | 说明 |
|---------|------|---------|------|
| 开发步骤文档 | dev-steps-generator | ✅/⏭️ | [更新说明或跳过原因] |
| PRD 文档 | prd-writer | ✅/⏭️ | [更新说明或跳过原因] |
| 技术方案文档 | tech-discussion-guide | ✅/⏭️ | [更新说明或跳过原因] |
| 测试用例文档 | test-case-generator | ✅/⏭️ | [更新说明或跳过原因] |
异常处理
开发步骤文档不存在
提示用户提供正确的文档路径，或使用 dev-steps-generator 技能先生成开发步骤。
计划被拒绝
- 了解用户的具体反馈
- 根据反馈修改计划
- 重新提交计划审批
验收不通过
- 记录不通过的具体项目
- 分析原因并提出修复方案
- 在用户同意后进行修复
