WorkBuddy 执行手册生成器

它解决什么问题

日常让 AI 干活，翻车姿势基本固定：你只说了一句需求，Agent 直接开干，做到一半才发现方向错了；任务有七八步，中途漏掉关键验证，交付时才发现用不了；某一步失败（文件不存在、命令报错），Agent 要么原地重试，要么瞎猜绕过；真要回滚时，Agent 已经改了一堆文件，谁也说不清动了什么。

这个技能给 WorkBuddy 补上「流程感」：先把需求拆成一步步可执行的清单，每步写明做什么、怎么证明做完、失败了怎么办，让 AI 把事做完、做稳、做错也能体面回退。

核心能力与关键步骤

• 拆解 brief：把模糊的一句话需求拆成 numbered steps。
• 六要素锁死每一步：Objective（一句话目标）、Action（具体到能直接执行）、Tool（要调用的能力）、Expected Output（完成后现场留下的结果）、Verification（可观测检查，优先命令 / 文件存在 / 输出匹配，而不是「看起来对」）、Fallback（失败后第一时间的回退动作，不是「再试一次」）。
• 产出文件：写入 ./runbooks/{slug}_{YYYY-MM-DD}.md，runbooks 目录不存在时自动创建。

两种模式：Plan（默认）只输出 runbook 并停下等用户确认；Craft 仅在用户明确说「直接执行」「Craft」「run it」时触发。Craft 模式下严格按序执行、不跳步，每步先跑 Verification，失败立即走 Fallback，重试不超过 2 次；Fallback 也失败就停下来报告步骤、错误、已执行内容与建议方案。每步完成还要输出证据：文件路径、命令输出前 20 行或截图说明。

适用边界

• 不要写「了解一下」「分析一下」这类无法验证的 Action，也不要省略 Verification 或 Fallback。
• 复杂任务别塞进单个 runbook，一次 50 步不如拆成多个。
• 用户没说「直接执行」就别自动执行；执行前先 read 或 stat 确认文件存在，不要假设。
• 删除、覆盖、发消息、调用付费 API 等破坏性操作，除非用户明确授权。
• 遇到不确定或权限请求就停下来问，不要猜，也不替用户做软性决定。