菜单
诊断本地分支分叉并按清单引导完成 rebase，历史保持 FF 直线
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
按照 git 规则自动分析变更并提交代码
提交前的自动 review 迭代环：委派子 agent 跑 CC 自带 /code-review（默认 sonnet × medium，并发/难复现等硬 diff 升 opus × high），发现高置信正确性问题就修、跑测试+happy-path 验证、复审，迭代到「运行验证通过 + 无高置信 correctness 问题」才放行。收敛靠运行验证+置信过滤，非 reviewer 挑不出为止。三条硬规则：永远显式传档位、永远委派子 agent、只用两个合法的模型×档位组合。由 /commit 在生成 commit 前自动调用，也可手动跑
为空项目搭建文档骨架（README.md / CLAUDE.md / DEVTREE.md），仅在项目首次开发前调用一次
依据 docs/DEVTREE.md 中作者维护的 Epic 结构，重新生成可视化图表和节点索引
完成当前开发项：撰写 SUMMARY.md，反思跨项目可沉淀流程并可向 claude-code-global 提 issue，关联并关闭 issue（GitHub / GitLab，如有），提交代码
把 claude-code-global 仓库管理的"跨项目共享开发配置模板"的最新变化同步进当前项目；含 adopt 模式（无 marker 老项目首次接入）
| name | rebase |
| description | 诊断本地分支分叉并按清单引导完成 rebase，历史保持 FF 直线 |
| disable-model-invocation | false |
用户调用此 skill 表示当前本地有分支分叉，需要通过 rebase 把分叉整理成直线历史。
调用时可附带参数（args），支持以下几种形式：
| 参数 | 含义 | 示例 |
|---|---|---|
| （无） | 把当前分支 rebase 到 master 上（默认 base） | /rebase |
<base> | 把当前分支 rebase 到指定的 <base> 上 | /rebase develop |
abort | 当前正处于 rebase 中间状态，放弃本次 rebase | /rebase abort |
continue | 当前正处于 rebase 中间状态，解决完冲突后继续 | /rebase continue |
要求：
master），立即停下告知人类。abort / continue 只在 .git/rebase-* 存在时才有效；若当前没有进行中的 rebase，应告知人类并退出。只处理本地：不执行 git fetch / git pull。远程同步由人类在调用前自行完成。
所有合并必须 FF：严禁生成 merge commit。rebase 完成后用 git merge --ff-only；若 FF 失败，继续 rebase 直到能 FF，绝不 fallback 到普通 merge。
个人分支才 rebase：如果要被 rebase 的分支是 master / main、或是已被他人 review 的公共分支，立即停下问人类。
数据优先于直线历史：一旦出现看不懂的状态，宁可 git rebase --abort + git reset --hard <备份 tag> 回退，也不要强行推进。
不支持交互式 rebase：不使用 -i；如需合并/重排 commit，请人类手动处理。
默认静默直行，风险才停（risk gates）：诊断方向明确且无风险时，诊断 → 备份 → rebase → FF 合并一气呵成、不逐阶段等确认，末尾汇报结果即可。无冲突的 rebase 本该近乎瞬间完成，不该被反复「停下 → 等 OK」拖住。仅在命中下面这份「必停清单」时才停下、说明原因、等人类决策：
master）；master / main 或已被他人 review 的公共分支（呼应原则 #3）；git merge --ff-only 失败；git push --force-with-lease 或推主干）—— 高影响，即便前面全程无冲突也停一次确认，绝不静默 force push；不在清单内（诊断清楚且方向明确、工作区干净、rebase 无冲突、FF 成功）→ 直接继续，不打断人类。注意：静默直行绝不牺牲安全 —— 原则 #4「数据优先于直线历史」不变，阶段 1 的备份 tag 无条件必打，静默直行也不例外。
执行以下命令并展示结果：
git rev-parse --show-toplevelgit worktree list — 识别当前是否在 worktree 内，属于哪一个git branch --show-current — 当前分支git status — 工作区 / 暂存区是否干净git log --graph --oneline --all -20 — 可视化本地分叉基于结果输出一份诊断报告，至少包含：
.git/rebase-merge 或 .git/rebase-apply）feat/installsh 的 3 个 commit rebase 到 master 上"）根据参数与诊断结果分流：
abort / continue：确认确实在 rebase 中间状态后，执行 git rebase --abort 或 git rebase --continue，完成后跳到阶段 3（若 continue 完成）或直接结束（若 abort）。<base> 参数：采用该 base 作为目标。master 作为 base。若当前分支就是 master，立刻停下告知人类，不要试图去找"另一条该 rebase 的分支"。诊断报告明确写出"将把 <current> rebase 到 <base>"。方向明确且未命中必停清单（原则 #6）→ 直接进阶段 1，无需等确认；命中必停项 → 停下说明原因、等人类决策。
确认方向后，执行强制项：
git commit 或 git stash，不得直接进入下一步。git tag backup/<branch-name>-$(date +%Y%m%d-%H%M)。
git reset --hard <备份 tag> 回到此刻。"cd 到对应 worktree 目录）。工作区干净 → 打完备份 tag 直接进阶段 2，无需等确认；工作区不干净 → 停下（命中必停清单），要求人类先 git commit / git stash。
执行 git rebase <base>。
展示 git log --graph --oneline -10 备查，直接进入阶段 3，不停顿。
git status 列出冲突文件。git add <file>。git rebase --continue。git rebase --abort 撤销整个 rebase。备份 tag 作为二重保险。rebase 完成后展示 git log --graph --oneline -10 让人类肉眼验证。冲突属必停项（原则 #6）：解决过程与解决完都停下过目，确认历史正确再进阶段 3。
若本次 rebase 的目的是把分叉合回主干（如 master）：
git checkout <target-branch>git merge --ff-only <rebased-branch>--ff-only 失败，说明目标分支在 rebase 期间又有新 commit。FF 失败属必停项：停下告知人类，处理方式是回到阶段 2，把 rebased-branch 继续 rebase 到最新的目标分支上，再来一次 FF。禁止 fallback 到普通 merge。FF 成功则直接继续，不停顿。
推送属必停项（原则 #6）：无论 --force-with-lease 还是推主干都高影响，推送前必停一次、告知推什么、等人类点头，绝不静默 force push。
git push --force-with-lease origin <branch>，禁用 git push --force。master）：正常 git push。git log --graph --oneline -10、是否已 / 待推送。git tag -d backup/...。docs/<N>-... 轮次目录的仓库）rebase / 历史整理后目标分支可能已占用本地 round 编号，导致三处脱节。触发：目标分支已占用当前 round 编号，或 docs round 与 commit round 不一致时，逐条核对、命中给顺延计划并要求确认、绝不静默：
docs/<N>-... 目录编号顺延到下一个空位。docs/DEVTREE.md（Epic 结构 / 可视化 / 节点索引）随之同步顺延。[round N] 前缀与目录编号一致。git log --oneline / git status 确认三者一致。纯代码仓（无 docs/<N>-...）→ 跳过本节。