fix(skills): 明确 ask 的授权与提问边界

[47seek]

当前 botmux-ask 将写文件和调用外部 API 列为需要用户选择的场景，容易让已获授权的常规工作重复等待确认。本次明确以任务授权和具体操作规则判断是否需要提问，并将需求分支提问限定为会实质改变目标、范围或影响且无法依据已有要求确定的选择。

已有授权覆盖的步骤继续执行；具体流程要求重新确认时仍遵循该要求，workflow humanGate / decision 的现有约束保持有效。

影响面：src/skills/definitions.ts 中的共享 ASK_SKILL 文案，适用于使用该 Skill 的 CLI、平台及会话。命令参数、按钮交互和权限检查逻辑保持原有行为。

验证在与提交内容一致的隔离源码副本中执行，使用 Bun 1.4.0 和锁定依赖：

• bun install --frozen-lockfile：成功。
• bun run test test/ensure-ask-skill.test.ts test/builtin-skills.test.ts test/skill-injection-mode.test.ts test/session-skill-injection.test.ts：4 个文件、59 个测试通过。
• bun run build：通过，包括 TypeScript、scripts 类型检查、dashboard bundle、dist 和 embedded assets 审计。
• git diff --check：通过。

验证覆盖 Skill 安装和注入；模型采用新措辞后的实际提问频率有待使用反馈。发布状态：本次提交 PR，运行中的 daemon 尚未部署此分支。

[deepcoldy]

感谢这个改动 👍 方向我们认同：把「是否要打断用户」的判据从按动作类型（写文件、调外部 API 一律先问）改成按授权是否已覆盖，确实能治好「已授权的常规活儿反复弹卡」这个问题。PR 描述里的验证也很扎实，我们复跑了一遍，结果与你写的逐字一致：

• bun run build 通过
• 你列的 4 个测试文件：59 passed
• CI 4/4 全绿（build / bun-test / bun-binary / bun-binary-musl）
• 与最新 origin/master rebase 后零冲突（期间合入的 4 个 commit 没有触碰 src/skills/definitions.ts）

代码本身没有发现缺陷或回归。下面一条是建议合入前顺手修，不是阻塞问题。

---

建议：frontmatter 的 description 也一并更新（src/skills/definitions.ts:1146）

正文的「什么时候用」已经改成授权口径了，但 frontmatter 的 description 还停留在旧说法：

触发场景：你需要用户在多个明确选项中做选择、确认风险动作、决定继续/回滚/中止……

这不只是文档一致性的问题，而是投放路径的问题。skills.builtinInjection 的默认值是 prompt 模式（DEFAULT_BUILTIN_SKILL_INJECTION），在这个模式下真正进入模型 prompt 的只有 description 这一行，正文要模型主动执行 botmux skill show botmux-ask 才读得到。

我们从生产入口 builtinSkillBlockForInjectsSessionContext() 实跑确认：

- botmux-ask: …触发场景：…确认风险动作、决定继续/回滚/中止…

  新措辞「已有授权覆盖」「具体操作规则」「实质改变目标」： 全部 NO
  旧措辞「确认风险动作」「继续/回滚/中止」：              全部 YES

  body 2783 字符  vs  description 157 字符

也就是说，在默认路径上这次改动目前是 0 字节可见的。botmux skill list 的输出同样仍是旧 description。

为什么这会削弱改动的效果：description 是模型判断「这个 skill 跟我当前处境有没有关系」的匹配键。旧文案把 botmux-ask 定位成「风险动作确认工具」，那么模型在遇到「已授权的常规操作还要不要问一下」时，根本不会把这个 skill 匹配上——而这恰恰是本 PR 想治的那个场景。

补充一点：在 global 模式下 ensureAskSkill 会把 SKILL.md 全文落盘（我们实测新正文 2783 字节完整可见），所以并非所有路径都失效；但默认的 prompt 模式确实读不到。

建议改法：把 description 里的「确认风险动作」换成与正文一致的授权口径（比如「按当前授权与操作规则判断是否需要用户批准」）。一行的改动，我们也 grep 过，没有任何测试锁住旧的 description 文案，改动是安全的。

可选：补一条测试

test/builtin-skills.test.ts 里 botmux-ask 现有的断言只覆盖 stdout / mention 契约（:334-342），「什么时候用 / 不要用」这两节零断言——也就是说这次改的正文即使被改坏也不会让测试变红。

同一个文件里 botmux-send 恰好有现成范本（:301-310），注释写得很清楚：

// Skills are matched by DESCRIPTION — the blocked-scenario trigger must live
// in the frontmatter, or a stuck agent won't realize send has --attention.
const fm = send!.content.split('---')[1] ?? '';
expect(fm).toContain('--attention');

如果愿意补，建议两条：① 断言 description 含授权口径（这条会让上面那个问题机械地变红，正是它的价值）；② 断言正文「什么时候用」节含新的门控措辞。注意顺序：第 ① 条需要先改了 description 才会绿。

---

最后说明边界：我们只验证到「默认路径上模型读到的仍是旧口径」，没有验证「模型因此就会多问」——正如你在 PR 描述里自己指出的，实际提问频率还得看使用反馈，这一点你的判断是对的。

以上是自动评审的初步意见，仅供参考，最终以维护者审阅为准。再次感谢你的贡献 🙏