conopslisted

# Dev Design 基于开发 conversation 生成结构化技术设计方案，面向产品/测试/开发评审。 ## 为什么需要这个 skill 开发方案是评审阶段的核心输出物。它需要同时满足三个受众： - **开发同事**：看架构、核心逻辑、数据模型、代码导航 - **测试同事**：看测试评审点、验收标准 - **产品同事**：看用户可见行为、范围边界、产品评审点 直接让 agent 自由输出容易产出"教科书风格"的泛泛文档。这个 skill 强制按 固定的 14 节结构 + 写作约束执行，确保文档能直接拿到评审会上用。 ## 生成前：先做契合检查 方案文档产出的前提是问题定义清晰。在写 14 节文档之前，先确认三件事： 1. **解决什么问题？** — 不是功能描述，是用户痛点。不是「加一个 ToF 传感器」，是「当前 LiDAR 在雨雾天无法测距，仿真测试缺数据源」。 2. **为什么现在做？** — 什么变了？需求、排期、依赖、资源？ 3. **怎么算做完了？** — 可验证的终点。不是「传感器能跑」，是「生成的点云帧率和实测传感器误差在 5% 以内」。 如果答案模糊，先和用户对齐再生成文档。这三问的结果反映在方案文档的第 2 节（背景与问题）和第 3 节（方案范围）中。 ## 输入源优先级 dev-design 通常在代码开发之前执行，因此代码不是主要输入源。 优先级按实际可用性排列： 1. **当前对话中的设计讨论** — 所有方案决策、trade-off、参数取舍都在这里。 这是最丰富的信息源，不要只依赖文件而忽略对话。 2. `/media/yhr/2T/Canon/tasks/<task>.md` — Canon task page 中的 § Plan / § Findings / § Decisions / § Artifacts。包含架构决策、约束和 artifact 路径。 3. `.planning/conversations/<id>/` — runtime scratch buffer（spec / task_plan / findings / progress）。历史参考，不作为 durable truth。 4. `.agent-state/conversations/<id>.md` — 历史 runtime recap，补充参考。 5. **代码 diff / 参考实现**（可选）— 仅在已有部分代码或参考文件时使用， 例如 Code Navigation 节需要具体文件路径时。 **如果 Canon task page 或 planning 文档不存在**，直接基于当前对话生成， 并标注缺失的信息源。不要因为文件缺失而拒绝生成。 --- ## 输出 ### 文档结构（14 节，强制） 1. **Executive Summary** — 1 句话 + 核心结论 bullet list（面向所有人） 2. **背景与问题** — 为什么需要这个方案，现有能力为什么不够 3. **方案范围** — 本次包含 / 本次不包含（两节等长或"不包含"更长） 4. **用户可见行为** — 从使用方视角描述入口、操作流程、API/CLI/UI 变化、配置项、默认值和兼容性。只写当前 feature 实际存在的接口；不要 强制虚构 Blueprint、Python、Proto 或其他技术栈。 5. **Architecture / Flow** — A