Skill工程化
重要
经过我多次的测试发现，使用工程化skill，缺点流程太繁琐，不适合快速开发，快速迭代,沟通需求太沉重不适合使用
- 小需求也要经过很长的流程；
- 用户和 Agent 需要反复确认；
- 产生大量与改动不相称的计划、文档和验证；
- 快速开发和快速迭代被流程本身拖慢。
在使用过程中发现，太过沉重，导致分析过度，还有在测试过程中，太复杂化,已经弃用，谨慎使用
一、Skill解决什么问题
$managing-uncertain-requirements 适合以下场景：
- 只有初步想法，需求还没有确定
- 需要先沟通需求，不希望AI直接修改代码
- 需要把需求分析、调研、架构、规格和开发过程保存为文档
- 涉及权限、金额、数据状态、异常处理等复杂业务规则
- 希望每个阶段由使用人确认后，才能进入下一阶段
- 希望AI按照SDD、Harness、Loop方式完成工程任务
- 希望避免AI自行补充需求、扩大范围或直接部署
整个流程遵守以下原则：
- 先检查项目事实，再提出建议。
- 区分现有事实、分析建议、已确认决定和待确认问题。
- 每次只询问一个最关键的问题。
- 每个阶段完成三次阶段出口审计。
- 使用人确认当前阶段文档后，才能进入下一阶段。
- 未明确授权时，不修改代码、不提交、不推送、不部署。
二、模式A：只沟通需求，不生成文件
适合需求刚刚出现，还不确定是否立项。
使用 $managing-uncertain-requirements。
项目目录：【项目路径】
初始需求：【需求想法】
当前只进行需求分析，不修改文件。
执行要求：
1. 先检查项目现有文档、代码和目录规范；
2. 从Discovery阶段开始；
3. 区分现有事实、分析建议、已确认决定和待确认问题；
4. 每次只问我一个最重要的问题，并给出推荐意见；
5. 不创建需求文档；
6. 不修改任何项目文件；
7. 完成三次阶段出口审计后，再让我确认Discovery结论；
8. 未经我的明确批准，不得进入下一阶段。该模式下，需求分析结论只保留在当前对话中。
三、模式B：完整文档流程
适合正式项目，需要保存各阶段文档。
使用 $managing-uncertain-requirements 管理这个需求。
项目目录：【项目路径】
初始需求：【需求想法】
功能名称：【中文名称】
功能标识：【英文kebab-case，例如material-settlement】
允许创建和更新需求阶段文档。
执行要求：
1. 先检查项目现有文档、代码、测试和目录规范；
2. 如果项目已有等价的需求文档目录，沿用现有规范；
3. 如果没有现有规范，使用：
docs/features/<feature-slug>/
4. 从Discovery阶段开始；
5. 区分现有事实、分析建议、已确认决定和待确认问题；
6. 每次只问我一个最重要的问题，并提供推荐意见；
7. 每个阶段必须完成三次阶段出口审计；
8. 必须由我确认当前阶段文档后，才能进入下一阶段；
9. 未经我的明确批准，不得进入实现阶段；
10. 未经授权，不得提交、推送、发布或部署。四、阶段文档目录
如果项目没有现成的文档规范，默认使用以下目录：
docs/features/<feature-slug>/
├── 01-discovery/
│ └── discovery.md
├── 02-research/
│ └── research.md
├── 03-prototypes/
│ └── prototype.md
├── 04-architecture/
│ ├── architecture-design.md
│ ├── architecture-improvement.md
│ └── wayfinding.md
├── 05-spec/
│ ├── drafts/
│ │ └── spec.md
│ └── approved/
│ └── spec.md
├── 06-tickets/
│ └── tickets.md
├── 07-implementation/
│ └── implementation-log.md
├── 08-debugging/
│ └── diagnosis.md
├── 09-reviews/
│ └── review.md
└── 10-handoffs/
└── handoff.md注意：
- 一个需求只维护一个功能目录。
<feature-slug>使用小写英文和连字符。- 例如：
material-revenue-settlement。 - 架构阶段只创建当前使用的文档，不需要同时创建三个架构文档。
- 项目已有等价规范时，沿用原有规范，不创建第二套目录。
五、Discovery：需求分析
用于确认问题、用户、目标、范围、限制、风险和未知项。
使用 $managing-uncertain-requirements。
进入Discovery阶段。
项目目录：【项目路径】
初始需求：【需求想法】
功能名称：【中文名称】
功能标识：【英文kebab-case】
请完成以下工作：
1. 检查项目现有代码、文档和业务术语；
2. 明确要解决的问题；
3. 明确主要用户；
4. 梳理3至5个核心场景；
5. 明确功能目标和成功标准；
6. 明确本次范围和非目标；
7. 检查权限、金额、隐私、数据状态和数据丢失风险；
8. 区分事实、建议、决定和未知项；
9. 每次只问我一个最重要的问题；
10. 把结论保存到：
docs/features/<feature-slug>/01-discovery/discovery.md
完成三次阶段出口审计后，让我确认Discovery文档。
未经确认，不得进入下一阶段。确认用语：
批准Discovery结论，并进入【下一阶段名称】。不批准时：
暂不批准Discovery结论。
需要修改：
【填写需要调整的内容】
请继续停留在Discovery阶段。六、Research：外部调研
适合查询官方接口、第三方能力、产品价格、政策或技术事实。
使用 $managing-uncertain-requirements。
进入Research阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
已经批准的调研问题：【填写具体问题】
来源要求：【例如只允许使用官方文档】
请完成以下工作：
1. 只研究已经批准的问题；
2. 优先使用官方文档和一手资料；
3. 区分已验证事实、合理推断和分析建议；
4. 记录来源和证据；
5. 不将调研建议自动视为业务决定；
6. 将结论保存到：
docs/features/<feature-slug>/02-research/research.md
完成三次阶段出口审计后，让我确认Research文档。确认用语：
批准Research结论，并进入【下一阶段名称】。七、Prototype：原型验证
适合验证页面交互、状态流程或技术方案是否可行。
使用 $managing-uncertain-requirements。
进入Prototype阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
需要验证的不确定性：【具体问题】
原型成功标准：【什么结果代表可行】
请完成以下工作：
1. 设计最小、可逆、可丢弃的验证方案；
2. 不把原型当成正式生产实现；
3. 不扩大验证范围；
4. 记录验证过程、结果和结论；
5. 说明原型结果对正式方案有什么影响；
6. 将结论保存到：
docs/features/<feature-slug>/03-prototypes/prototype.md
完成三次阶段出口审计后，让我确认Prototype结论。确认用语：
批准Prototype结论，并进入【下一阶段名称】。八、Wayfinding：定位现有代码
适合不熟悉项目，不知道功能入口、模块归属或数据流时使用。
使用 $managing-uncertain-requirements。
进入Wayfinding阶段。
项目目录：【项目路径】
需要定位的问题：【填写问题】
请只检查现有项目，不设计新架构，不修改代码。
请梳理：
1. 功能入口；
2. 主要调用链；
3. 数据经过的模块；
4. 核心状态变化；
5. 数据库或外部服务依赖；
6. 模块职责和归属；
7. 已确认事实和未知项；
8. 可能受到影响的文件；
9. 下一步需要做出的决定。
将结果保存到：
docs/features/<feature-slug>/04-architecture/wayfinding.md
完成三次阶段出口审计后，让我确认Wayfinding结论。确认用语：
批准Wayfinding结论，并进入【下一阶段名称】。九、Architecture Design：新架构设计
适合新增模块、跨系统功能或重要技术决策。
使用 $managing-uncertain-requirements。
进入Architecture design阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
需要解决的技术决策：【填写技术问题】
请完成以下工作：
1. 检查现有项目架构和约束；
2. 明确模块边界和职责；
3. 分析数据模型影响；
4. 分析外部服务和依赖；
5. 提供可选方案；
6. 比较每个方案的优缺点和迁移成本；
7. 给出推荐方案；
8. 说明不采用其他方案的原因；
9. 判断是否需要ADR；
10. 不直接修改代码。
将结果保存到：
docs/features/<feature-slug>/04-architecture/architecture-design.md
完成三次阶段出口审计后，让我确认Architecture design文档。确认用语：
批准Architecture design，并进入【下一阶段名称】。十、Architecture Improvement：现有架构改进
只适合已经存在代码，并且能够找到真实架构问题的项目。
使用 $managing-uncertain-requirements。
进入Architecture improvement阶段。
项目目录：【项目路径】
需要检查的模块：【模块或目录】
请先检查真实代码证据，不要根据猜测提出重构。
重点检查：
1. 模块职责是否混乱；
2. 是否存在重复所有权；
3. 是否存在边界泄漏；
4. 是否存在难以测试的接口；
5. 是否存在重复业务逻辑；
6. 是否存在不合理的跨层依赖；
7. 改进方案能否分步实施；
8. 改进可能带来的迁移风险。
当前只分析和设计，不修改代码。
将结果保存到：
docs/features/<feature-slug>/04-architecture/architecture-improvement.md
完成三次阶段出口审计后，让我确认Architecture improvement文档。确认用语：
批准Architecture improvement，并进入【下一阶段名称】。十一、Specification：正式需求规格
进入该阶段前，Discovery和必要的调研、原型或架构结论必须已经批准。
使用 $managing-uncertain-requirements。
进入Specification阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
请读取已经批准的：
- Discovery文档；
- Research文档；
- Prototype文档；
- Architecture文档。
根据已批准结论编写可测试的需求规格，必须包括：
1. 问题和目标用户；
2. 核心使用场景；
3. 功能范围；
4. 明确非目标；
5. 业务规则；
6. 输入和输出；
7. 用户权限；
8. 数据状态；
9. 正常流程；
10. 异常流程；
11. 失败恢复方式；
12. 验收标准；
13. 安全、隐私、金额和数据风险；
14. 明确排除项。
先生成草稿并保存到：
docs/features/<feature-slug>/05-spec/drafts/spec.md
未经我明确批准，不得复制到approved目录，不得拆分Tickets。修改草稿：
暂不批准Specification草稿。
需要修改：
【填写修改要求】
请修改草稿，不要进入Tickets阶段。批准规格：
批准这份Specification，用于拆分Tickets。
请将批准版本保存到：
docs/features/<feature-slug>/05-spec/approved/spec.md十二、Tickets：拆分开发任务
使用 $managing-uncertain-requirements。
进入Tickets阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
请根据已批准的Specification拆分开发任务。
每个Ticket必须包括：
1. Ticket编号；
2. 单一目标；
3. 对应的Specification条目；
4. 前置依赖；
5. 预计修改范围；
6. 验收条件；
7. 测试要求；
8. 明确非目标；
9. 风险和注意事项；
10. 是否可以独立验证。
当前只拆分Tickets，不修改代码。
将结果保存到：
docs/features/<feature-slug>/06-tickets/tickets.md
完成三次阶段出口审计后，让我确认Tickets。批准指定任务：
批准这些Tickets，并允许实现ticket T-001。
本次只授权T-001，不代表批准其他Ticket。十三、Implementation：逐个实现
使用 $managing-uncertain-requirements。
进入Implementation阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
本次批准实现的Ticket：【T-001】
执行要求：
1. 读取已批准的Specification和Tickets；
2. 检查项目开发规范和现有代码；
3. 检查测试、构建、类型检查和启动命令；
4. 先输出T-001的小步实现计划；
5. 只修改T-001涉及的范围；
6. 不添加无关功能；
7. 不进行无关重构；
8. 不擅自增加依赖；
9. 不擅自修改数据库、部署或生产配置；
10. 完成后运行对应测试；
11. 检查修改差异；
12. 报告修改文件、行为变化和验证证据。
将实现记录保存到：
docs/features/<feature-slug>/07-implementation/implementation-log.md
未经重新批准，不得实现下一个Ticket，不得提交、推送或部署。批准下一个任务：
批准实现ticket T-002。十四、Debugging：先诊断再修复
使用 $managing-uncertain-requirements。
进入Debugging阶段。
项目目录：【项目路径】
预期行为：
【填写应该发生什么】
实际行为：
【填写实际发生什么】
复现步骤：
【填写复现方式】
错误信息或日志：
【粘贴完整错误】
最近修改：
【如果知道则填写】
当前只进行诊断，不要直接修改代码。
请输出：
1. 已确认症状；
2. 可能原因；
3. 每个假设的验证方法；
4. 已排除原因；
5. 涉及的文件和调用链；
6. 推荐的最小修复边界；
7. 修复后的验证计划。
将诊断结果保存到：
docs/features/<feature-slug>/08-debugging/diagnosis.md
完成三次阶段出口审计后，让我确认Diagnosis。批准修复：
批准这份Diagnosis。
允许按照文档中的最小修复边界进行修复。
不得扩大修改范围。十五、Review：代码与需求审查
使用 $managing-uncertain-requirements。
进入Review阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
审查范围：【Ticket编号、分支、提交或修改范围】
请分别执行：
1. Standards Review：检查是否符合项目规范；
2. Specification Review：检查是否符合批准的需求规格。
重点检查：
- 功能是否满足验收标准；
- 是否存在范围外修改；
- 权限是否正确；
- 数据状态是否完整；
- 异常处理是否完整；
- 是否存在安全或隐私问题；
- 测试证据是否充分；
- 是否存在潜在回归。
按严重程度列出问题。
当前只进行Review，不直接修改代码。
将结果保存到：
docs/features/<feature-slug>/09-reviews/review.md批准处理Review问题：
批准处理Review中的以下问题：
【问题编号】
只允许处理指定问题，不得扩大范围。Review完成后：
批准Review处理结论，并进入Handoff。十六、Handoff：交付说明
使用 $managing-uncertain-requirements。
进入Handoff阶段。
项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
请整理：
1. 已交付范围；
2. 未交付内容；
3. 主要修改文件；
4. 功能入口和数据流；
5. 测试与验收证据；
6. 已知限制；
7. 遗留风险；
8. 技术债；
9. 认知债；
10. 部署和运行注意事项；
11. 出现问题时首先检查的位置；
12. 后续负责人需要完成的事项。
将结果保存到：
docs/features/<feature-slug>/10-handoffs/handoff.md
不要自动提交、推送、发布或部署。
完成三次阶段出口审计后，让我确认Handoff。最终确认：
批准这份Handoff为完成状态。十七、学习模式
如果希望理解整个工程过程，而不是只让AI完成代码，可以使用强Ownership模式。
使用 $managing-uncertain-requirements。
学习模式。
我想理解整个实现过程，不要直接修改代码，带我分析。
项目目录：【项目路径】
当前问题：【需求或Bug】
每个阶段请说明：
1. 为什么这样判断；
2. 功能入口在哪里；
3. 数据经过哪些模块；
4. 核心状态如何变化；
5. 最容易在哪里出错；
6. 为什么选择当前方案；
7. 为什么不选择其他方案；
8. 如何验证结果；
9. 出现问题时首先检查哪里；
10. 我还需要理解哪些知识。
涉及正确性、安全、金额、权限、数据丢失或部署风险的问题，
如果我还没有理解清楚，请将其标记为阶段阻塞项。十八、三次阶段出口审计
每次进入下一阶段前，AI都需要完成以下检查。
第一次：完整性检查
检查：
- 当前阶段要求是否已经完成
- 是否存在矛盾
- 是否遗漏关键内容
- 是否把推断误认为事实
- 是否还有没有记录的决定
第二次：阻塞项检查
所有未解决问题必须分类为：
blocks-next-stage
defer-to-<stage>
out-of-scope涉及以下内容的问题，默认会阻塞Specification、Tickets或Implementation：
- 业务规则
- 用户可见行为
- 权限
- 数据状态
- 金额与结算
- 失败处理
- 安全与隐私
- 数据丢失风险
第三次：阶段跳转检查
检查：
- 下一阶段是否真的有必要
- 当前阶段输入是否已经批准
- 是否还有阻塞项
- 下一阶段是否依赖尚未确定的内容
如果审计未通过，AI必须说明：
阶段出口审计未通过。并继续停留在当前阶段。
十九、推荐日常总控提示词
以后处理新的不确定需求，可以直接复制下面这段：
使用 $managing-uncertain-requirements 管理这个需求。
项目目录：【绝对路径】
初始需求：【当前想法，可以很粗略】
功能名称：【中文名称】
功能标识：【英文kebab-case】
工作模式：【只沟通需求，不生成文件 / 完整文档流程】
Ownership模式：【lightweight / 学习模式strong】
执行要求：
1. 先检查项目现有文档、代码、测试和目录规范；
2. 从Discovery阶段开始；
3. 区分现有事实、分析建议、已确认决定和待确认问题；
4. 每次只问我一个最重要的问题，并提供推荐意见；
5. 优先沿用项目已有文档规范；
6. 如果没有现有规范，使用：
docs/features/<feature-slug>/
7. 每次进入下一阶段前，执行三次阶段出口审计；
8. 必须由我确认当前阶段文档或无文档结论；
9. 未经确认，不得进入下一阶段；
10. 未经批准，不得进入Implementation；
11. 实现时一次只允许处理一个指定Ticket；
12. 不得自动提交、推送、发布或部署；
13. 任何“应该可以”“逻辑正确”都不能作为完成证据；
14. 必须使用测试、构建、接口、页面或人工验收结果证明完成。二十、常用确认语句
批准Discovery结论，并进入Research。批准Discovery结论，并进入Specification。批准Research结论，并进入Architecture design。批准Architecture design，并进入Specification。批准这份Specification，用于拆分Tickets。批准这些Tickets，并允许实现ticket T-001。批准实现ticket T-002。批准这份Diagnosis，允许按照最小修复边界修复。批准Review处理结论，并进入Handoff。批准这份Handoff为完成状态。批准一个问题不等于批准整个阶段；批准需求文档不等于批准修改代码；批准实现不等于批准提交、推送或部署。
版权所有
版权归属：念宇