Retro design
Skill kaixin1seu/retrospective-system/.claude/skills/retro-design
通用AI Agent复盘系统——榨干对话价值，沉淀为知识资产。Claude Code /复盘 命令 + 6领域skill + 平衡锚定
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.
What its author says it does
Copied from the file, not written here
系统设计/架构复盘——从决策质量、架构完整性、流程方法、风险控制等维度深度挖掘
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.