dw 只解决一件事：在不牺牲需求清晰度、设计质量、验证和独立复审的前提下，把软件需求直接做完。
需求 → 设计 → 实施 → 验证 → 复审 → 完成
只有同时满足以下条件才按小需求处理：
- 只有一个可独立验收的用户结果；
- 业务规则、范围、非目标和完成标准清晰；
- 修改局部、可逆，不改变架构、共享组件或公共契约；
- 不触及数据模型、迁移、权限、安全、资金、不可逆操作、并发、事务、一致性或外部生产状态；
- 能在当前任务内完成，并由一组定向验证给出结论。
跨文件、前后端同时改动或代码行数较多，不单独构成大需求。只要仍是一个结果、共享边界已稳定且可以一起验证，就可以是小需求。
出现以下任一情况时按大需求处理：
- 包含多个可独立交付或验收的用户结果；
- 需要跨会话、分阶段推进或多个独立验证里程碑；
- 需要改变架构、共享契约或上述高风险边界；
- 必须先决定关键方案、依赖顺序、迁移策略或需求拆分；
- 当前证据无法证明它满足全部小需求条件。
上述分类用于判断一个独立提出的需求是否需要正式 requirements/design。主 Agent 先给出有证据的分类建议；用户可以决定拆分方式。信息仍不足且会改变分类时，先做有界只读调查，再请求用户决定，不按文件数猜测。
主 Agent 先从用户指令和仓库证据形成短摘要：
- 目标与可观察结果；
- 范围和非目标；
- 验收标准；
- 约束与仍未知的关键事实。
只有未知信息会改变业务语义、公共契约、数据、权限、安全、资金、迁移、不可逆结果或验证充分性时才暂停提问。其余局部、可逆细节遵循现有模式。
只在对话中给出短设计，不创建需求或设计文件：
实施前说明：
- 受影响模块和边界；
- 关键数据流或公共契约；
- 方案取舍和主要风险；
- 3～7 项实施步骤；
- 最小充分验证。
满足小需求条件时，说明后直接实施。
优先遵循项目已有文档约定；没有约定时使用：
docs/tasks/YYYY-MM-DD-<topic>/requirements.md
docs/tasks/YYYY-MM-DD-<topic>/design.md
需求文档记录总体目标、用户结果、范围、非目标、验收标准、约束、待确认项和建议的子需求拆分。总体设计文档记录现状证据、架构与边界、数据流和契约、关键取舍、风险、验证策略，以及每个子需求如何落到总体设计。
两份当前文档作为一个 package 交给独立 design_reviewer；只进行一条评审链。修复至 APPROVED 后，由用户确认当前 package 和拆分，再开始第一个有界子需求。需求和设计不可互相替代。
子需求是父 package 内已确认的有界实施切片，不再按独立需求重新分级。开始时先读取父文档，用对话内短摘要冻结当前切片，然后直接实施，不重复创建 requirements/design。子需求可以触及父设计已明确覆盖的数据、权限、迁移、并发等高风险边界，但仍执行适用的高风险验证和最终专业复审；父 package 已覆盖的设计选择不重复做文档评审。如果实现证据要求改变父范围、验收、架构、契约或关键拆分，先更新受影响文档，由同一 reviewer 复审当前 package，并让用户重新确认被改变的业务范围或关键取舍。
progress.md 仅在跨会话状态无法从父文档、Git diff 和验证结果恢复时创建。
主 Agent 负责范围、决策、集成和最终结论。单点查找直接完成；多模块只读探索可交给 explorer；互不重叠的实现切片可交给 worker。委派只携带完成子任务需要的上下文，并要求返回结论、证据、改动范围、验证和风险。
发现真实扩围、公共契约变化或新的高风险边界时，在写入前请求用户决定。不要把清理、复用、未来兼容或 reviewer 建议自动变成当前范围。
运行覆盖实际影响的最小充分检查。高风险或共享行为不能只靠静态检查。失败时区分本次引入、修改前已存在和环境阻塞；没有结论性证据就不声明通过。
生产代码默认在验证后进行一次独立复审。纯文档、格式、注释或确定性机械变化可以免审并说明理由。
Reviewer 必须把 finding 分为 BLOCKING_IN_SCOPE、SCOPE_CHANGE_REQUIRED 或 NON_BLOCKING_NOTE。阻断项必须映射当前需求、验收、现有契约、适用规则、当前回归或具体高风险不变量，并给出可复现证据；偏好、推测性加固、可选重构和未证实缺口只记录。主 Agent 在修复前独立核验每个 finding，只对确认的范围内 blocker 自行设计最小修复；Reviewer 的实现建议不具有约束力，也不能直接转交给 worker 执行。证据性驳回后，没有新的具体证据就不能继续阻断。同一 Reviewer 只复审原阻断项、修复 delta 及其可能引入的回归。
详细输入、角色选择、verdict 和复审闭环见 review contract。复审不替代测试，也不替用户批准扩围或外部操作。
交付只报告实际改动、验证命令与结果、真实 reviewer verdict 或免审理由、既有失败和残留限制。已修改、已验证、已复审、已提交、已推送、已发布 和 已安装 必须分开。
普通小需求不生成 PRD、spec、plan 或新会话 prompt。大需求保留一份 requirements + design package 和必要时的 progress，不恢复多 skill 文档流水线。