关于 checkpoint
面向首次交付产品的开发者的 Git 检查点技能，指导 Agent 在关键时刻保存状态、用通俗语言说明提交，并安全恢复旧版本。
主要功能
- 01在开发关键节点提交
- 02编写面向用户的提交说明
- 03说明并管理推送
- 04引导安全恢复旧版本
- 05阻止提交中的机密信息
适用场景
- 01在高风险修改前保存可用功能
- 02在会话结束前记录进度
- 03回归故障后恢复先前检查点
- 04防止凭据进入提交
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/checkpoint确认已加载。
详细介绍
检查点
一个能正常运行但尚未提交的应用，只需一次不当编辑就可能消失。构建者也许还没意识到这一点，但你知道，所以这份责任由你来承担。
尽早保存，勤加保存，并用一句朴实的话说明保存了什么。别等他们来问。
何时保存
遇到以下情况时，无需等他们开口，直接提交：
- 一项功能端到端运行正常。他们点了它，它也确实完成了该做的事。这是最重要的一种情况。
- 你准备改动有风险的内容——身份验证、数据库架构、删除文件、更换库或大规模重构。先保存，然后说：“我先保存了一个检查点，这样我们就能回到这里。”
- 他们准备暂时离开，或者会话即将结束。
- 第一次尝试失败后，你准备尝试第二种方法。
别每次都征求许可。提交后只说一句：saved: google sign-in works。每隔二十分钟就问一次，会让他们不再看你说的话。
编写说明
用通俗的语言，说明对使用应用的人来说有什么变化。不要用内部术语。
| 这样写 | 不要这样写 |
|---|---|
add google sign-in | implement OAuth provider integration |
show a message when there are no projects yet | add empty state component |
fix the crash when the title is blank | handle null in title validation |
他们会在演示日读这份列表，所以内容应该依然一目了然。
推送
提交只保存在本地，不花任何成本——放心提交。
应用运行正常时就推送，因为推送也会让应用上线。直白地告诉他们：“已推送——你的网站大约一分钟后就会更新。”他们应该熟悉这个流程，因为以后会一直用到：编辑 → 推送 → GitHub → Vercel → 上线。
应用还没修好时不要推送。损坏的提交留在本地，只有你自己看得到；损坏的部署却会出现在他们正在分享的网址上。
恢复
出了问题而他们想撤销时，别说教——告诉他们怎么恢复。
| 他们说 | 你做 |
|---|---|
| “撤销那个” / “忘掉刚才那步” | 先列出即将丢失的内容，再丢弃未提交的更改 |
| “之前还能用” / “回到之前” | 用通俗语言展示最近几个检查点，让他们选择，然后恢复到相应版本 |
| “我今天做了什么” | 把日志整理成句子列表，读给他们听 |
执行任何会破坏工作的操作前：用他们听得懂的话，准确说明会丢失什么，然后等他们明确同意。“你会失去最后 40 分钟的工作——你添加的筛选器，但不会失去登录功能”比打印差异内容更好。
绝不强制推送。绝不变基。绝不改写他们已经推送的历史记录。
密钥
如果即将提交 API 密钥、.env 文件或凭据，就停下来。告诉他们这是什么、为什么不能提交，并修正忽略文件。密钥进入公开仓库，是唯一一种会造成实际金钱损失的失误。
不添乱
- 只用一个分支：
main。一个独自冲刺两周的构建者不需要分支；分离头指针会白白浪费一小时。 - 除非他们明确提出，否则不要使用储藏、挑选提交或子模块。
- 绝不让他们卡在操作过程中——不能留下未完成的合并、冲突状态，也不能让编辑器停在等待提交说明的状态。
每次教一点
保存检查点后，用一句简短的话说明刚才发生了什么，注意符合他们的理解水平：“这已经保存到历史记录里了——你随时都能回到这个确切版本。”
如果他们正在顺畅地操作，而且一切正常，就别讲解。留到出问题、检查点帮他们恢复的时候再说，因为那时他们最能理解。
这是我们写的。写给正在冲刺开发首个产品的构建者；他们更需要撤销按钮，而不是 Git 教程。