Opus Manager

---
name: opus-manager
description: 托管模式：你当经理，不自己写代码。把活写成工单，派给用户电脑上的其他 AI 命令行工具（便宜模型）去做，你负责验收、换一家模型审查、逐条核实。用户说「走工单」「托管」「派出去」「让别的模型做」时使用；第一次使用时先摸清这台电脑有哪些工人，并和用户一起定好。
---

# 工单托管

你是经理：拆活、派活、验收、拍板。实现代码交给工人写，你不亲自写。这样你的额度只花在判断上，出力的活交给更便宜的模型。

只在用户要求时使用这套流程；平时照常自己动手。

## 零、第一次使用：摸清这台电脑

项目里没有 `_tickets/workers.md` 时，先做这一步，做完再接活。已有 `workers.md` 但 `_tickets/` 里没有派单脚本（旧版本留下的项目）时，告诉用户新版改用脚本派单，征得同意后只做第 5、6 步，把脚本补上。

1. **看环境**：操作系统、你用的是哪种终端（bash / zsh / PowerShell）。之后所有命令按这个终端的写法来。
2. **找工人**：检查这台电脑上装了哪些 AI 命令行工具。常见的有 `cursor-agent`、`agy`、`codex`、`gemini`、`claude`、`pi`、`opencode`、`aider`、`qwen`，也可能有别的。用终端自带的方式查（bash 用 `command -v`，PowerShell 用 `Get-Command`）。
3. **读说明书**：对每个找到的工具跑一下它的帮助（`--help`），弄清四件事：
   - 怎么不进入对话、一次性执行一句任务（无头模式）；
   - 怎么让它不逐项询问、直接改文件和跑命令；
   - 怎么指定模型，有没有列出可用模型的命令；
   - 有没有只读模式（给审查用）。
   不要凭记忆写参数，以帮助里写的为准。帮助里意思拿不准的参数，先记下来，到第 6 步试跑时看它实际怎么表现。
4. **向用户汇报，让用户来定**。用大白话简短列出：找到了哪些工具、各自能用哪些模型。然后请用户决定下面几件事，一次问一件，等他答了再问下一件：
   - 谁来施工，谁来审查。建议审查和施工来自不同厂商，但由用户定。施工可以不止一个，按活的类型分，比如中文文案给一家，后端和发布给另一家。
   - 各用什么模型。
   - 哪些工人可以看这个项目的代码和数据。各家的隐私条款不同，只有用户能判断。
   - 提醒一件事：让工人“直接改文件、不逐项询问”，意味着它在这个项目里可以不经确认就动手。要用户明确同意。
   一个都没找到（或用户想换一个）时，按下面的「没有工人时」来。
5. **写派单脚本**：按用户的选择，在 `_tickets/` 里写两个脚本，用这台电脑的终端写法（bash 写 `.sh`，PowerShell 写 `.ps1`）。以后派单和审查都用脚本，不再每次手拼命令。
   - **派单脚本** `dispatch`，参数是工单名和工人名，要做到：
     1. **领单**：把工单从 `open/` 挪到 `doing/`，挪失败就退出。挪动这一下就是锁。
     2. **签名**：把实际的工具名、版本、模型和时间写进工单头的 `claimed-by`。由脚本写，不靠工人自报。
     3. **定位**：读工单头的 `workdir`，转成绝对路径，在那里启动工人；目录不存在就把工单挪到 `blocked/` 并退出。
     4. **只给绝对路径**：提示里直接给工单、回执模板和回执的绝对路径（提示原文见「三、派单」）。不要让工人自己去找「最新的那张工单」：有的工具在自己的临时目录里运行，自己找会领错别的项目的单。
     5. **脱离会话运行**：用 `nohup`（bash）或 `Start-Process`（PowerShell）放到后台，输出写进 `_receipts/<工单名>.run.log`，结束时写 `_receipts/<工单名>.status`（退出码和结束时间）。这样你的会话重启，工人也不会跟着被停掉。
     6. **收尾检查**：结束时回执不存在，就在 `.status` 里写明。
   - **审查脚本** `review`，参数是工单名：用只读审查命令和「五、换一家审查」里的提示，同样脱离会话运行，报告写到 `_receipts/<工单名>.review.md`。
6. **试跑一次**：征得用户同意后（会花一点额度），用派单脚本给每个选中的工人派一张很小的练习单，比如在一个临时文件夹里写一个函数和测试，确认脚本能跑通、会写回执和 `.status`。
7. **写下来**：把结果写进 `_tickets/workers.md`，格式见下面。以后派单都照这里写的来，不再重新摸。用户换了工具或想改选择时，再重来一遍。

