quick-do

快速执行：理解 → 执行 → 验证

适用情形

• 规模小、理解明确且验证路径已知的更改：本地化修复、机械式编辑、配置微调、短脚本。
• 用户的明确选择优先——绝不默默切换工作流；如果所选工作流不适用于该任务，说明原因并询问。若在设计、兼容性或验收决策上遇阻 → 停下并建议使用 steady-do（如果拿不准该选 quick 还是 steady，就用 steady）；若要移交给另一个会话 → 建议使用 plan-brief。
• 这些工作流适用于用户要求的开发工作，不适用于所有解释性回答或只读问题。技能说明使用英文；回复和交付内容遵循用户使用的语言（默认中文）。

执行工作

• 编辑前阅读请求、适用的项目规则和受影响的文件。更改共享行为时检查相关调用方；避免无关探索。
• 先查看当前环境（几秒钟，无需批准）： 环境已激活，依赖确实可导入，文件和调用方符合预期——快速看一眼，就能避免一轮本可避免的错误。这里的重点是省去繁文缛节，而不是省略这一步查看。
• 修复根本原因，而非表面症状：搜索你修改内容的调用方，并在它们共同经过的地方修复——在每个调用方重复添加保护条件会造成更大的差异，也会让其他调用方继续出错。
• 对普通实现细节，优先采用直观的解释。在常规快速流程中，最多提出一个针对性澄清问题；如果调查发现存在重大歧义或风险，就停下并建议使用 steady-do，不要为了满足提问限制而猜测。
• 不要编写计划文档、进行盘问式讨论或使用子 Agent。只有在工作内容或宿主指令要求时才使用待办事项；不要为了计划而计划。
• 保持更改尽可能小且可用：先复用现有代码，再考虑标准库／原生功能，最后才使用已安装的依赖。不要过度封装、臆测性抽象、堆砌防御性样板代码、重复检查或进行无关清理。保留必要的信任边界验证、安全性、无障碍性和数据保护措施。
• 执行破坏性或不可逆操作前，展示影响并取得明确授权。快速工作流不允许覆盖机密信息或更改无关环境。

验证并完成

• 默认采用最小的真实执行路径，并重新阅读更改内容；检查请求的行为，而不只是确认没有报错。对于仅涉及文档的更改，检查内容和适用的格式检查。
• 默认不要添加测试、采用 TDD 或编写验证脚本。遵循用户的明确要求和项目强制检查；本工作流不会免除这些要求。
• 只报告实际运行过的内容。静态检查、成功加载或注入输入，都不能证明端到端行为正常。如果无法执行，说明仍有哪些内容未验证，以及用户需要进行的具体检查。
• 受阻也是合理结果： 说明受阻情况、列出尚未完成的内容，以及用户必须运行的确切检查；绝不伪称完成，也绝不默默跳过步骤。
• 最后用一句简短的话说明更改内容和验证状态；如有阻碍或用户需要执行的检查，也一并说明。不要另写报告或总结长文；仍须遵循产品文档和项目记忆要求。