用途
ds-unstick 用于打破重复失败的僵局。资料指出，当两次修复以相同方式失败时，问题通常不是某处编辑写错了，而是一个错误的前提假设在作祟。该技能的目标就是找出这个假设并直接验证它。
主要能力与步骤
- 停止编辑：不要再尝试同一修复的第三种变体。
- 记录失败尝试：每次尝试写一行，说明改了什么、发生了什么，并附上准确的错误文本。
- 命名共享假设：写出一句话，概括所有这些尝试共同依赖的假设。资料给出的典型例子包括："这个文件就是实际运行的那个""配置已加载""函数收到的是字符串""缓存已清空""错误来自我的代码"。
- 直接验证假设：用成本最低、能给出是/否答案的探测手段测试该假设，例如打印语句、日志行、which 或 --version、用 grep 查找真实调用点、最小脚本，或阅读所安装确切版本的文档。需要粘贴探测结果。
- 分支处理：若假设为假，即找到了真正的问题，依据新事实规划修复；若假设成立，列出 3 种不同方法。"不同"指另一种机制、库、层次或数据路径，而不是同一编辑的微调。每种方法用一行说明成本与风险。
- 选择并说明理由：选定一种方法，用一句话说明原因。
- 干净重启：若失败尝试留下了残留，先用 git 还原（git stash 或 git checkout -- <files>），然后只应用所选方法。
- 记录：将假假设或所选方法记录到 PROGRESS.md（参见 ds-context-reset），以免后续会话重复这些尝试。
- 返回验证循环：带着新方法回到 ds-verify-loop。
停止条件
- 第 4 步的探测解释了失败原因，或新方法通过其检查。
- 该技能已执行两轮仍失败时，停止并向用户报告：尝试过什么、测试了哪些假设、证据是什么，并请求指示。
规则
- 不要重复已经失败的修复，即使只做了小改动。
- 证据优先于推理；如果一个探测只需一分钟，就去运行它。
- 保留失败尝试清单，因为它是报告中最多有价值的部分。
- 在新方法之前使用干净状态，避免旧编辑掩盖结果。
适用场景
适用于开发调试过程中反复尝试同类修复却始终失败的情形，尤其是怀疑存在错误前提（如文件、配置、缓存、调用点、版本行为）时。
限制
资料未提供该技能的安装方式、运行平台、依赖条件或收费信息，暂未提供。