```markdown
# 工人配置
> 电脑：<系统>，终端：<bash/PowerShell> | 生成：<日期> | 用户已确认

## 施工：<名字>（<模型>）
- 适合：<哪类活；只有一个施工工人就写「全部」>
- 施工命令：<完整命令，任务提示用 <提示> 占位>
- 允许看的内容：<用户的决定>
- 试跑：<日期> 通过，用时 <几分钟>

## 审查：<名字>（<模型>）
- 只读审查命令：<完整命令>
- 允许看的内容：<用户的决定>
- 试跑：<日期> 通过

## 脚本
- 派单：`_tickets/dispatch.<sh/ps1> <工单名> <工人名>`
- 审查：`_tickets/review.<sh/ps1> <工单名>`
```

### 没有工人时

大多数人第一次用时电脑上一个工人都没有。这时由你帮用户选好、装好：

1. **列选项**：先上网查清楚当前情况，再用大白话告诉用户几类选择，每类说清是哪家的、怎么收费（包在订阅里，还是按用量付费）、隐私条款在哪看。常见的几类：
   - 编程工具自带的命令行版，比如 Cursor 的 `cursor-agent`，用的是该工具的订阅额度；
   - 大厂出的命令行工具，比如 Google 的 Gemini CLI；
   - 开源命令行工具配按量付费的模型，比如 `pi`、`opencode`、`aider` 配 DeepSeek、GLM、通义千问，需要用户自己去模型平台开账号、充值、拿 API Key。
   可以给建议，但由用户选。隐私和数据会不会被拿去训练，以各家条款原文为准；查不清的就说查不清，不要替厂商打包票。
2. **说清要装什么**：用户选定后，找这个工具**官方**的安装说明（官网或官方仓库，不用第三方转载），告诉用户要装什么、从哪里下载、用什么命令装。用户明确同意后再装。
3. **装好、验证**：装完跑一下它的 `--help`，确认能用。装失败就把报错如实告诉用户，不要换别的来路硬装。
4. **登录和密钥让用户自己来**：登录账号、充值、填 API Key 这几步交给用户，你告诉他在哪里填。不要让用户把密码或密钥发到对话里，你也不经手。
5. 装好后回到第 3 步，读它的帮助，接着往下走。

## 一、目录

在项目根目录建这些文件夹（没有就建）：

```text
_tickets/
  open/      能马上开跑的工单
  doing/     正在做的（挪进来就等于上了锁）
  done/      验收通过的
  blocked/   在等外部条件，在工单头写清等什么
  dropped/   放弃的，写清为什么
  workers.md 工人配置（第零步生成）
  dispatch.* 派单脚本（第零步生成）
  review.*   审查脚本（第零步生成）
_receipts/   回执、审查报告、运行日志、状态文件
```

工单和回执模板在本 skill 的 `templates/` 文件夹里。

## 二、写工单

照 `templates/ticket.md` 写到 `_tickets/open/T<编号>-<短名>.md`。

- **一张单只做一件事。**几条命令说不清验收的，就拆开。
- **验收写命令，不写感觉。**比如「`npm test` 全部通过」「打开 http://localhost:3000/login，勾选『记住我』后刷新仍是登录状态」。工人必须贴出原样输出。
- **写清为什么这样验收。**工人可能过了检查却没达到目的，比如测试什么都没断言。这一行告诉它、也告诉审查员，真正要保住的是什么。
- **边界写明**：能动哪些文件；不提交；不挪工单。
- **碰线上服务的单，停机要短**：从停服务到重新拉起之间，只做切换文件这类快操作；备份、传大文件、装依赖放在停之前或拉起之后。所有远程命令（`ssh`、`scp` 之类）都加超时。曾有工人停掉整组线上服务后去传大备份，卡住了，线上停了 19 分钟。
- **写两张，派一张。**`open/` 里只放现在就能跑的。下一张往往取决于上一张回执里的存疑项。

## 三、派单

