用途 Quickie 用于在当前会话中依次运行 design-specs 与 implementation-plan 两个技能，从一个请求或意图文件出发，产出经校验的设计规格（spec.md）和实施计划（plan.md）。它本身不实施、也不执行计划。
主要能力
- 接受用户直接请求、意图文件或主题文件夹作为输入。若没有主题文件夹，从请求中推导最短主题；不额外要求单独的意图文件或主题。
- 在委托自动模式下，按 design-specs 的范围、UI、HLD 和最终检查规则执行，只纳入明确需求与必要的隐含验收条件；可选建议记录为排除或延后并说明原因，不静默增加推荐范围。
- 对校验通过的规格再运行 implementation-plan，检查源哈希与仓库新鲜度，应用其完整计划检查，并以同一有限委托记录计划批准。
- 保存的 spec.md 与 plan.md 仅在所有适用检查通过后标记 status: validated。
- 使用 ASD-STE100 语言规则撰写聊天内容和交付物。
- 报告两个产物的路径、重要假设和被排除的可选工作，并在实施前停止。
使用方式 调用 quickie 即视为对常规范围、UI、HLD、规格和计划审批的委托。需先阅读两个完整技能及其产物模板，并遵循其证据、设计、可追溯性、新鲜度和计划规则。若请求缺少可观察结果，先询问该结果再起草。写入前阅读既有主题产物；未经许可不得覆盖已批准内容。在规格批准记录和计划批准记录中说明委托及其边界，不得声称用户审阅了其并未审阅的内容。
需在最早受影响的关卡暂停并询问用户的情形包括：意图、验收、范围或明确用户选择发生实质变更；不同方案产生不同的用户可见结果；设计引入或改变公共契约、持久格式、迁移、安全或隐私行为，或造成未获授权的重大兼容性或数据丢失风险；重要依赖、成本、部署或架构选择存在现实替代方案且仓库无明确先例；必需事实缺失、来源实质冲突、既有义务与请求冲突或结果不可行；已批准产物需替换，或源哈希变化影响已批准决策。常规推断、UI 细节、私有结构、测试选择和可选增强不视为破坏性；可选增强直接排除而非询问是否扩大范围。不得从沉默或事实性回答推断同意。用户取消即停止，保留草稿以便恢复。
流程
- 检查相关代码、调用方、测试、契约与既有产物，区分用户输入、仓库事实、推断与未知项。
- 对给定意图运行 design-specs，在委托自动模式下应用范围、UI、HLD 与最终检查，记录各关卡批准；遇到破坏性决策时在受影响关卡询问；全部适用检查通过后保存 spec.md 并标记 validated。
- 对该已校验规格运行 implementation-plan，检查源哈希与仓库新鲜度，应用完整计划检查并记录批准；需要时询问破坏性决策或更正源；全部检查通过后保存 plan.md 并标记 validated。
- 报告两个路径、重要假设和被排除的可选工作，在实施前停止。
恢复时读取已保存产物与来源，校验哈希和批准记录，从最早未完成或受影响的关卡继续。不得通过把阻塞项标为常规来绕过它；不得运行 git commit、创建分支、推送更改，也不得修改生产代码、测试、依赖或项目配置。
适用场景与限制 适用于在已有仓库上下文中快速生成经验证的设计规格与实施计划的流程，尤其适合希望减少常规审批交互但保留破坏性决策人工确认的场合。限制包括：不实施计划；不执行代码或配置变更；不替代用户对破坏性决策的确认；不覆盖已批准内容；关于收费、价格、平台支持等细节，资料暂未提供。