system-design

name	system-design
description	系统设计。brainstorming 完成、需求锁定后触发。扁平 fork:调度者先 fork designer 写设计,再 fork 独立自检挑战者验证,调度者控制迭代。
allowed-tools	Read, Glob, Grep, Bash, Write, Edit, Agent

系统设计

架构:扁平 fork(2026-04-16 改造)。主对话(调度者)依次 fork designer 和自检挑战者,两者互相独立。详见 docs/decisions/2026-04-16-fork-flat-refactor.md。

输入(注入到 designer 的 prompt 中)

!f=$(ls -t docs/superpowers/specs/*-design.md 2>/dev/null | head -1); [ -n "$f" ] && echo "已有设计文档: $f" && cat "$f" || echo "无设计文档(本次新建)"

!cat docs/RUBRIC.md 2>/dev/null || echo "无评分标准"

!cat docs/ARCHITECTURE.md 2>/dev/null || echo "无架构规范"

!cat docs/references/DESIGN_TEMPLATE.md 2>/dev/null || echo "无设计模板"

---

执行

第一步:fork designer 写设计草稿

用 Agent 工具,subagent_type: general-purpose,fork 一个 designer,prompt 按 .claude/agents/designer.md 内容构造,并嵌入上面注入的 RUBRIC / ARCHITECTURE / DESIGN_TEMPLATE / 已有设计文档内容(designer 看不到本对话上下文)。

designer 完成后返回草稿(或写入 docs/superpowers/specs/[功能名]-design.md 后返回路径)。

第二步:fork 自检挑战者

用 Agent 工具,subagent_type: general-purpose,fork 一个独立的自检挑战者,prompt 如下:

你是设计文档的自洽性验证员。你没有参与设计过程,只看到最终文档。

逐条检查以下自洽性要求:
- 需求 ↔ 模块:每个需求场景都有模块实现路径?
- 模块 ↔ 接口:每个模块的职责都通过接口体现?没有孤岛模块?
- 接口 ↔ 数据:接口中的数据类型都在数据模型中定义了?
- 数据 ↔ 边界:每个数据字段的边界值都有处理?
- 依赖 ↔ 架构:模块依赖方向符合 ARCHITECTURE.md?
- 决策 ↔ 需求:设计决策没有偏离需求约束?
- 决策 ↔ 架构:设计决策中的架构选择与 ARCHITECTURE.md 一致?
- 影响 ↔ 模块:改动文件与标记为"改动"的模块对应?
- RUBRIC ↔ 设计:每个 RUBRIC 惩罚项都有应对方式?
- 契约 ↔ 接口:第 3.3 节的共享类型覆盖了所有 API 端点?字段命名一致?

同时检查每节内部的自检清单(文档中每节末尾的 checklist)是否都满足。

对每个不通过的项:指出哪里不自洽、具体内容、建议修复方向。
输出:通过的项打 ✅,不通过的项打 ❌ 并说明原因。

[附:完整设计文档 / RUBRIC.md / ARCHITECTURE.md]

第三步:调度者控制迭代

• 自检全 ✅ → 设计阶段完成
• 有 ❌ 项 → 回到第一步,fork 一轮新 designer,把"草稿 + 自检报告"一起作为输入,让它修订
• 连续 2 次自检不通过 → 停下来让用户介入,决定方向

第四步:待决策项

designer 或自检过程中产生的"待用户决定"项,写入 docs/decisions/(标记 🟡),由调度者转达给用户。

与旧架构的差异

阶段	旧(两级 fork,失效)	新(扁平 fork)
designer 写草稿	skill → fork designer	主对话 → fork designer
designer 自检	designer → fork 自检子 agent(失效)	主对话 → fork 自检挑战者
迭代控制	designer 自己控制	主对话控制
独立性	designer 和自检独立(理想)	designer 和自检独立(实际)