| name | think-thrice |
| description | When a new idea arrives mid-development, classify it, assess destructiveness, audit consumers, and choose the lowest-impact integration path instead of rewriting. |
| version | 1.2.0 |
| author | dmlin7777777 |
| tags | ["workflow","idea-management","vibe-coding","agent-discipline","no-rewrite"] |
三思 — 新 idea 接入协议
三思而后行。当新 idea 在开发中途出现时，引导 agent 选择最低破坏性的接入路径，而非推倒重建。
适用场景
以下任意一条出现时，本 skill 自动激活：
- 用户在开发进行中说"我突然想到…"、"要不要顺便…"、"能不能改成…"
- 英文等价："I just thought of...", "can we also...", "what if we change...", "let's also add...", "should we refactor..."
- 用户提出的新需求会影响已有的文件、接口、数据结构
- 用户问"这个架构能支持 X 吗？" / "Can this architecture support X?"
- Agent 发现当前实现路径与用户新想法存在冲突
不适用（误触发排除）：
- 项目从零开始的第一个功能
- 纯 bug 修复（不涉及新想法）
- UI 微调（改颜色、调间距、换文案）——这些是双向门，直接执行即可
- 明确的用户指令："直接做，不需要评估" / "just do it"
- 纯信息查询（"这个文件是干什么的？" / "what does this code do?"）
与 incremental-implementation 的区别
incremental-implementation：已知需求，如何实现得更稳。
三思：新 idea 出现，往哪接、破坏多大、要不要现在接。
合体使用场景：新 idea 经三思分类为 B 类且用户确认"现在做"→ 交接给 incremental-implementation 执行分步实现。
安全边界
本 Skill 是决策协议，不是执行引擎——所有操作需用户确认后才执行。
这个 Skill 会做什么：
- 暂停 Agent，输出分类结果和影响评估
- 建议冷却期、建议接入模式
- 在单向门场景强制等待用户确认
这个 Skill 绝不会做：
- 删除文件、修改数据库、执行 shell 命令
- 自动 commit 或 push
- 发送外部网络请求
- 绕过用户权限或 sandbox
- 替代用户做单向门决策
最大破坏半径：减慢开发节奏（这是设计意图，不是 bug）。
铁律一：先分类，不动手
新 idea 出现，立刻做三秒分类，不要开始写代码：
| 类型 | 判断标准 | 默认处置 |
|---|
| A — 堵漏 | 影响当前主路径，不修会出错 | 现在处理，走铁律二 |
| B — 优化 | 体验更好，但当前能用 | 问用户："现在做还是记 inbox？" |
| C — 扩展 | 新场景、新功能 | 默认记 inbox，24 小时冷却后再评估 |
C 类冷却原因：新功能冲动往往在 24 小时后自然消退，或变成更清晰的需求。不让即时灵感打断正在进行的任务。
分类模糊时的处置
| 触发条件 | 一线修复 | 仍无法判定 |
|---|
| A 还是 B 分不清 | 按 A 处理（堵漏优先，宁严勿松） | — |
| B 还是 C 分不清 | 问用户："这个功能不做的代价是什么？" | 用户说"不急"→ C；用户说"影响体验"→ B |
| 跨铁律边界（如 C 类但涉及安全） | 升级为 A，立即处理 | — |
铁律二：评估破坏性（单向门 vs 双向门）
决定处理后，先评估破坏性，再选路径。
双向门（可以反悔）：
- 改 UI 样式、文案、布局
- 加新字段（不删旧字段）
- 加新函数（不改旧函数签名）
- 加新路由（不改旧路由）
→ 直接进入铁律三
单向门（改了很难反悔）：
- 改数据库或存储结构
- 改对外 API 签名
- 删文件或移路径
- 改全局状态的形状
- 升级核心依赖
→ 🔴 CHECKPOINT · 🛑 STOP：停下来，先输出影响矩阵，等用户确认：
模板：references/impact-matrix-template.md
影响评估：
- 直接改动：[文件/接口名]
- 下游影响：[哪些消费者会受影响]
- 回滚成本：[高/中/低，原因]
- 建议：[现在做 / 开新分支 / 记 inbox 等条件成熟]
铁律三：消费者审计（建之前先数使用者）
新建任何 API、模块、组件、工具函数之前，先问：
"这个东西的消费者是谁？现在有几个实际调用点？"
| 消费者数量 | 处置 |
|---|
| 0 个 | 不建。记 inbox C 类，等真实需求出现 |
| 1 个 | 最简实现，写在调用处，不抽象 |
| 2 个 | 可以提取，但不做通用化设计 |
| ≥ 3 个 | 才考虑抽象层、接口、配置化 |
这条规则阻断"为将来扩展而设计"的过度抽象冲动。
消费者数量不确定时
| 触发条件 | 处置 |
|---|
| 外部调用者（第三方 API 消费者） | 按 ≥ 3 保守评估，改动走单向门流程 |
| grep 搜不到但怀疑有隐式调用（反射、字符串拼接 import） | 标记为「消费者待确认」，先不改，等运行时报错再定位 |
| 跨仓库/跨项目调用 | 默认当消费者存在，不删不改旧接口签名，只追加 |
铁律四：选接入模式
通过前三条铁律后，选择具体接入方式（按破坏性从低到高）：
模式 1 — Wrap（包一层）
适用：新功能是对现有功能的增强，不想改现有代码。
做法：在现有函数/组件外加一层，旧路径不动。
触发信号："在 X 基础上加 Y"、"X 的增强版"
模式 2 — Extend（延伸现有结构）
适用：新功能可以作为现有模块的新分支，共享大部分逻辑。
做法：加新参数、新 case、新路由，不改已有路径。
触发信号："支持新的类型/场景"、"加一种模式"
模式 3 — Branch（并行分支）
适用：新旧路径差异较大，需要并存一段时间再迁移。
做法：新路径单独实现，旧路径保留，逐步迁移消费者。
触发信号："要改架构，但不能停服"、"要验证新方案"
模式 4 — Replace（替换）
适用：确实需要重写，旧实现已是负债。
前提：必须先完成铁律二的单向门评估，且用户明确确认。
做法：先写新实现并覆盖测试，再删旧实现，逐步迁移。
禁止：新旧混用超过一个 commit。
铁律五：重复报警
写代码时，发现同一段逻辑在不同地方出现 ≥ 3 次：
- 🔴 CHECKPOINT · 🛑 STOP：停下来，不要静默复制第 3 次
- 输出："我发现 [X 逻辑] 重复了 [N] 处，建议提取。现在统一还是记 inbox？"
- 用户选"记 inbox" → 记 B 类，继续当前任务
- 用户选"现在统一" → 提取作为独立子任务，走完整五段流程
注意：1-2 次重复是正常的，3 次才是信号。不要为 2 次重复提前抽象。
执行检查清单
每次有新 idea 出现时，内心走一遍：
□ 分类了吗？（A/B/C）
□ C 类的话，进 inbox 了吗？
□ 单向门还是双向门？
□ 单向门的话，影响矩阵输出了并等用户确认了吗？
□ 消费者数量清楚吗？（0/1/2/3+）
□ 接入模式选好了吗？（Wrap / Extend / Branch / Replace）
□ 有 ≥ 3 次重复的逻辑吗？
反模式（永远不要做）
❌ 默认重写：看到新 idea 就重构现有代码，不先评估破坏性
❌ 为未来消费者设计：现在没有的消费者不算消费者
❌ C 类即时执行：新功能冲动绕过冷却期直接开发
❌ 混合模式超期：新旧两套方案并存超过一个 commit
❌ 静默蔓延：改着改着把相关代码"顺便"也改了
用户覆盖与降级
当用户明确拒绝分类建议时（如坚持 C 类立即执行），不争论，走降级路径：
🔴 CHECKPOINT · 🛑 STOP：
- 输出风险提示："这是 C 类扩展功能，建议进 inbox 冷却。如果确定现在做，我会按单向门标准评估影响。"
- 用户确认后 → 将 idea 升级为单向门评估，走铁律二完整影响矩阵
- 执行后 → 在 commit message 中标注
[bypass-cooling]，保留决策痕迹
核心原则：agent 负责亮红灯，用户负责踩油门。不替用户做决定，但确保用户做决定时信息充分。
铁律自纠正：当分类出错时
分类是人机协作中最容易出错的环节。以下自纠正机制确保错误不会累积：
| 错误类型 | 信号 | 自纠正动作 |
|---|
| A 类误判（把 B/C 当 A） | 评估破坏性后发现实际是单向门但用户说不急 | 降级为 B 或 C，重新走对应流程 |
| C 类漏判（把 A 当 C 记了 inbox） | 记入 inbox 后用户在 5 分钟内再次提起 | 升级为 A，立即评估（冷却期内二次提起 = 真实紧迫） |
| B 类模糊执行（B 类直接做了没问用户） | Agent 已开始改动但没有先输出"现在做还是记 inbox？" | 立刻停下，补问用户，已完成改动作为"事实"接受 |
| 用户纠正分类 | 用户说"这不是 C，这得现在做" | 接受用户判定，升级为对应类别，不争论 |
Agent 不预设自己分类一定正确。用户的一次纠正优先于所有铁律。
最终确认门（All Clear Gate）
全部铁律通过后，在动手写第一行代码前，输出一句确认：
✅ 三思审计完成
分类: [A/B/C] | 破坏性: [单向门/双向门] | 消费者: [N 个]
接入: [Wrap/Extend/Branch/Replace] | 冷却: [是/否/已跳过]
开始执行。
如果没有输出这句确认 → 说明有铁律未走完。这是防止跳跃执行的最后一道门。
与其他 skill 的协作
核心三技能闭环（三思 → ideas-inbox → vibecoding-workflow）
新想法到达 → 三思（分类+评估）→ B/C 类入 ideas-inbox（归档+冷却）
→ 确认执行 → vibecoding-workflow（执行纪律：如何安全地改）
| Skill | 角色 | 交接点 |
|---|
| ideas-inbox | B/C 类处置依赖 ideas-inbox 作为归档机制 | 三思分类后，B/C 类移交 inbox |
| vibecoding-workflow | 管执行纪律（如何改） | 三思选定接入模式后，交接给 vibecoding-workflow |
| incremental-implementation | 分步执行（已知需求稳着来） | 接入模式选定后，具体实现可衔接；处理"已知需求"的"如何实现" |
| superpowers 体系 | brainstorming（需求前）→ 三思（新想法到达）→ executing-plans（执行+检查点） | 三思填补了 superpowers 中"新想法处理"的空白 |
互补叙事
- brainstorming / grill-me：负责开发前的需求澄清（"你到底要什么？"）
- 三思：负责开发中的新想法接入（"这个新想法怎么放进去？"）
- incremental-implementation：负责确认后的分步执行（"已知需求怎么稳着实现？"）
三者在时间线上形成闭环：澄清 → 接入决策 → 执行。
一句话总结
三思而后行——新 idea 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。
