| name | project-fix-generator |
| description | 项目后期修改生成器:当生成结果不符合需求时,先归类问题再路由到专项深问,并给出可验收的增量修改方案。用户要求修正、补齐、重构现有项目时调用。 |
project-fix-generator
一句话目标
把“哪里不对”变成“怎么改 + 改哪些文件 + 怎么验收”,并避免盲改。
触发条件(何时用)
- 用户说“生成结果不符合需求/这里要改/帮我修正/按新要求调整”
- 用户提供新需求,希望在现有项目基础上增量修改
小白模式(必须支持)
- 归类时用一句话解释类别含义(不要只给黑话)
- 术语首次出现必须解释(例如 JWT、RBAC、迁移、CI/CD)
- 推荐策略必须解释“为什么这样改”
路线图(强约束调用链)
- 从零生成:
project-scaffold-generator
- 生成后修正:本 Skill(总入口)
- 专项深问:由本 Skill 路由到专项 Skill
专项路由(明确分流)
- 前端问题(页面/交互/路由/类型/联调) ->
frontend-fix-generator
- 后端问题(接口/业务/异常/校验/鉴权) ->
backend-fix-generator
- 数据库问题(表结构/DDL/迁移/索引/事务) ->
database-fix-generator
- UI 风格问题(主题/配色/布局/字体/动效/暗黑) ->
ui-style-fix-generator
- 工程化问题(跑不起来/构建/部署/Docker/CI/文档) ->
engineering-fix-generator
若同时命中多类:
- 先选 1 个主类进入专项深问
- 其他作为“次问题”记录为后续修改包
最短流程(6 Phase,精简版)
Phase 1:收集上下文
优先确认 4 件事(必须使用 AskUserQuestion 工具以选项形式呈现,禁止要求用户手动打字):
- 现象(现在是什么样)→ 给出常见问题选项
- 预期(你想要什么样)→ 给出改进方向选项
- 位置(在哪个模块/页面/API/文档)→ 列出项目模块让用户选择
- 证据(截图/报错/需求文档/复现步骤)→ 给出证据类型选项
Phase 2:问题归类
输出“问题归类卡”,给出主归类 + 次归类,并用通俗话解释每类含义。
Phase 3:停止深问并路由
如果主归类已明确,不在这里继续问细节,直接切到对应专项 Skill 做更细追问。
Phase 4:修改方案(改前确认)
输出“修改方案卡”,至少包含:
- 修改策略(最小修复/局部重构/模块重做)
- 目标文件/模块清单
- 风险与回滚建议
- 验收点(改完如何判断成功)
Phase 5:增量修改执行(如果当前平台允许改代码)
执行时每个修改包必须输出:
- 文件清单
- 运行/启动方式
- 验收点(接口返回、页面行为、构建通过等)
Phase 6:回归与对照表
输出:
- 修改对照表(问题项 | 归类 | 修改内容 | 位置 | 状态)
- 回归检查表(功能/类型/响应/安全/UI/工程链路)