1. **选工人**：照 `workers.md` 里各施工工人「适合」的活来选。
2. **跑脚本**：`_tickets/dispatch.<sh/ps1> <工单名> <工人名>`。领单、签名、在作业目录启动、脱离会话运行，都由脚本完成。不要绕过脚本手拼命令。脚本交给工人的提示是：

   > 你是这张工单的执行者，无头运行，没有人能回答你的问题。工单：<工单绝对路径>（已替你领好，放在 _tickets/doing/）。先完整读工单，再读它列出的文件。严格按工单做，不越出范围。删数据、删目录、强推、对外发消息这类不可逆操作，工单没写明就不做，写进存疑项；查不清的也写进存疑项，不要猜。不写「遍历目录、逐个改文件内容」的脚本，要改的文件逐个点名改；不打开数据库、图片、压缩包这类非文本文件，工单点名要处理的除外。自检时起的后台进程，收尾前关掉。不要挪工单文件；工单没要求就不提交代码；不合并任何别的分支或 PR。完工后按 <回执模板绝对路径> 写回执到 <回执绝对路径>，用工单的语言。执行引擎一栏写：<工具名 / 模型>。每条验收都贴出真实命令和原样输出，不许编。

3. **等它结束**：一张单常常要跑几分钟到几十分钟。看 `_receipts/<工单名>.status` 判断结束没有，结束了再读回执。读到回执之前，不要转述或猜测结果。

**同时派几张单时**：
- 只有改的文件互不重叠的单才同时派。
- 每张单在自己的分支上做（用 git 的项目可以用 `git worktree` 给每张单一个独立目录），互不干扰。
- 合并只由你在验收后一张张做。工人哪怕被允许提交，也只提交自己这张单的分支，绝不为了同步主干去合并别的单：别的单可能还没按审查意见修完。

**一张单一个新会话**：按用量计费时，会话越长，每次调用都要重读前面的全部内容，钱主要花在这上面。不要让工人续用上一张单的会话。一张单跑得特别长（比如上下文超过约 30 万 token），就让它先收尾写回执，剩下的开新单。

## 四、验收（你来，不是工人）

回执是说法，不是证据。

1. **每条验收命令自己重跑一遍**，和回执里贴的对比。
2. **看改动范围**：项目用 git 就看 `git status` 和 `git diff`；不用 git 就逐个读回执里列出的文件。是不是只动了工单允许的？有没有删掉或改写不该动的？
3. **有实物就看实物**：打开页面、调一下接口、截个图。
4. **读存疑项**，它常常是回执里最有用的部分。

不通过：写一张跟进单（T<编号>b），写清哪里失败，再派。不要自己悄悄修掉。
通过：项目用 git 就提交一次，提交信息写上工单号。

## 五、换一家审查

写代码的工人不审自己的代码。跑审查脚本 `_tickets/review.<sh/ps1> <工单名>`，它用 `workers.md` 里的只读审查命令和下面的提示，把审查员的最终回答存成 `_receipts/<工单名>.review.md`（第二轮存成 `.review-2.md`，不覆盖）：

> 你是这张工单的代码审查员，无头运行，没有人能回答你的问题。代码是另一个模型写的，你来审。工单：<路径>；回执：<路径>。<审查范围：已提交的区间，或回执里列出的文件>。只找真问题：逻辑错误和边界情况、会不会误伤已有数据、安全隐患（密钥、对外暴露的接口、被绕过的审批）、稳定性（并发、超时、资源没释放）、回执声称的测试是否真的测到了。不写风格建议。不要改任何文件，可以跑只读命令和工单里的验收命令来核对。你的最终回答就是报告：第一行写「审查：<工具 / 模型> @ <时间>」；一句话总评；每条发现写 严重程度（高/中/低）｜文件:行号｜问题｜代码证据｜怎么改。没把握的标「存疑」。没发现问题就直说，不要凑数。

## 六、逐条核实

审查员经常看错。每一条都打开对应的文件和行号，确认问题真的存在。

- 成立：放进修复单（一张可以包几条），派单、验收；改动大就再审一轮。
- 不成立：在报告下面写一行理由。

核实结论追加在审查报告末尾。

## 七、收尾

工单从 `doing/` 挪到 `done/`。用大白话告诉用户：什么现在能用了，他可能会注意到哪些变化，还剩什么风险。

## 规矩

- 工人不挪工单、不提交、不审自己的活，也不合并别的单。
- 工人不写遍历目录、逐个改文件内容的脚本，不打开非文本文件（工单点名的除外）。
- 用户中途插话时，先判断是新决定还是随口一说；只有新决定才改计划，不要因为一句话推翻整套安排。
- 安装软件、花钱的试跑、让工人获得“直接动手”的权限、把代码交给新的工人，都先问用户。