技能介绍

要解决的问题

大模型跑完一轮长会话后，最常见的交接方式是复制粘贴 transcript：既没有来源校验，也会随上下文压缩丢失细节。换成共享的中心仓库虽然可行，但要所有人就仓库名达成一致，而且仓库里的每一段对话历史对所有成员可见——收件箱越热闹，泄露面越大。

它怎么工作

这个技能只实现 P2P 模式：每个人持有一个私有 GitHub 收件箱仓库，发送方作为 collaborator 直接推送文件，没有中心仓库，也没有回退路径。

交接载体是极简的：文件名形如 2025-01-01T00-00-00Z--from-alice.txt，内容恰好一行分享 URL。接收端统一调用 verify_inbox.py，所有校验逻辑都收敛在这一个脚本里，shell 层不重新实现任何判断。

校验分五层：

Tier 1 文件名必须严格匹配正则，否则文件连 git log 都不会被传递给，直接保留；
Tier 2 发送方必须在 trust.json 白名单中，否则静默删除并计数；
Tier 3 内容按字节读取（git show HEAD:，不走工作树），限制 ASCII 与末尾换行，杜绝 BOM、CRLF 走私；
Tier 4 commit 作者与提交者必须都是 claimed_sender，捕获 collaborator 伪造归属；
Tier 5 若开启 require_signed_commits，要求 GPG 签名已通过 GitHub 验证。

接收是事务性的：先输出信任边界前言，再抓取 URL，把内容包裹在 [收到的会话内容 — 第三方数据] 中展示，全部成功之后才 git rm。顺序颠倒就是数据丢失 bug。

配置也做了分离：权限放 opencode.jsonc，传输设置放 config.json，信任名单单独放 trust.json——这样恶意项目的 opencode.json 无法向白名单注入条目。克隆时通过 -c 内联设置 core.symlinks=false、submodule.recurse=false、protocol.file.allow=never，符号链接与子模块攻击无从下手。

边界与注意

验证管线确认的是谁发送了 URL，而不是 URL 指向的内容。抓取回来的 transcript 属于第三方数据，可能夹带 prompt 注入，前言里会明确标注。

技能只搬运 URL，正文靠 WebFetch 或配套的 opencode-share 解析。规模超过 5 人左右时，N(N-1) 的双向 collaborator 邀请成本过高，应该改用中心仓库合集版。此外，信任发送方的账号与签名密钥同时失守、无密码 GPG 密钥被本机其他进程读取，属于明确列出的未防御场景。