| name | dev-workflow |
| description | 开发流程六步法。支持项目梳理、需求理解、方案设计、代码实现、Bug 修复、代码审查，内置 AI 记忆文档、项目需求逻辑梳理文档、分类方案模板、上下文续接机制、自我进化规则、注释偏好、节省 token 的执行策略与默认自主落地规则，适合大型 Java 项目、复杂需求、多轮迭代和上下文不足场景。当用户提到「项目梳理」「核心流程」「业务逻辑」「系统流程」「需求分析」「方案设计」「代码实现」「代码审查」「理解需求」「技术设计」「开始写代码」「Review」「检查代码」「bug」「报错」「崩溃」「异常」「出错了」「中间记忆」「上下文不够」「复杂项目」「继续上一轮」「接着做」「继续分析」「继续实现」「功能迭代」「直接改代码」「直接生成所有代码」「注释多一点」「节省token」「优化skill」「优化我的skill」「数据库设计」「建表」「DDL」「字段设计」「接口设计」「API设计」「接口文档」「Swagger」「swagger」「YApi」「yapi」「导入YApi」时使用。 |
开发流程六步法
项目梳理 → 需求理解 → 方案设计 → 代码实现 → 代码审查 → Bug 修复
本 skill 建议与同目录下的 copilot-instructions.md 配合使用：
copilot-instructions.md 负责常驻硬规则SKILL.md 与 reference/*.md 负责阶段流程和模板- 如有冲突，以
copilot-instructions.md 中的硬规则为准，SKILL.md 提供流程框架
发现与安装
通常不需要用户在对话里告诉 AI 这个 skill 的目录路径。
前提是该 skill 已放在 Copilot 支持的 skill 目录中，例如：
~/.copilot/skills/dev-workflow/- 工作区内的
.github/skills/dev-workflow/
只要目录位置正确，且 description 与用户请求匹配，Copilot 应该会根据语义自动发现并加载。
如果共享给同事，文档里只写 ~ 形式路径，不写真实用户名。
如果遇到未命中：
- 优先增强
description 的触发词
- 或让用户在请求里明确提到
dev-workflow
使用时机
- 用户想梳理现有系统、已上线逻辑、核心业务流程、模块职责
- 用户描述新功能/项目想法，需要需求分析
- 用户提到「方案设计」「架构设计」「怎么实现」
- 用户提到「代码实现」「开始写代码」「帮我实现」
- 用户提到「代码审查」「Review」「检查代码」「看看有没有问题」
- 用户提到「bug」「报错」「崩溃」「异常」「不工作」「出错了」「测试失败」
- 用户提到「继续上一轮」「接着做」「继续分析」「继续实现」「继续修」
- 用户面对大型项目，希望通过记忆文档和多轮接力完成复杂任务
- 用户希望代码默认写得更完整，注释更多，减少来回确认和 token 消耗
默认高优先级偏好
当用户没有单独覆盖时，dev-workflow 默认附带以下偏好执行：
1. 注释偏好默认偏强
- 新增代码默认不是“极简无注释”风格，而是“便于接手和维护”的风格。
- 对外接口、Controller、Service 接口、Service 实现、核心领域方法、复杂工具函数，默认都应补充函数级注释。
- 关键成员变量、配置常量、复杂局部变量、重要状态位、核心分支判断，默认都应补充说明性注释。
- 过程中的关键步骤注释要比普通项目更充分，尤其是：
- 业务分支多
- 状态流转复杂
- 幂等/补偿/回滚/兼容逻辑
- 脚本化修正逻辑
- 注释必须解释“为什么”和“业务意图”，不能只写同义废话。
2. 默认直接落地，不反复问下一步
- 只要用户意图已经足够明确，默认直接做完搜索、设计、改码、校验、文档同步，不把本可连续完成的工作拆成多轮确认。
- 不要把“我接下来要不要继续第 2 步 / 第 3 步”这种可自主推进的动作反复抛回给用户。
- 只有在以下情况才中断并询问用户：
- 需求本身存在关键歧义
- 多个方案的业务取舍差异很大
- 涉及高风险破坏性修改、数据迁移、批量删除、对外口径改变
- 当前上下文或权限确实无法继续
3. 默认优先节省 token
- 能一口气完成的事就一口气完成，不为了“流程感”强行拆成很多往返。
- 优先读取双主文档和必要代码，避免重复全仓扫描。
- 输出时只保留当前有增量价值的信息，不重复复述已确认的大段背景。
- 多文件实现优先一次性完成同批次修改、验证、记忆回写，而不是每改一两个文件就停下来问。
- 只有当任务确实过大、存在明显上下文风险时，才进入续接模式。
4. 默认产物要便于后续复用
- 不只交付代码，还要顺手补齐后续最容易反复解释的注释、文档、脚本说明、边界条件说明。
- 如果用户一再补充同类风格偏好，应把这些偏好沉淀进 skill，而不是只在当前轮临时遵守。
Step 0：每轮必读双主文档（最优先，不得跳过）
无论用户说「继续」「接着做」「帮我写一下」还是提出任何开发请求，都必须先完成此步骤，再做任何其他事情。对话历史或摘要不等于文档，不可用来代替读取。
必做动作
- 用 read_file 读取项目根目录下的
开发工作流记忆.md
- 用 read_file 读取项目根目录下的
项目需求逻辑梳理.md
- 在开始执行任务前，先用 1-3 句话输出：当前阶段 / 上一轮做了什么 / 本轮要做什么
读完文档再往下走。不读文档直接开工，视为流程违规。
若文档不存在
首次使用时，按 working-memory.md 与 project-logic-doc.md 初始化两个文档，再继续。
Step 1：识别当前步骤
根据用户需求选择对应 reference 文件执行：
项目梳理附加说明：project-analysis.md 内含两个子文件：
方案设计专项规则说明：design.md 内含两个强约束子流程：
Step 2：读取或初始化双主文档
在执行任意阶段前，先处理两个核心文档：
专项规则追加读取（仅在对应阶段执行时）：
项目根目录识别规则：
- 优先使用
README.md 所在目录
- 若项目没有
README.md，则使用当前仓库根目录
- 每个项目只维护一个唯一的
开发工作流记忆.md
- 每个项目只维护一个唯一的
项目需求逻辑梳理.md
后续阶段默认先读这两个文档，再补充读取代码与用户新输入。
Step 3：判断是否需要临时方案文档
在真正执行前，先判断当前工作是否适合直接写入项目记忆文档：
- 若内容属于已确认需求、已确认设计、已落地实现、已验证根因，则写入
开发工作流记忆.md
- 若内容只是候选方案、阶段计划、迭代草案、待用户确认的做法，则先写入临时方案文档
临时方案文档默认命名：
使用规则：
- 先根据场景选择对应方案模板并询问用户是否按此执行
- 用户确认后，再把确认结果和最终落地结论同步到
开发工作流记忆.md
- 未确认的临时方案不要直接当作项目事实写入记忆文档
Step 4：收集本轮输入
- 先从
开发工作流记忆.md 提取当前任务背景、已确认约束、历史决策、最近改动
- 再从
项目需求逻辑梳理.md 提取业务流程、技术实现细节、条件分支、状态流转、库表字段含义
- 再从用户当前输入提取新增目标、变化点、最新限制条件
- 只在中间记忆缺失或明显过期时，补充搜索代码和文件内容
执行前先判断复杂度：
- 小模块、小迭代、单点问题：保持轻量
- 常规中大型任务：使用标准结构
- 超大项目、跨多轮任务：再启用深度结构和分批方案
如果用户本轮需求与记忆文档记录不一致：
- 先以用户当前明确表述为准
- 将失效内容标记为“已废弃”或直接替换
- 避免把旧结论继续当作当前事实使用
Step 5：检查上下文是否足够
执行过程中持续评估上下文是否足够支撑当前阶段：
- 是否已经无法同时保留任务目标、当前阶段、关键约束、最近修改文件、未决问题
- 是否项目过大，继续搜索会挤掉当前任务关键状态
- 是否需要跨多个模块、多个文件批次、多个迭代轮次持续推进
若上下文充足：继续当前流程。
若上下文不足：按 continuation.md 执行完整续接流程（同步文档 → 生成交接摘要 → 输出续接指令）。
建议继续指令格式：
继续 dev-workflow：请先读取项目根目录下的 开发工作流记忆.md 和 项目需求逻辑梳理.md；如果存在 功能迭代方案.md、问题修复方案.md、重构分批方案.md 或 开发工作流方案.md，请把相关方案文档一并读取，然后从“下一步”继续执行。
说明：skill 本身不能真正自动创建一个新的聊天窗口，但必须在判断上下文不足时主动做“停靠 + 交接 + 指引继续”。
Step 6：执行对应阶段
读取对应 reference 中的完整流程，按步骤执行，输出符合该阶段要求的交付物。
执行时默认还要遵守两条附加原则：
- 若用户是在要代码，而不是在讨论方案，默认直接完成尽可能完整的一批代码，不故意拆成多个“下一步”。
- 若本轮已经可以顺手补齐注释、文档、脚本、测试或记忆同步，就一并完成，减少下一轮额外 token 消耗。
Step 7：完成前强制同步文档（交付物的一部分，不可省略）
在向用户回复「已完成」「完工」「全部做好了」之前，必须先完成文档同步。未更新文档 = 本轮工作未完整交付。
本轮只要发生以下任意一项，就必须更新对应文档：
- 确认了新的需求范围或排除了旧需求
- 做出了新的技术决策或推翻旧方案
- 修改了代码、配置、依赖、脚本、测试
- 发现了新的根因、风险、阻塞项、假设
- 阶段结论发生变化
- 完成了接口设计（必须在
开发工作流记忆.md 的「方案与决策」节记录接口路径和关键字段）
回写要求：
- 只保留当前仍然有效的信息，删除或覆盖失效内容
- 用简洁事实表达，避免冗长过程记录
- 明确写出“本轮新增”“本轮失效”“下一步动作”
- 未确认的方案不写入记忆文档，保留在临时方案文档中
开发工作流记忆.md 保持简洁，偏向当前任务状态项目需求逻辑梳理.md 保持技术细节充分，重点维护受影响的模块、流程、条件分支、表字段解释
Step 7.5：执行后自我进化
每完成一轮需求、设计、实现、审查或修复后，主动检查这次工作是否带来了新的稳定认知：
- 是否发现了新的项目约定、隐含规则、命名习惯、边界条件
- 是否发现了之前文档缺失的关键流程、条件分支、字段语义
- 是否用户重复纠正过同一类背景信息或业务逻辑
若答案为“是”，则执行：
- 将项目级稳定认知写入
项目需求逻辑梳理.md
- 将当前轮任务状态写入
开发工作流记忆.md
- 让后续轮次直接复用这些信息，而不是再次向用户索取相同上下文
自我进化的原则：
- 进化的是“已验证、可复用”的认知，不是猜测
- 小改动增量更新，避免把文档越写越乱
- 若发现旧结论失效，应主动覆盖，而不是并存冲突版本
Step 8：结束前做一次最终同步
阶段完成前，必须再次同步中间记忆文档，至少更新：
当前阶段当前任务已确认事实已完成事项最近修改文件待确认问题下一步
若本轮留下待确认方案，也同步检查 开发工作流方案.md 是否需要更新或清理。
同时检查 项目需求逻辑梳理.md 中受本轮影响的章节是否需要增量更新；小迭代只改受影响部分，不要求每次整篇重写。
注意事项
- 流程串联：需求理解 → 方案设计 → 代码实现 → 代码审查 → Bug 修复；每步完成后提示用户进入下一阶段
- 上游缺失时：提示用户先完成前置步骤，或简要收集关键信息后继续
- 大型项目优先依赖中间记忆文档组织上下文，而不是每轮从头阅读整个仓库
- 中间记忆文档不是流水账，而是持续维护的“当前有效事实表”
- 对于复杂迭代，优先把“候选方案”和“已确认事实”分层管理，不要混写
- 检测到上下文压力过高时，应主动触发续接流程，而不是硬撑到信息混乱
- 处理“项目梳理/复杂逻辑梳理”时，优先给出模块、主流程、关键状态流转、外部依赖、风险点的结构化整理结果
- 不要把每个小任务都套成重型流程，复杂度应与任务规模匹配
- 代码实现默认采用“高可维护性注释风格”，尤其是接口层、实现层、关键变量和复杂过程逻辑
- 若用户没有明确要求只出方案，则应优先直接落地代码、验证并同步文档，而不是停留在计划层
- 若可以在当前轮完成，就不要为了形式感频繁输出“下一步是否继续”，这会浪费 token
