メニュー
When a new idea arrives mid-development, classify it, assess destructiveness, audit consumers, and choose the lowest-impact integration path instead of rewriting.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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 在开发中途出现时，引导 agent 选择最低破坏性的接入路径，而非推倒重建。
以下任意一条出现时，本 skill 自动激活：
不适用（误触发排除）：
incremental-implementation：已知需求，如何实现得更稳。
三思：新 idea 出现，往哪接、破坏多大、要不要现在接。
合体使用场景：新 idea 经三思分类为 B 类且用户确认"现在做"→ 交接给 incremental-implementation 执行分步实现。
本 Skill 是决策协议，不是执行引擎——所有操作需用户确认后才执行。
这个 Skill 会做什么：
这个 Skill 绝不会做：
最大破坏半径：减慢开发节奏（这是设计意图，不是 bug）。
新 idea 出现，立刻做三秒分类，不要开始写代码：
| 类型 | 判断标准 | 默认处置 |
|---|---|---|
| A — 堵漏 | 影响当前主路径，不修会出错 | 现在处理，走铁律二 |
| B — 优化 | 体验更好，但当前能用 | 问用户："现在做还是记 inbox？" |
| C — 扩展 | 新场景、新功能 | 默认记 inbox，24 小时冷却后再评估 |
C 类冷却原因：新功能冲动往往在 24 小时后自然消退，或变成更清晰的需求。不让即时灵感打断正在进行的任务。
| 触发条件 | 一线修复 | 仍无法判定 |
|---|---|---|
| A 还是 B 分不清 | 按 A 处理（堵漏优先，宁严勿松） | — |
| B 还是 C 分不清 | 问用户："这个功能不做的代价是什么？" | 用户说"不急"→ C；用户说"影响体验"→ B |
| 跨铁律边界（如 C 类但涉及安全） | 升级为 A，立即处理 | — |
决定处理后，先评估破坏性，再选路径。
双向门（可以反悔）：
→ 直接进入铁律三
单向门（改了很难反悔）：
→ 🔴 CHECKPOINT · 🛑 STOP：停下来，先输出影响矩阵，等用户确认：
模板：
references/impact-matrix-template.md
影响评估：
- 直接改动：[文件/接口名]
- 下游影响：[哪些消费者会受影响]
- 回滚成本：[高/中/低，原因]
- 建议：[现在做 / 开新分支 / 记 inbox 等条件成熟]
新建任何 API、模块、组件、工具函数之前，先问：
"这个东西的消费者是谁？现在有几个实际调用点？"
| 消费者数量 | 处置 |
|---|---|
| 0 个 | 不建。记 inbox C 类，等真实需求出现 |
| 1 个 | 最简实现，写在调用处，不抽象 |
| 2 个 | 可以提取，但不做通用化设计 |
| ≥ 3 个 | 才考虑抽象层、接口、配置化 |
这条规则阻断"为将来扩展而设计"的过度抽象冲动。
| 触发条件 | 处置 |
|---|---|
| 外部调用者（第三方 API 消费者） | 按 ≥ 3 保守评估，改动走单向门流程 |
| grep 搜不到但怀疑有隐式调用（反射、字符串拼接 import） | 标记为「消费者待确认」，先不改，等运行时报错再定位 |
| 跨仓库/跨项目调用 | 默认当消费者存在，不删不改旧接口签名，只追加 |
通过前三条铁律后，选择具体接入方式（按破坏性从低到高）：
适用：新功能是对现有功能的增强，不想改现有代码。
做法：在现有函数/组件外加一层，旧路径不动。
触发信号："在 X 基础上加 Y"、"X 的增强版"
适用：新功能可以作为现有模块的新分支，共享大部分逻辑。
做法：加新参数、新 case、新路由，不改已有路径。
触发信号："支持新的类型/场景"、"加一种模式"
适用：新旧路径差异较大，需要并存一段时间再迁移。
做法：新路径单独实现，旧路径保留，逐步迁移消费者。
触发信号："要改架构，但不能停服"、"要验证新方案"
适用：确实需要重写，旧实现已是负债。
前提：必须先完成铁律二的单向门评估，且用户明确确认。
做法：先写新实现并覆盖测试，再删旧实现，逐步迁移。
禁止：新旧混用超过一个 commit。
写代码时，发现同一段逻辑在不同地方出现 ≥ 3 次：
注意：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：
[bypass-cooling]，保留决策痕迹核心原则：agent 负责亮红灯，用户负责踩油门。不替用户做决定，但确保用户做决定时信息充分。
分类是人机协作中最容易出错的环节。以下自纠正机制确保错误不会累积：
| 错误类型 | 信号 | 自纠正动作 |
|---|---|---|
| A 类误判（把 B/C 当 A） | 评估破坏性后发现实际是单向门但用户说不急 | 降级为 B 或 C，重新走对应流程 |
| C 类漏判（把 A 当 C 记了 inbox） | 记入 inbox 后用户在 5 分钟内再次提起 | 升级为 A，立即评估（冷却期内二次提起 = 真实紧迫） |
| B 类模糊执行（B 类直接做了没问用户） | Agent 已开始改动但没有先输出"现在做还是记 inbox？" | 立刻停下，补问用户，已完成改动作为"事实"接受 |
| 用户纠正分类 | 用户说"这不是 C，这得现在做" | 接受用户判定，升级为对应类别，不争论 |
Agent 不预设自己分类一定正确。用户的一次纠正优先于所有铁律。
全部铁律通过后，在动手写第一行代码前，输出一句确认：
✅ 三思审计完成
分类: [A/B/C] | 破坏性: [单向门/双向门] | 消费者: [N 个]
接入: [Wrap/Extend/Branch/Replace] | 冷却: [是/否/已跳过]
开始执行。
如果没有输出这句确认 → 说明有铁律未走完。这是防止跳跃执行的最后一道门。
新想法到达 → 三思（分类+评估）→ 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 中"新想法处理"的空白 |
三者在时间线上形成闭环：澄清 → 接入决策 → 执行。
三思而后行——新 idea 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。