context-save

其他 社区 v1.0.0
解读按原文结构重写,命令、链接、术语均保留;右侧可核对作者原始 SKILL.md

设计思路

context-save 把你当前 session 的工作状态——意图、进展、剩余事项——序列化成一份带 frontmatter 的 markdown,写到 ~/.gstack/checkpoints/。文件名用 YYYYMMDD-HHMMSS-<title>.md 格式,作者特地强调find + sort -r 而不是 ls -1t——文件名前缀是稳定时序,filesystem mtime 在复制 / rsync 后会乱。frontmatter 必须包含 branch,是 context-restore 跨分支恢复的钥匙。

工作流

写入:从 git 状态(branch、staged / unstaged diff、最近 commit)和当前对话上下文里推断出标题、状态、剩余 work item,能不问就不问;只有 title 实在推断不出来才用 AskUserQuestion。

列表(/context-save list

  • 默认只列当前分支的 checkpoint。
  • --all 列所有分支,多一列 Branch。
  • 表头格式:
SAVED CONTEXTS ({branch} branch)
═══════════════════════════════
#  Date        Title              Status
─  ──────────  ─────────────────  ───────────
1  2026-04-18  auth-refactor      in-progress

读取每个文件的 frontmatter 拿 status / branch / timestamp,文件名时间戳后面那段就是 title。

重要规则

  • 绝不改代码——只读 state、只写 checkpoint 文件。
  • branch 必须写入 frontmatter——是跨分支 restore 的关键。
  • append-only——不覆盖旧文件,每次保存都生成新文件。
  • infer,不 interrogate——能从 git 和对话推断的就别问用户。
  • 是 gstack skill,用户输入 /context-save 时通过 Skill tool 调用。旧名 /checkpoint 和 Claude Code 内置的 /rewind 别名冲突,改名后修复。

适合谁

  • 跨天 / 跨 session 持续工作的工程师
  • 多 worktree 切换时希望「合上盖子」的人
  • 任务被打断,怕回来想不起进度

不适合

  • 任务半小时就能做完——存档反而成开销
  • 不在 git 仓库里——无 branch 信息可记

配套

context-restore(读取端)、landing-report(更正式的阶段交付报告)、using-git-worktrees(让 cross-worktree handoff 真正发生)。

流狐档案 作者与许可取自来源;运行、权限和网络为流狐检测或估算
流狐分类
通用
作者声明 Agent
未找到明确声明;不据此推断已兼容或已测试
静态检查
92 / 100 · 启发式扫描,不代表运行安全
作者 / 版本 / 许可
@garrytan · v1.0.0 · 未声明 license
流狐 Token 估算
较高消耗
流狐接入估算
需简单配置
是否需要外部 API Key
未发现要求
检测到的系统要求
macOS · Linux · Windows
底层运行要求
Bun
检测到的文件与系统行为
  • 只读
  • 允许写入 / 修改
  • Shell 执行
检测到的网络行为
允许外网请求
安装命令数
无(仅作为资料)

档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。

需要注意: 未限定 allowed-tools,默认拥有全部工具权限。

输出预览 context-save.preview
# Writing Style (skip entirely if EXPLAINLEVEL: terse appears in the preamble echo OR the user's current message explicitly requests terse / no-explanations output)

- Gloss curated jargon on first use per skill invocation, even if the user pasted the term.
- Frame questions in outcome terms: what pain is avoided, what capability unlocks, what user experience changes.
- Use short sentences, concrete nouns, active voice.
- Close decisions with user impact: what the user sees, waits for, loses, or gains.
- User-turn override wins: if the current message asks for terse / no explanations / just the answer, skip this section.
- Terse mode (EXPLAIN_LEVEL: terse): no glosses, no outcome-framing layer, shorter responses.

讨论

基于 GitHub Discussions。登录 GitHub 即可参与讨论、点赞、订阅更新。