use-workflow

使用工作流

将工作分配给最精简且合适的工作流。遵循仓库内的说明和用户的明确要求。如果两者存在实质性冲突，应说明冲突并给出建议，而不是擅自选择。不要把明确的低风险任务变成一个项目。

如有仓库术语表，请使用；否则请使用 workflow-language.md。

路由

• 解释代码区域或流程 -> explain-codebase
• 诊断 Bug、故障、偶发问题、意外输出或回归 -> diagnose-issue
• 用户明确要求规划，或存在重大歧义、协调需求、跨领域范围、不可逆性或风险 -> plan-work
• 执行已通过 Plan、交接、调查结果、简报、文档任务、修复或重构确定的范围 -> implement-work
• 编写续接提示词或文件 -> write-handoff
• 审查 Plan、更改、修复轮次或非代码产物 -> review-work
• 探索架构改进机会 -> improve-architecture
• 在不改变预期行为的前提下简化已限定范围的区域 -> simplify-work
• 通过一次性模拟或逻辑原型回答设计问题 -> plan-prototype
• 编写提交消息或提交更改 -> 如果已安装，使用 commit-work
• 创建或更新 PR、交付堆叠 PR，或运行堆叠合并循环 -> 如果已安装，使用 manage-pr
• 设置隔离的工作树或清理过期工作树 -> 如果已安装，使用 manage-worktrees
• 回答编码规范问题，或为结构/验证决策提供依据 -> 如果已安装，使用 coding-standards

明确且低风险的工作可以直接处理；如果执行纪律或续接上下文能带来实质帮助，则使用 implement-work。

具体的架构审查应使用 review-work。对于明确选定且保持行为不变的简化，使用 simplify-work；对于其他已确定的更改，使用 implement-work；如果仍需探索改进机会或接口形态，则使用 improve-architecture。

如果有多个技能适用，选择最具体的技能。如果用户指定了某个技能，就使用该技能。

成本与权限

• 根据实际的不确定性和风险，匹配问题、研究、工具、产物、委派和验证。
• 合并向任务负责人提出的问题，并附上建议；不要询问仓库本身就能回答的问题。
• 只针对可能实质性改变结果的信息缺口开展研究，并优先使用本地证据和一手资料。
• 除非用户明确要求修复或实施，否则审查和诊断仅限只读。
• 除非用户要求或授权的工作流自然要求，否则不要创建 Plan、路线图、持久文档、交接文件、工作树、提交、PR 或问题。
• 每个实施阶段结束时，都必须在全新上下文中独立审查该阶段的完整范围。没有 Plan 的直接实施也视为一个等效阶段，并在交付前接受同样的审查。
• Plan 可以在高影响任务或任务组之后增加审查检查点。低影响任务无需逐项立即审查。
• 不要递归审查审查结果。根据一手证据核实委派的结论，并在请求范围完成后停止。

将工作流状态保存在工作流产物中。持久交付产物不得依赖 Plan 或路线图文件，也不得依赖工作流内部标识符。