技能（Skill）：设计解决方案

目的 (Purpose)

将已验证需求转化为单一的、免实施的设计文档。该设计描述了架构、组件、数据流和权衡，以便下游技能（例如“分解任务”）可以毫无歧义地导出可执行任务列表。

核心目标（Core Objective）

首要目标：根据需求制作一份已验证的设计文档，作为实施规划的唯一事实来源；没有生成任何代码或实现步骤。

成功标准（必须满足所有要求）：

✅ 设计文档已批准并保留：写入“docs/design-decisions/YYYY-MM-DD-.md”（或每个“docs/ARTIFACT_NORMS.md”的项目约定路径）、已提交且用户明确批准
✅ 需求可追溯性：设计明确引用或总结其满足的需求
✅ 已记录的替代方案：至少考虑 2-3 种方法并进行权衡（优点/缺点/最佳方案）
✅ 错误处理和测试策略：关键失败路径和验证方法（测试方法，而不是测试代码）已记录
✅ 无实施：零代码、脚手架或实施任务；仅设计
✅ 下游就绪：读者可以将设计分解为具有依赖性和验收标准的任务，而无需提出澄清问题

验收测试：有人可以单独使用这个设计文档来生成完整的、有序的任务列表（例如通过“breakdown-tasks”）而不提出澄清问题吗？

范围边界（范围边界）

本技能负责：

需求文档→设计文档（架构、组件、数据流、接口）
权衡分析和替代方法
设计批准和持久性作为实施规划的单一事实来源

本技能不负责：

引出或验证需求（使用“分析需求”）
将设计转化为任务列表（使用“breakdown-tasks”）
编写代码或实现（任何实现技能）
没有需求文档的粗略想法设计（使用此技能以粗略想法作为输入）

转交点：当设计被批准并坚持时，将其移交给breakdown-tasks来生成tasks.md（或同等文件）。

使用场景（用例）

后期需求设计：您有一份已验证的需求文档，需要在实施前进行详细的设计。
来自需求的架构：需求明确；您需要组件边界、数据流和技术权衡。
单一事实来源：您需要一份可供实施和任务分解依赖的设计文档。

行为（行为）

交互（互动）政策

默认：需要需求产品（路径或内容）；如果存在，则使用设计路径的项目规范
选择选项：澄清时一次一个问题；在有用的地方提供“[A][B][C]”作为设计选择
确认：转交前必须用户同意设计；未获批准前不予实施

硬门：无实施

DO NOT write code, scaffold projects, or produce implementation steps.
Output is design documentation only. Implementation is downstream (e.g. breakdown-tasks then execution).

第 1 阶段：摄取要求

负载需求：阅读需求文档（例如需求.md或docs/requirements-planning/*.md）。
确认范围：与用户简要确认此需求文档是本设计的范围（或同意子集）。
识别约束：从需求中提取约束、验收标准和范围外的项目。

第 2 阶段：探索替代方案和权衡

提出 2-3 种方法：满足需求的架构/组件/数据流选项。
记录权衡：对于每个选项：优点、缺点、“最适合”。
推荐：说明推荐的方法和理由；请用户选择或调整。

第 3 阶段：生成设计文档

结构：目标、架构、组件、数据流、错误处理策略（关键故障路径）、测试策略（验证方法，而不是测试代码）、考虑的权衡、验收标准（可追溯到需求）。
Scale to Complexity：简单范围的缩写；需要时提供更多细节，以便任务分解明确。
解析路径：先检查docs/ARTIFACT_NORMS.md（项目覆盖）；默认后备是每个 specs/artifact-contract.md 的 docs/design-decisions/YYYY-MM-DD-<topic>.md。
编写并保存：保存带有前置内容的设计（artifact_type: 设计、created_by: 设计解决方案、lifecycle: snapshot、created_at）。

第 4 阶段：批准和移交

用户批准：在宣布完成之前获得明确批准。
Handoff：建议使用此设计的“breakdown-tasks”作为输入来生成tasks.md。

输入与输出 (Input & Output)

角色	内容
输入	需求文档（路径或内容）；可选的项目背景、现有设计或 ADR
输出	设计文档位于“docs/design-decisions/YYYY-MM-DD-.md”（或每个“docs/ARTIFACT_NORMS.md”的项目路径）；实施和任务分解的单一事实来源

限制（限制）

硬边界（Hard Boundaries）

无实施：不生成代码、文件布局或分步实施说明。
需求第一：当需求模糊或缺失时，不要运行此技能；首先移交给“分析需求”。
仅设计：不生成任务列表；为此，请移交给“分解任务”。

技能边界 (Skill Boundaries)（避免重叠）

不要做这些（其他技能可以处理它们）：

需求获取或验证→“分析需求”
任务分解或计划 → 分解任务
代码实施或重构→实施技巧

自检（Self-Check）

设计文档已批准并保留：写入“docs/design-decisions/YYYY-MM-DD-.md”（或每个“docs/ARTIFACT_NORMS.md”的项目路径）、已提交、用户明确批准
要求被引用或总结；溯源清晰
记录了至少 2-3 个具有权衡的替代方案
错误处理和测试策略：关键故障路径和验证方法已记录
输出中没有代码或实现步骤
读者可以根据此设计生成任务列表，无需进一步说明

示例（示例）

示例1：已验证需求的标准设计

调用：“我们在 docs/requirements-planning/core-v1.md 中有需求。为其制作一个设计文档。”

代理：使用设计解决方案；读取需求；提出 2-3 个架构选项并进行权衡；将设计写入 docs/design-decisions/YYYY-MM-DD-core-v1.md；获得用户认可；建议在该设计上运行分解任务来获取tasks.md。

示例 2：边缘情况 — 范围非常小

调用：“对小型 CLI 工具的要求已在 docs/requirements-planning/one-off-migration.md 中捕获。我们还需要完整的设计文档吗？”

代理人：

确认需求已验证，但范围较小。
生成简洁的设计文档，该文档仍然涵盖架构、数据流和约束，但保持各部分简短且重点突出。
明确说明为什么轻量级设计就足够了，并将文档标记为以后回归或重复运行的单一事实来源。
获得用户批准，然后在共享或重复实施的情况下推荐“分解任务”。

design-solution