用途
twoperson 解决的是一个很具体的问题：当你让两个 AI 编程智能体（一个负责写代码、一个负责审查）协作时，「先审查再交付」这条规则如果只写在系统提示词里，时间一长构建智能体就会自行决定审查是可选的、自己批准自己的工作，或者在拿到真实审查后又在上面 rebase 更多 commit 再整体推送。twoperson 把这条规则从提示词移到了两个智能体互相通信的数据格式里，用 schema 来强制。
主要能力
twoperson 的核心是五个「拒绝」机制：
- 审查结论必须回答一个真实存在于收件箱中的审查包。
- 批准必须指名该审查包所在的 commit，而不能是其他 commit。
- 审查包不能在缺少审查引用的情况下声称已推送、部署或重启。
- 引用必须是一个真实存在、表示批准、且批准该 commit 的结论。
- 如果审查包的 changed_files 显示改动了测试（除了新增或复制），所引用的结论必须确认这些确切路径。
除拒绝机制外，它还包括：从两个 sha 之间的 git diff 重新计算 changed_files 和 diff_summary，并拒绝与 head 不符的声明；检查 base_sha 是否为 head_sha 的真实祖先（用 git merge-base --is-ancestor）；当 base_ref 能解析时还要求 base_sha 可达；对审查包做严格 schema 校验（拒绝未知键、限制字符串长度和列表数量、路径必须是仓库相对路径）；扫描疑似凭据（Anthropic、OpenAI、GitHub、AWS、Slack、Google 密钥、PEM 块、bearer token 等）；在渲染审查包时用 BEGIN/END 标记包住正文并声明这是数据而非指令。
使用方式
工作流程是：构建智能体写一个 review packet（审查包），即一份 JSON 记录，包含它试图做什么、head sha、改了哪些文件、跑了哪些测试及结果。twoperson publish 校验它并放入 .twoperson/pending/。审查者认领它、阅读它，并写下 verdict（结论）。twoperson verdict --ack-test-changes 用于确认测试变更，它会从被审查的 --packet 推导确认路径而非手打列表。twoperson verify 运行与 publish 相同的检查（包括 diff 推导）但不写任何东西，可用于试运行。check 设计为可轮询，不触碰模型。
它还可以通过 twoperson install 添加一个 Stop hook 到 .claude/settings.json，在会话结束时向收件箱投放一个小的信号文件。在 Mac 上，twoperson install-watch 设置一个 launchd agent，在收件箱变化时触发并运行你在 TWOPERSON_ON_PACKET 中配置的命令。
twoperson 会向上查找到主工作树，让仓库的每个 worktree 都落在同一个 .twoperson/，可用 TWOPERSON_INBOX 覆盖。twoperson tier 根据校验过的字段给审查包打分，报告 low、medium、high 或 critical，供审查者侧按难度选择。此外还有 consult 通道（consult-publish / consult-next / consult-advise），用于征求意见而非审计，不产生结论，也不能解锁推送。
适用场景
适合让两个 AI 编程智能体针对同一仓库协作、并希望在数据层面强制「审查后方可交付」的场景。也适合需要留下可追溯的、绑定到具体 commit 的审查记录的团队。
限制
twoperson 明确不运行模型，它只记录约定和分层（tier）。凭据扫描是「绊线」而非保证。它不需要服务器、API key 或网络。文档中也指出了与同类项目的差异：它不是在本回合内阻塞 stop 的审查门，而是留下持久化的、绑定到具体 commit 的记录。更多具体计费、平台或价格信息暂未提供。
