用途：quick-do 用于在当前会话中直接完成小型、已充分理解且验证路径明确的开发变更，例如局部修复、机械式编辑、配置调整和短脚本。它强调以最小仪式感推进工作，适合用户明确要求快速处理时使用。
主要能力与原则：先阅读请求、适用的项目规则和受影响文件，再动手编辑；修改共享行为时检查相关调用方，避免无关探索。先快速查看实际环境（环境是否激活、依赖是否可导入、文件与调用方是否符合预期），这一步不需要审批。修复根因而非表面症状，例如查找被修改内容的调用方，在共同路径上修复。普通实现细节优先采用显而易见的解释；正常快速路径中最多提一个聚焦的澄清问题。不写计划文档、不做盘问式讨论、不使用子代理；仅在确有需要时使用待办事项。保持最小可用改动：优先复用现有代码，其次标准库或原生特性，再次已安装依赖；避免过度封装、推测性抽象、防御性样板、冗余检查或无关清理，同时保留必要的信任边界校验、安全、可访问性和数据保护。破坏性或不可逆操作前须展示影响并获得明确授权。
验证与收尾：默认采用最小真实执行路径并重读改动，检查请求的行为而非仅确认无错误；纯文档变更则检查内容与适用格式检查。默认不添加测试、TDD 或验证脚本，但用户明确要求或项目强制检查仍需遵守。只报告实际运行过的内容；静态检查、成功加载或注入输入不能证明端到端行为。若无法执行，说明未验证部分及用户需执行的具体检查。受阻是合法结果，应说明剩余事项和用户需运行的检查，不得伪造完成或静默跳过步骤。最后用一行说明改动与验证状态，包括阻塞或所需用户检查。
适用场景与限制：适合小型、边界清晰、验证方式已知的变更。若卡在设计、兼容性或验收决策上，应停止并建议改用 steady-do；若不确定 quick 还是 steady，选 steady；需要移交到独立会话时建议 plan-brief。用户明确选择的工作流优先，不得静默切换；若所选流程不适合任务，应说明原因并询问。技能说明为英文，回复与交付物遵循用户语言（默认中文）。这些流程约束的是被请求的开发工作，不适用于所有解释或只读问题。