设计研讨会
在一切记录之前，与负责人一起思考设计。负责人主导；智能体拓宽选项，展示每个选项的隐含含义，并保持对话的诚实性。在最后的提升步骤之前，任何内容都不会进入系统设计，负责人将在该步骤选择纳入的内容。
可在任何时间使用：在系统设计存在之前、里程碑规划期间或里程碑进行中。术语（系统设计、附加检查、可审查表面、settled/working、owner/proposed、里程碑、试验性代码、临时代码、负责人偏好、双重覆盖规则）在 system-design 技能的 terms.md 中定义；请按定义使用。
文件
<DocDir>/SystemDesign/
Overview.md 系统设计（system-design）；仅由提升步骤修改
Sessions/<date>-<Short_Topic>.md 本技能的临时笔记，提升步骤后删除
<date> 格式为 YYYY-MM-DD；Short_Topic 为 2-3 个单词，使用蛇形命名法，例如 2026-11-01-Review_Import.md。笔记格式自由：无ID、无状态、无协议标记、无问题限制。它们记录负责人的草图、考虑过的方案及其图表、追踪的后果、发现的矛盾及其解决方式、试验结果以及负责人的倾向。每当对话有进展时更新笔记，以便中断的会议可以从文件继续。
工作流程
1. 阅读，然后让负责人主导
读取系统设计以及任何与该主题相关的子系统文档、路线图的当前里程碑、<DocDir>/Taxonomy.md、项目规则文件（CLAUDE.md 或同等文件）以及负责人偏好文件 ${DANNY_SKILLS_STATE_DIR:-$HOME/.local/state/danny-agent-skills}/owner-preferences.md（如果存在）。如果 Sessions/ 中已存在该主题的笔记文件，则从该文件继续。否则创建它并指明路径。
询问负责人在构思什么，并用几行文字以及（当构思包含两个或更多部分时）一个图表来反映他们的草图。只询问那些会改变设计形态的问题；永远不要问那些你可以作为默认值陈述的问题。
2. 提供备选方案
提供 2-3 个方案，负责人的原始草图算作一个。每个方案包括：遵循 plan-milestone 技能 diagrams.md 的 Mermaid 图表（节点标签使用系统设计中的组件名称，新部件标记为 sketched，方案更改的内容标记为 touched）、一个该方案在项目用例上行为的简单示例，以及一行优缺点。然后推荐其中一个，或者说“不做推荐”并说明原因。根据功能为新事物命名（terms.md，“名称和标签”）。按照 diagrams.md 的要求对每个图表进行渲染检查。
3. 追踪后果
对于负责人倾向的方案，说明它会改变什么：子系统、接缝、数据模型、可审查表面（仅在那里逐字段说明）、名称以及威胁与隐私部分。对每个后续里程碑的基线运行附加检查：如果某个后续里程碑无法在不重构的情况下添加，则说明当前必须决定哪个接缝。如果尚无系统设计或后续里程碑基线，则跳过附加检查，直到里程碑存在；永远不要为了检查而发明里程碑。指出每个该方案会改变的 settled 项；改变一个则意味着需要重新规划。将接缝内部的实现细节保留为未定；细枝末节放在“运行后决定”列表中。
4. 发现矛盾
当负责人的陈述与本会议中的早期陈述、某个 settled 项、负责人偏好、项目规则或 Taxonomy.md 中的名称相矛盾时，直白地指出来。引用双方表述，并询问哪方成立。将答案记录在笔记中。
5. 提供临时性试验
只有当只有运行某些东西才能解答某个问题时（是否足够快、API是否返回这个、平台能否做那个），才提供最小的能回答该问题的运行：它做什么、什么结果指向哪个方向、以及大约需要多长时间。仅在负责人接受后才构建它，在产品代码之外（一个临时目录或临时分支），运行它，并将结果记录在笔记中。代码被丢弃；如果负责人想保留它，则在步骤 6 中作为临时代码提升。
6. 提升
当负责人表示完成，或对话已经收敛时，列出笔记中所有可以进入系统设计的条目，使用 presenting-for-review.md 中的格式，每个条目附带一个推荐结果：
- 提升为
settled或 提升为working并附上回顾说明（“如果……则重新审视”）。 - 预留 到后续里程碑，指明该里程碑。
- 丢弃。
在同一条消息中，根据双重覆盖规则提出负责人偏好条目：仅当负责人在本次会议中两次覆盖了你提供的同一类型的方案，或直接表达了偏好时。每个偏好一行（偏好内容、一个示例、日期），并说明它是放入跨项目负责人偏好文件还是项目规则文件。单一的裁决是决策，而非偏好；对本技能行为的反馈应进入回顾会议，而非此处。对于负责人措辞中的每个条目（名称、结果文本、接缝），在同一消息中做一次 system-design 技能步骤4的收紧提议：列出每个歧义，并在原版旁展示一个收紧版本；负责人接受、编辑或保留原版。以一个提问结束。
按照负责人的裁决将提升的条目应用于系统设计（overview-template.md），作为一次普通编辑：
| 提升的条目 | 放置位置 |
|---|---|
| 一个组件 | 组件行（sketched、构建目标、协议）和一个仅包含深度类（从不 touched）的图表节点 |
| 一个接缝 | 接缝与接口行及其协议 |
| 一个表、API 或公共符号 | 可审查表面，逐字段，带其标记 |
| 一个实体或关系 | 数据模型 |
| 一个名称 | 名称，然后 DocDir>/Taxonomy.md，作为一组与其余内容一起审查 |
| 方案之间的选择 | 决策行：下一个可用 D ID、类型 choice、协议 settled 或 working (revisit if …)、原因说明被拒绝的方案 |
| 会议发现的一个未知问题 | 风险行及其最便宜的实验 |
| 对后续里程碑的更改 | 其范围和里程碑基线以及附加检查单元格 |
| 负责人保留的试验代码 | 临时代码行，以及代码中的 PROVISIONAL 标记 |
| 一个预留的结构性条目 | 开放问题行，指明它等待的里程碑，例如“Q4（预留至M3，记录更改）：……” |
| 一个预留的细枝末节 | 将解决它的里程碑下的“运行后决定”列表 |
协议标记遵循模板：负责人编写或编辑的条目读取 owner（例如 settled · owner）；负责人未经修改接受的条目不携带 proposed 标记。新ID延续文档序列，从不重用。对已达成协议的条目的更改通过决策日志进行，而非静默编辑。当提升的条目更改了 settled 条目（例如一个接缝）或负责人的请求为当前里程碑增加了结构时，明确指出需要重新规划，并在以下提交之后编写一份交接备注，以便 /rung 在以后的会议中路由该重新规划：<DocDir>/Handoff/replan-<date>.md，包含 Route: replan、Model: opus、Waiting on: re-plan after the design session on <topic>、Date:，以及一个说明更改项和提交的正文（handoff.md）。丢弃的条目不予记录；git 历史中的笔记文件保留它们。将接受的偏好条目写入负责人选择的文件。
如果系统设计尚不存在，则将提升的条目写入一个新的 Overview.md，包含模板的标题（Status: draft），仅填充它们所属的章节；system-design 从中继续。
通过显式路径暂存并提交系统设计、Taxonomy.md、项目规则文件（如果更改了）以及笔记文件，提交信息为 Design session: <topic>，以便历史保留笔记。然后 git rm 笔记文件并提交，信息为 Remove design session notes: <topic>。记录一个 step 事件，包含 skill design-session 1.0.1 和 kind design-session（其他字段在 tasklist-run 的度量日志中），以及你为提升提议的条目计数：proposed、accepted（未修改）、edited 和 rejected。
以一个简单的句子结束，说明发生了什么变化以及下一步是什么，然后 Next: /rung，当该步骤需要 Opus 时添加 (Opus: /model opus)：系统设计仍需达成一致、里程碑规划、或步骤6指出的重新规划。
如果负责人在提升前停止，则将笔记文件留在原处，不提交，并说明其路径；下次关于该主题的设计会议将从此文件继续。
如果链接的文件或技能缺失
当链接的文件缺失时，不要停止：在此处使用最小内容，并在一两行中说明缺失了什么以及如何安装（claude plugin install project-planning@danny-sung-agent-skills，或 npx skills add dannys42/agent-skills --skill <skill-name> 到相同的技能目录，以便相对链接可以解析）。
- 没有
terms.md：settled预期保持不变；working足够好可以开始，并说明什么会使我们重新审视它；owner条目是负责人的原话，proposed是智能体的。附加检查询问每个后续里程碑是否可以在不重构的情况下添加。 - 没有
diagrams.md：Mermaidflowchart，引用每个标签，标签是组件名称，每个深度一个类（sketched虚线，designed细线，built粗体）。 - 没有
presenting-for-review.md：重要条目优先（最多5个，难以逆转或影响范围广），每个带选项、一个简单示例、优缺点以及一个推荐；以一个提问结束。 - 没有
overview-template.md：将提升的条目放入系统设计现有章节，匹配其表格和标记。
判断准则
- 负责人主导。 提供方案和后果；不要盘问或引导至你最喜欢的方案。不会改变形态的问题不值得问。
- 自由探索，严格提升。 会议中任何内容都可以讨论，但只有结构性能进入系统设计：子系统、接缝、数据模型、可审查表面、名称、决策和风险。内部实现细节留在外面。
- 试验胜过争论。 当负责人和智能体对一个可以通过短时间运行来验证的事实存在分歧时，提供运行而非争论。