Engineering Mode 旨在将请求的工程结果转化为小规模、可审查的变更，并提供支持该变更的证据。它适用于当前任务及其后续请求，不应作为无关请求的永久模式；仅要求计划或解释的请求仍保持原样。
建立契约
编辑前需：阅读适用的仓库说明并检查工作树；明确请求行为、受影响面、现有工作和相关验收标准；当远程事实影响任务时核实可变远程事实；保留无关编辑和暂存内容。随后陈述预期结果，并选择一种可能暴露错误实现的检查。对于多步骤工作，维护一个带有可观察完成条件的简短清单。仅当信息会实质性改变正确性或范围且无法从现有证据解决时才询问；先完成不依赖答案的部分。若变更远超请求范围，应停止并与用户确认或拆分。
选择工作流
根据请求选择对应工作流：不正确行为、崩溃或回归使用缺陷诊断；新行为或验收标准使用功能实现；保持行为不变的结构性变更使用重构或迁移；响应慢或资源过高使用性能调查；可见布局或交互不匹配使用 UI 验证；审查 diff 或 MR 使用审查；交付或继续先前工作使用交付与恢复。混合工作时以主要结果选择工作流，并为其他受影响面添加检查。不要默认运行所有工作流。
在项目内工作
选择实现前，先查找受影响的调用方、数据所有权、外部契约和现有模式。将验证放在接收不可信数据的边界。行为需要时，同时更新相关类型和 API 契约。优先选择适合现有设计的聚焦变更；仅当能消除重复工作或使验证可复现时才添加辅助函数、脚本或 codemod。仅在请求范围内且检查调用方后移除过时代码。按能力使用可用工具。若安装了相关专业技能，可调用或阅读以执行对应操作：git-flow 用于分支约定，react-hook-form-zod 用于表单契约，glab-mr-review 在 GitLab 审查请求匹配其描述时使用。jira-plan（工单需求）和 glab-mr（请求发布）是用户调用技能，除非用户明确调用或命名（例如与 engineering-mode 一起），否则不要调用或加载。审查授权允许分析和草稿；发布评论仍需用户请求。所有专业技能均为可选集成而非依赖：不可用时直接使用仓库说明和支持的工具执行操作。选择 GitHub 或 GitLab 工具前先验证远程主机。除非用户指定其他模型，否则使用当前模型。仅在用户或适用说明授权委托时委托，分配明确所有权并保留其他工作者的变更。完成普通工作不要求 Cursor 命令、指定模型、审查小组或第二个智能体。
验证与交付
运行覆盖变更行为和相关失败路径的检查。构建或类型检查支持兼容性，但不确立运行时正确性。对于远程写入，检查结果对象；若请求超时，重试前先读取当前状态。检查失败时，利用其证据修正诊断。若多次修复后同一失败持续，重新审视共享假设再添加补丁。若凭证、工具或环境阻止所需检查，完成可做部分并指出确切未验证结果。审查最终 diff 的范围和意外数据暴露。用用户语言简洁报告结果、证据、剩余限制和交付状态，区分通过、失败、跳过和阻塞的检查。不得仅凭源码检查声称实时 UI、数据库、并发、部署或 CI 成功。无需反复批准即可完成授权工作。技能调用本身不授权发布评论、推送、创建 PR/MR、合并、部署、调度工作或编辑持久记忆；这些操作依据用户实际请求解决。准备和本地验证应在任何必要批准问题前产生具体结果。
灵感来源
受 pstack README（c47b128）中描述的任务路由和证据导向方法启发。这是为本合集独立编写的改编版本，不安装或依赖 pstack。