Retro design
Skill kaixin1seu/retrospective-system/.claude/skills/retro-design
系统设计/架构复盘——从决策质量、架构完整性、流程方法、风险控制等维度深度挖掘From its SKILL.md
npx -y skills add kaixin1seu/retrospective-system --skill retro-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.0 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it
retro-design — 设计/架构复盘透镜
适用范围与边界
本 skill 偏向系统架构和流程设计——系统分层、模块划分、技术选型、审查流程、设计方法论等。
与其它 skill 的区分：
- 写代码时做的具体实现决策（函数签名、错误处理逻辑） →
retro-coding - 实验设计和假设验证 →
retro-experiment - 数据处理架构选择（流式 vs 批处理）→ 本 skill 覆盖，但数据层面的具体问题归
retro-data
如果一个发现涉及多个领域，归入最相关领域深度复盘，其他领域在综合时简述。
不适用场景：简单的代码重构决策（用 retro-coding）、算法选择（用 retro-experiment）、API 参数设计、UI 布局设计。
评估维度
1. 决策质量
- 关键决策是否被记录？（不只记了"选了什么"，还记了"为什么选"和"放弃了什么"？）
- 决策前是否考虑了至少 2 个备选方案？（包括"不做"这个选项）
- 决策是可逆的还是不可逆的？不可逆决策是否给了足够的审查时间？
- 是否存在"先给方案再找问题"的倾向？（用解决方案倒推问题定义）
2. 架构完整性
- 设计是否覆盖了正常路径和失败路径？（不只是 happy path）
- 非功能需求是否被明确考虑？（性能、安全、可维护性、可扩展性）
- 外部依赖的失败模式是否被纳入设计？（依赖挂了怎么办？）
3. 流程与方法
- 设计过程是否遵循了"先理解问题，再设计方案"的顺序？
- 关键假设是否被验证过？（还是只靠推理？）
- 是否有外部视角的审查？（自己审查自己容易有盲区）
- 设计迭代的节奏是否合理？（审查→修改→再审查，有没有过度或不足？）
4. 风险与迁移
- 设计是否考虑了从当前状态到目标状态的迁移路径？（不只是最终状态，还有中间步骤）
- 有没有"单点不可逆"的决策？（如果这个决策错了，能不能回头？）
- 技术债务是否被显式标记和规划偿还时间？
- 设计是否过度工程化？（为了可能的需求增加了不必要的复杂度）
5. 文档与传播
- 设计文档是否足够清晰，让后来者能理解"为什么这样设计"？
- 关键 tradeoff 是否被显式记录？（放弃了什么、为什么接受这个代价）
- 设计是否考虑了团队能力约束？（团队能维护这个复杂度的系统吗？）
常见反模式
| 反模式 | 检测信号 |
|---|---|
| 方案先行 | 对话中先出现技术方案，后补问题定义。问"要解决什么问题"时回答模糊 |
| 审查迷失 | 设计迭代中新增架构层/子系统/规则系统，但原始问题定义和约束无变化——新加的复杂度不是服务于核心目标 |
| 隐式 tradeoff | 设计只说了选了什么，没说什么被放弃了。所有方案都有代价——说不出来代价说明没想清楚 |
| 过度工程化 | 为"未来可能"的需求设计了复杂抽象，但当前场景只需要简单方案 |
| 过度设计 | 为简单问题设计了不必要的复杂架构。问"这能更简单吗？"回答不出 |
| Happy-path 设计 | 只画了正常流程，没有考虑依赖故障、输入异常、资源耗尽等失败场景 |
| 缺乏迁移路径 | 描述了完美的最终状态，但没有说明从当前状态怎么一步步走过去 |
| 决策理由丢失 | 设计做完了但为什么这样做没有被记录。后来者只能猜测当初的考量，重复讨论已解决的问题 |
| 审查权威模糊 | 审查发现的问题没有区分"必须改"和"建议改"，每个意见都像否决票 |
| 单点决策 | 关键决策由一个人/一次推理确定，没有交叉验证或外部视角 |
已固化模式
| 模式 | 适用信号 | 验证 | 来源 |
|---|---|---|---|
| 研究→第一性原理→审查→对齐 | 系统设计类任务，不确定最佳方案时。信号：任务涉及多个可行方案、有行内最佳实践可参考、用户强调质量 | 1 | 🤖 2026-07-06 |
| 系统性修复 | 发现组件缺陷后，先检查同类组件是否有一致问题再批量修复。信号：存在结构同构的多个组件 | 1 | 🤖 2026-07-06 |
关键追问
挑刺式（找改进空间）
- 这个设计要解决的核心问题是什么？问题定义有没有被反复确认？
- 放弃了什么？（每个设计都有代价，如果说不出来代价，说明没想清楚）
- 如果最关键的假设是错的，设计还能成立吗？
- 从当前状态到目标状态，第一步是什么？中间有没有不可逆的步骤？
- 这个设计产生的复杂度，团队有能力长期维护吗？
- 审查过程中，有没有"为了修复审查发现而增加复杂度"的情况？（审查迷失）
- 设计的成功标准是什么？怎么知道它起作用了？
- 设计过程中用了什么工具/方法来辅助决策？（ADR、决策矩阵、原型验证、tradeoff 分析等）有没有该用但没用的？
正向式（找值得复用的）
- 这次设计中最值得复用的做法或模式是什么？为什么它有效？ （信号：某个设计模式在后续迭代中被反复引用无修改、某个决策标准被其它设计任务复用）
- 有哪些"这次做对了"的决策值得被记住？（下次类似场景可以直接复用） （信号：某个决策带来了意料之外的正向副作用、后续设计自然延续了这个决策没有回头）
- 设计过程中有没有特别顺畅的环节？什么因素促成的？ （信号：某个审查流程特别高效、某次讨论产出远超预期、某个方法论被团队自然接受）
反证条件指引
对于核心设计决策，追问：什么具体信号会提示这个决策需要重新考虑？ （引导写出可操作的反证条件，而非空洞的"如果前提假设错了"——什么具体信号说明前提假设错了？）
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.