C: step-back-planning skill 迁入 GNM 仓库（受版本控制）

skills/step-back-planning.md

@@ -0,0 +1,125 @@
+---
+name: step-back-planning
+description: "面对复杂/不确定的任务时，先退一步（step back）分析 scope、assumptions、风险，拆成独立小步骤再逐批执行。每步之间设刹车点——上一步验证通过才继续。"
+version: 1.1.0
+author: tckm.er
+metadata:
+  hermes:
+    tags: [planning, step-back, braking, decomposition]
+    related_skills: [plan, subagent-driven-development, assumption-checking]
+---
+
+# Step-Back Planning
+
+> 先退一步，看清全局，再动手。每步之间设刹车点，上一步验证通过才继续。
+
+---
+
+## 触发条件
+
+以下任一信号触发时，**先退一步再动手**：
+
+- ❓ 需求模糊/不完整，不知道从哪开始
+- ❓ 不确定根因，在猜"应该是 X 问题"
+- ❓ 涉及多个子系统或步骤（>3 步）
+- ❓ 同一问题修了 2 次没修好
+- ❓ 用户说「你先看看」「先分析一下」
+
+## 流程
+
+### Step 1: Step Back —— 退一步分析
+
+**不出手，先回答五个问题：**
+
+1. **目标是什么？**   → 最终要达成什么状态
+2. **当前状态？**     → 现在在哪
+3. **已知 assumptions？** → 哪些是确定的，哪些是猜的
+4. **最大风险点？**   → 最可能在哪翻车
+5. **怎么验证？**     → 做完怎么看对不对
+
+**输出：** 一段人话分析（不写文件，直接说）
+
+### Step 2: 拆步骤
+
+把任务拆成 3~5 个独立步骤，每步只做一件事。
+
+**要求：**
+- 每步有明确的完成信号
+- 每步之间有刹车点——上一步的结果决定下一步方向
+- 超过 5 步说明拆得太细，重新合并
+
+### Step 3: 逐批执行
+
+按步骤依次执行，每步之间必须停顿：
+
+1. 执行当前步
+2. 验证结果是否符合预期
+3. **符合** → 继续下一步
+4. **不符合** → 退回到 Step 1 重新分析
+5. 不确定时 → `delegate_task` 让干净 subagent 查，不自己硬想
+
+### Step 4: 收尾
+
+- 对照 Step 1 的目标确认全部完成
+- 提炼新认知 → `memory add`
+- 如果过程中修正了假设，记下为什么最初想错了
+
+---
+
+## 典型示例
+
+### 示例 1：修 bug
+
+```
+用户：帮我看看这个 bug
+
+❌ 直接干：
+  猜根因 → 改 → 没修好 → 再猜 → 再改 → ... 5 轮后放弃
+
+✅ Step-Back：
+  Step 1: 什么 bug？复现步骤？最近改了啥？→ 未知
+  Step 2: 查 git log → 找到最近改动 → 缩小范围
+  Step 3: 读那几行代码 → 确认根因 → 改 1 行
+  Step 4: 测一下 → 好了 → memory add 根因
+```
+
+### 示例 2：搭新服务
+
+```
+用户：帮我搭个 Tailscale 中继
+
+❌ 直接干：
+  搜教程 → 照着配 → 不通 → 搜另一个教程 → 再配 → ...
+
+✅ Step-Back：
+  Step 1: 需求是什么？中继还是直接连？现有网络结构？
+  Step 2: 确认方案 → 选 DERP 还是直接节点
+  Step 3: 配置 → 验证连通
+  Step 4: 确认通了 → 记录配置
+```
+
+---
+
+## 与 plan skill 的区别
+
+| 对比 | plan | step-back-planning |
+|------|------|-------------------|
+| 触发时机 | 需求清晰时 | 需求模糊/不确定时 |
+| 输出 | 写 .md 文件到 .hermes/plans/ | 不写文件，直接分析+执行 |
+| 核心价值 | braking（步骤间刹车） | step back（退一步看清全局） |
+| 适用场景 | 执行复杂度高但目标明确 | 目标/路径不确定 |
+| 配合方式 | 先 step-back 看清 → 再 plan 写步骤 | — |
+
+两者是前后关系：**需求模糊时先用 step-back-planning，看清了再用 plan 写执行计划。**
+
+---
+
+## 坑
+
+- ❌ Step Back 阶段开始动手 → 失去了退一步的意义
+- ❌ 拆了步骤但连续执行不刹车 → 那拆了等于没拆
+- ❌ 发现假设错了还硬走 → 退回 Step 1，不是继续
+- ✅ 不确定就 delegate，不自己猜
+- ✅ 第一次猜的假设大概率是错的——这是规律，不是意外
+
+—— tckm.er