unfreeze

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

unfreeze 是 /freeze 的对偶:把上一次 /freeze 设置的「只允许编辑某目录」边界清掉,让 edit 在所有目录恢复自由。

设计思路

作者把「冻结 / 解冻」当成一对临时锁,用来在执行某个高风险任务时约束 agent 的写范围。/freeze 把允许的目录写到 $STATE_DIR/freeze-dir.txt/unfreeze 删掉这个文件即解锁——hook 仍注册在 session 里,但因为没 state 文件,hook 默认放行一切。要再次冻结,再跑一次 /freeze

工作流

① 跑 eval "$(~/.claude/skills/gstack/bin/gstack-paths)"GSTACK_STATE_ROOT;② 检查 $STATE_DIR/freeze-dir.txt 是否存在;存在就读出 PREV,删除文件,告诉用户 "Freeze boundary cleared (was: $PREV). Edits are now allowed everywhere.";不存在则告知 "No freeze boundary was set.";③ 全程顺手 append 一条 telemetry 到 ~/.gstack/analytics/skill-usage.jsonl

与 freeze 的关系

  • /freeze <dir> 写 state 文件,把允许写的范围限定在 <dir>
  • /unfreeze 删 state 文件解锁
  • hook 在 session 里始终注册,所以无须重新挂 hook,只是当 state 不存在时变成 no-op

适合的场景

  • /freeze 任务跑完,把边界主动撤掉
  • agent 误操作了 /freeze 想立即解锁
  • 切到新任务前先 reset 写权限

不适合

  • 你压根没跑过 /freeze:跑了也只是 echo "No freeze boundary was set."
  • 想精细收紧边界而非解锁:直接 /freeze 设新目录覆盖即可

配套

freeze(建立写边界)、continuous-checkpoint(冻结期间常配套自动 commit)、ship(合并前先 unfreeze 让 /ship 可改各处)、autoplan(在计划模式下也常配套使用 freeze / unfreeze)。

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

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

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

输出预览 unfreeze.preview
作者没有在当前 SKILL.md 中定义固定输出样例。

讨论

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