القائمة
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 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。