steady-do

Steady Do：理解 → 澄清 → 在此实现 → 验证

适用场景

• 在现有项目中开展常规功能、插件、扩展和跨模块工作，并在本次会话中实现和验证。
• 以用户的明确选择为准——绝不悄悄切换工作流；如果所选工作流不适合任务，请说明原因并询问。范围明确且清晰 → quick-do；需要长期推进、持久化计划并交接到单独会话的工作 → plan-brief（如果交接会有帮助但用户未提出，请建议采用）。
• 这些工作流适用于用户要求的开发工作，而不是所有解释或只读问题。技能说明使用英文；回复和交付内容使用用户的语言（默认中文）。

1. 理解需求和项目

• 阅读完整需求以及本次对话中已经确定的决策。区分明确要求和待解决问题；修改文件前先调查。
• 阅读项目规则、README、相关入口和模块。梳理实际流程、复用机会、受影响的调用方和兼容性边界。根据相关性扩展调查范围，不要遍历整个仓库，也不要只凭单个函数进行猜测。
• 先查看实时项目状况（几秒即可，无需批准）： 激活命令和解释器、当前实际导入的依赖版本、启动命令、输入/输出格式、配置路径，以及是否已有相关任务在运行。检查而不是假设解释器或系统 Python。花少量时间查看，就能避免一连串本可避免的错误——省去繁文缛节是目的，但不能省略这一步。
• 在聊天中简要说明目标、范围、不在范围内的事项和可观察的完成标准。不要创建计划文档。

2. 追问尚未解决的决策

使用以下有界、分轮追问方法；它自成一体，无需单独的技能或文档工作流。

• 自行查明事实；让用户做决策。 先查看代码、配置、项目记忆和文档。对于不确定的外部 API 或平台限制，查阅上游文档、源码或问题记录，不要把猜测说成约束。
• 只问会影响行为、范围、兼容性、风险或验收的问题。每个问题都给出建议和简要权衡。按照项目惯例解决一般实现细节。
• 将可以独立回答的问题分为一轮；依赖尚未回答的问题则留到后续轮次。条件允许时使用结构化提问，否则在聊天中编号提问，然后等待回答。
• 每轮结束后，重新判断哪些事项因答案而得以推进，并提出下一轮问题。只要仍有问题会影响行为、范围、兼容性、风险或验收，就继续提问；停止条件是没有重要事项悬而未决，而不是只完成了一轮。
• 不要重复已确定的问题，也不要为了凑数而提问。如果需求和上下文已经解决了相关决策，就直接进入总结。
• 验证模式——必须作出决策，并在总结中说明模式及一行理由：
  • TDD 模式——仅在反馈循环快速且测试成本低时使用（前端/UI、产品服务、可即时运行单元测试的库代码）；调用 tdd 技能。
  • 冒烟测试与代码审阅模式（研究、长时间运行或计算开销大的工作默认采用）：执行最小的真实路径 + 重新阅读自己的改动 + 检查其涉及的相邻行为；之后由用户运行真实工作负载。不搭建测试脚手架，也不编写封装测试的框架。
  • 经验法则：如果编写和运行测试的成本高于它能捕获的故障代价，就不要编写。
• 验收和责任归属——明确观察什么、预期结果是什么，以及最终由谁运行/验证。复用已商定的验证方式，不要再次询问。
• 当实现所必需和验收所必需的模糊之处均已解决，且双方理解一致时停止。不要追问推测性的未来需求，也不要让用户设计每个函数。

3. 回顾并在此处实施

• 简要回顾已达成一致的范围、方法和验证方式，然后直接开始，无需额外设置计划审批环节。如果回顾中出现尚未解决的重要选择，请先等待答复。
• 在本次会话中完成主要实现；不要交给新的会话或执行子 Agent。必要时可委托只读调研或评审，但不要默认采用多 Agent 流程。
• 不编写计划文档、启动提示词、开发报告或评审报告。使用会话待办事项跟踪多步骤工作；仍须遵守必要的产品文档和项目记忆要求。
• 如果新证据表明已达成一致的方法无效，或需要扩大范围、改变外部行为，请暂停受影响的工作并重新对齐。普通的本地实现问题由你自行解决。
• 执行破坏性或不可逆操作前，说明影响并获得明确授权。获准开始并不代表可以覆盖机密信息或更改无关环境。

4. 保持 ponytail 风格

• 采用最小可行改动：优先复用现有代码，其次使用标准库或原生功能，再考虑已安装的依赖。简单问题不要新增依赖。
• 不要过度封装、凭空抽象、防御性样板代码、冗余检查、为未来预搭框架，也不要做无关清理。
• 沿实际调用链修复根本原因，而不只是修复报告中的症状；检查共享逻辑的其他调用方。
• 保留必要的信任边界验证、安全性、无障碍性、数据保护，以及可防止数据丢失的错误处理。

5. 验证并完成

• 默认采用最小的实际执行路径，同时重新检查改动及其相邻行为。验证已达成一致的可观察结果，而不只是确认没有报错。仅涉及文档的改动，应检查内容及适用的格式检查。
• 默认不要新增测试、采用 TDD 或编写验证脚本。遵循用户的明确要求和项目的强制检查；功能开发本身并不意味着必须采用 TDD。
• 区分静态检查、成功加载、本地调用和完整的用户交互。插件能够加载不代表功能可用；注入输入不等于实际终端交互。
• 如果执行需要用户的环境或受到阻碍，请说明哪些内容尚未验证，并给出具体步骤和预期观察结果。受阻也是合理结果——请明确说明阻碍，并指出用户必须运行的确切检查；绝不要捏造完成情况，也不要悄悄省略受阻的工作。
• 简要报告改了什么、实际运行了什么，以及哪些内容需要用户确认。足够时用一行说明；不要另写报告或冗长总结。