用途
design-solution 在需求已获批准之后使用，产出 docs/specs/<YYYY-MM-DD>-<feature>/design.md，回答需求“如何”被满足。输入契约是需求文件，必须先完整阅读。
主要能力与流程
准备：从技能集模板 templates/design.md 起步，查找顺序为：本 SKILL.md 旁的 templates/、${CLAUDE_PLUGIN_ROOT}/templates、../../../templates。模板中的每个标题都是必需槽位。开始前为步骤 1、2、2b、3、4 各建一个 todo，按序完成，仅在满足各步 Done when 后勾选。该技能拥有自己的清单，独立于上游 specify-behavior 与下游 plan-tasks。
步骤 1：上下文与决策：用 2–4 段说明现状、约束方法的关键约束、以及因该约束被排除的替代方案。派发扫描子代理绘制被触及表面（签名、数据形状、保存/加载路径）为摘要文件（.skills/<CODE>/scan.md，CODE 之前为 .skills/_pending-<slug>/scan.md），而非原始源码；仅当某决策依赖精确内容时才将具体文件拉入上下文。若用户表示从未读过被触及子系统，提示其可运行 /understand，但不要调用。扫描摘要之后、复用阶梯之前运行一次全新检索：必需子技能 load-subgraph，以功能 CODE、需求术语、扫描候选路径为种子；依据 skills/execution/load-subgraph/references/grounded-claims.md，不得仅凭 envelope 编造 Reuse。将发现阶段锁定的决策记录为编号列表。难以逆转、缺乏上下文会令人意外且存在真实取舍的决策还需 ADR（由 define-domain 掌管 ADR 门）。存在 docs/architecture/ 主干时，其 ARCH-N 不变量是输入：读取并在步骤 2 引用；若决策须违背不变量，属 ADR 或取代事件，需记录 ADR 或在主干中以删除线取代不变量，不得静默违反。设计跨越信任/合规、可靠性、标准领域、架构形态或跨模块结构时，读取并遵循同目录 system-docs.md。
步骤 2：架构：每个模块或区域一个 ### 小节，按模板槽位顺序填写：Satisfies（本模块满足的需求 ID；无此行则标为基础设施或不属此节）、Reuse（成立的最高阶梯层级与具体目标，或 none——新代码 rung 7 及理由）、Respects（无主干或无依赖时省略）、Surface（本节的改动会影响已有读取者时必需；通过引用搜索而非记忆找出所有受影响读取者——仓库内调用点、测试、持久化行、发出事件、外部订阅者、文档、配置——并各给一个处置：replace 本次变更已迁移、旧路径删除；compat 两条路径并存，仅限本次无法触及的读取者且须指出移除后续项；frozen 本变更不得单方修改的契约，须说明是绕开契约还是以该所有者同意为门）、Security（可选，仅列 Approved 的 docs/security/ 中定义的可搜索 TB-N、THR-N、CMP-N ID，不放在 Respects）、Reliability（可选，仅列 Approved 的 docs/ops/reliability.md 中定义的 SLO-N ID）、Interface（调用方所知，小于实现）、Depth（rung 7 新模块给出删除测试一句话；复用 rungs 2–5 填 n/a——扩展 <目标>）、Locality（落点与对邻居影响：leave | extend | extract 加一句）。新增第三方依赖须由用户决定：介绍它是什么、为何合适、成本，并等待同意后再写入设计；已安装依赖无需询问。真正困难的接口（新持久化、并发、插件缝）读取 design-principles.md 取一个基础、移植不超过 2 个想法。构建任何模块前攀登复用阶梯并在最高成立层级停下：是否需要存在（YAGNI）→ 本代码库已有 → 标准库或语言内建 → 平台/框架/运行时特性 → 已安装依赖 → 一行代码 → 最后才是最小新代码。阶梯不豁免输入校验、防数据丢失的错误处理、安全、可访问性及需求要求的一切。
步骤 2b：UI 设计（可观察条件）：若任一 Satisfies ID 通过浏览器渲染面交付则填写模板的 ## UI design，否则删除该节。填写时读取并遵循同目录 ui-design-recipe.md。
步骤 3：约定测试接缝：填写“Seams for testing”表：测试书写的公共边界、每个接缝覆盖的需求 ID、测试类型（unit/integration/e2e）。优先使用已有接缝；新接缝理想数为 0 或 1。测试优先技能拒绝在未约定的接缝写测试，此表即契约。每个需求 ID 须至少映射到一个接缝行。
步骤 4：覆盖度自检与审批门：从头到尾走查 requirements.md，每个 ID 恰好出现在一个 Satisfies 行（或列为有意未映射并给理由）；扫描占位符与内部矛盾。复用覆盖：每个架构节的 Reuse 行须与其声称的阶梯层级相符。结构覆盖：每节有 Interface、Depth、Locality。Surface 覆盖：自行重跑引用搜索确认清单完整且每行有处置；compat 行无移除后续项，或变更的外部/持久化读取者未标 frozen 则失败。UI 覆盖：重新评估步骤 2b 谓词。派发独立设计评审子代理（不自审），携带设计、requirements.md、扫描摘要与仓库，证明代码面向声明（具名接缝与路径存在，file:line）、结构声明；发现写入 .skills/<CODE>/design-review.md。上游同步回写不可跳过：设计发现与已批准需求矛盾的事实时，必须修正需求原文并重新提交审批，不得悄悄重新解释措辞。将文件逐节呈现给用户并停下等待审批，通过后设 Status: Approved。
退出：必需子技能 plan-tasks。
适用场景
- 需求已批准、需要编写技术设计/架构文档时
- 需要追踪需求到架构模块的覆盖关系时
- 需要约定测试接缝并做设计自检与独立评审时
限制
- 本资料未提供具体收费、价格或平台要求。
- 部分步骤依赖子代理与特定技能集环境（如 CLAUDE_PLUGIN_ROOT、skills 目录结构）；无子代理时需自行以直接阅读方式完成。
- 依赖的模板与参考文件（templates/design.md、system-docs.md、design-principles.md、ui-design-recipe.md、grounded-claims.md）需在所描述路径存在。
- 新增第三方依赖须先获用户同意。