Git Recovery 是一个面向 Git 用户的恢复类技能，主要用途是处理日常开发中容易出现的版本控制失误，例如撤销提交、找回被删除的分支、修复被错误修改的历史记录等。它通过交互式的方式呈现多个恢复场景，并在每个场景中给出对应的命令与验证方式。
主要能力
该技能在调用时会先展示当前 Git 状态，包括 git status 与 git log --oneline -5，然后列出八种恢复选项：
- 保留更改地撤销最近一次提交；
- 丢弃更改地撤销最近一次提交（破坏性操作）；
- 恢复已删除的分支；
- 将文件重置到上次提交（破坏性操作）；
- 撤销一次变基；
- 撤销一次合并；
- 查找丢失的提交（通过 reflog 深入搜索）；
- 取消暂存文件。
每种场景都配有相应的命令示例，例如使用 git reset --soft HEAD~1 保留更改地撤销提交，使用 git reflog 查找已删除分支的最后一个提交，使用 git reset --hard ORIG_HEAD 回退到变基前状态，以及使用 git revert 处理已推送的合并等。
使用方式
该技能通过 /git-recovery 命令调用。调用后先显示仓库当前状态，再向用户呈现恢复选项菜单，由用户选择对应场景编号。对于破坏性操作，技能要求先展示将要丢失的内容，提供备份引用（例如使用 git rev-parse HEAD 保存 BACKUP_REF），并要求用户显式确认后再执行。恢复操作完成后，技能会运行验证命令、展示新的状态并确认恢复成功。
适用场景
该技能适用于本地或团队协作中需要修复 Git 历史的场景，包括误提交、误删分支、误操作变基或合并、误暂存文件以及需要找回丢失提交等情况。它也列出了常见问题与正确应对方式，例如已推送的提交应使用 git revert 而不是 git reset --hard，恢复已删除分支应借助 git reflog，以及在共享分支上撤销变基应使用 revert 而不是 reset。
限制与安全规则
该技能明确标注了部分操作为破坏性操作，例如丢弃更改地撤销提交、将文件重置到上次提交。此类操作在执行前必须展示丢失内容并提供备份命令，同时要求用户确认。技能规定不得在共享分支上未经明确确认使用 --force，每次恢复后都必须验证，并且在建议使用 reset 还是 revert 之前需检查更改是否已推送。reflog 默认保留约 90 天记录，ORIG_HEAD 可能被其他操作覆盖，若其已过时应改用 reflog。该技能的收费方式、价格、支持平台与效果保证等事实暂未提供。