放弃了「一句话修好」的体验
确认步骤会让流程变慢。但这是维修，不是补全代码。一次误删的代价远高于多按一次回车。慢是设计出来的。
先取证，再判断；先计划，再修改
2026 · 技能设计与实现 · Agent Skill · Python · Markdown · AGPL-3.0
一个能装进 Codex / Claude Code / OpenClaw 的跨平台电脑维修 Skill。C 盘爆满、卡顿、流氓软件、弹窗广告、网络问题这些直接用自然语言说，Agent 按平台与风险挑一条 Playbook 走。64 个 Playbook 按需加载，覆盖 Windows / macOS / Linux。标题那句是它写在 README 第一行的规矩。
64专项 Playbook
338GitHub Star
3覆盖操作系统
0需装桌面端
01背景
C 盘爆满、系统卡顿、流氓软件、数据恢复，这类问题用自然语言描述很容易，但通用 Agent 常常跳过取证直接给命令。在别人的真机上执行，这是有破坏性的。
02卡在哪
既要覆盖 Windows / macOS / Linux 三套完全不同的排查路径，又不能把所有知识一次性塞进上下文。塞进去就会互相干扰，Agent 会在 Windows 的问题上引用 Linux 的命令。同时必须区分只读诊断与写操作，让删除、提权、分区、服务修改这类动作永远先经过人确认。
03怎么解
把知识拆成 64 个专项 Playbook，通过一张路由索引按问题按需加载，无关内容不进上下文。执行层设两条硬规则：证据优先，先读系统状态、日志与硬件事实，再建立候选原因；只读优先，任何改变状态的操作都必须先给出影响面、回滚方案与验证步骤。技能资源以 Markdown 为主，不绑定桌面程序，装进你已经在用的 Agent 就行；仓库带 CI，每次改动都校验 Skill 结构与 Playbook 索引，保证 64 个文件的路由表永远对得上。
关键取舍
写清楚放弃了什么，比罗列做了什么更说明判断。
放弃了桌面客户端
做成客户端就要处理签名、更新、权限弹窗与三套安装包。以文本资源为主的 Skill 可以被任何支持 Agent Skill 的宿主直接读，迁移成本接近零。
64 专项 Playbook仓库树 skills/computer-repair-skill/references/playbook-*.md 计数（不含索引与 authoring）
338 Star / 35 ForkGitHub API：GET /repos/88lin/computer-repair-skill，2026-10-01
3 覆盖操作系统README 声明的 Windows / macOS / Linux 三条排查路径
CI 结构校验仓库 GitHub Actions 工作流：路由表与 Playbook 结构校验