| name | nextclaw-solution-design |
| description | 当用户要求技术方案、方案设计、设计文档、架构方案、实现前设计、交互/前端/后端方案，或开发流程进入“先设计再实现”的阶段时使用。用于产出可执行的方案设计合同，覆盖现状证据、owner、数据流、目录组织、可维护性、非目标、风险与验证标准；本 skill 是开发流程中的方案设计专项，不是完整开发 workflow owner。 |
NextClaw 方案设计专项
定位
本 skill 只负责“方案设计”阶段。完整开发节奏由 nextclaw-delivery-workflow 编排；本 skill 被它或用户显式设计诉求调用。
目标是让方案能指导实现，而不是只写想法、愿景或待办。
使用前置
设计前先确认：
- 问题对象：产品体验、架构边界、数据流、目录组织、运行链路，还是交互细节。
- 现状证据：至少查到当前 owner、调用方、被调用方、已有同类实现或缺口。
- 产物层级：用
project-knowledge-governance 判断写入 docs/designs、docs/plans，还是只在回复中给轻量方案。
如果证据不足，先用 code-investigation-workflow 查链路，不要凭文件名或局部片段做系统结论。
必须覆盖的设计维度
方案至少回答这些问题：
- 用户价值：解决什么用户可见或系统可观察问题。
- 当前事实：现有链路、owner、状态归属、已有约束是什么。
- 推荐方案：主链路是什么，为什么比备选更简单、更清晰。
- Owner 边界：业务逻辑归哪个 manager/service/store/presenter/feature。
- 数据流：事实从哪里产生，在哪里持久化，谁消费，谁不能越界依赖。
- 目录组织：新增或移动文件放在哪个 feature/root/role 下，为什么不是别处。
- 可维护性：删什么、合并什么、避免什么新抽象或重复链路。
- 兼容与迁移：旧数据、旧入口、fallback 是否需要保留，删除条件是什么。
- 非目标：明确本轮不解决什么，防止方案膨胀。
- 验证标准：测试、tsc、lint、冒烟、治理检查分别如何证明方案落地。
专项联动
按设计面选择专项 skill，不要把所有细节塞进本 skill：
- 架构职责、owner、生命周期：
classic-software-design-principles
- 代码审美、抽象必要性、拆分收益：
writing-beautiful-code
- kernel/manager/service/store/presenter 主干分支：
kernel-branch-owner-architecture
- 前端 MVP、view/store/manager 状态归属：
mvp-view-logic-decoupling
- 目录、命名、角色落位：
file-naming-convention、role-first-file-organization、collapsible-feature-root-architecture、file-organization-governance
- 前端样式或交互：
frontend-style-encapsulation、frontend-interaction-quality
- fallback、兼容、恢复路径：
predictable-behavior-first
输出合同
轻量方案可在回复中给出；稳定方案应写入 docs/designs/YYYY-MM-DD-<topic>.design.md。
设计文档建议结构：
# <标题>
## 背景
## 现状依据
## 核心判断
## 推荐方案
## Owner 与数据流
## 目录组织
## 兼容与迁移
## 验收标准
## 非目标
## 后续实现顺序
如果用户明确要求“简约清晰”，保留这些标题但写短，不扩成长篇论证。
反模式
- 把方案设计当成完整开发 workflow owner。
- 只给结论，不给现状证据和 owner 边界。
- 只写 UI/代码步骤，不写数据流、目录组织和验证标准。
- 为了显得完整新增很多抽象、阶段或文档，而没有删减和合并判断。
- 设计文档写完后没有说明它为什么属于
docs/designs 而不是 thought/plan/log。
