dabingfy-dot/solo-to-team-skills

项目介绍

Solo to Team 面向「一个人带多个长期 AI 助手」的场景，解决四个反复出现的问题：活派出去没人收、说「做好了」却没核过、写给新手的步骤只有作者看得懂、同一个坑踩两遍。包里是四支技能、一个登记行模板、一套跟做示例和脱敏案例，MIT 许可。核心是一条线：提目标 → 分工 → 交接 → 核对 → 判断，派活前先登记一行「待收」，写明谁在干、谁来收、谁到点查 项目说明。

四支技能中，dispatch-accept-verify（派收）与 evidence-before-done（交活前证据）是主流程；beginner-ops-writing（新手操作说明）和 ops-case-notes（脱敏运营记录）是原创的配套内容，前者讲如何把须人做的步骤写到照做就成，后者记录日更流水线和验收链里真实漏过的环节、改法和仍未解决的问题 技能一览。

快速使用

技能都是带 SKILL.md 的普通目录，没有 App 形态；插件清单里 hooks: {}，不附带定时和叫醒。

不装宿主也能开始：从 登记行模板 复制「待收」那一行，派活前写好，到点去查，收到后记「已收到成果」，核对过证据才记「已验收」。想先看完整流程，跟 会议纪要示例 走一遍：给定输入 → 成果 → 证据 → 验收，中间还包含一次退回。

已经在用 AI 助手：把技能目录整份拷进宿主的技能目录，再按名调用。以 Cursor 为例，拷入 ~/.cursor/skills/ 后在 Agent 或 CLI 里点名；Codex 用包内自带的市场清单：

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

装完新开一次会话，例如让它「用 dispatch-accept-verify 登记一件待收的活」Codex 装法。其余宿主各有自己的落点和调用方式：WorkBuddy、DeepSeek Harness、CodeBuddy、Kimi Work 拷目录，千问办公拷 ~/.qwenworkcn/skills/，Grok Bot 需在对话里把正文存成私有技能；Claude Code 结构已备但尚未列为支持 各宿主一览。

手动拷贝时整目录拷，不要只拷 SKILL.md：dispatch-accept-verify 要连同 templates/ 一起，否则登记行模板会丢。

使用约束

• 关键动作留给人。花钱、发出、删除、登录、付款确认这类步骤，技能一律写「请本人来」，不代做；收下还是退回也由人拍板。
• 不含自动化。到点查、催办、跨助手发消息、叫醒都依赖宿主自身能力；宿主没有定时，就由人按点去查。不要把本包理解成自动派工或自动回执。
• 支持范围按具体产品算。「支持」只指某一种装法和调用方式有走通记录，不代表同品牌其他客户端也能用。CodeBuddy ≠ WorkBuddy，Kimi Work ≠ Kimi Code CLI，千问办公 ≠ 通义灵码；其他工具尚未验证。
• 效果有边界。方法在队内日更主链上跑了约两周余、复盘 3 次，但没有对照实验，尚未证明全队错误率下降或催办变少；八家宿主各有一例有限任务的验收记录，不代表稳定性。
• 版本状态。README 标注为 v0.9-draft，正式公开前还会改。

HotRepo 点评

项目在 2026-11-07 的 HotRepo 新项目榜上被记录到 106 star、10 fork，统计窗口约 10.7 小时。对一个没有编程语言代码、以文档和技能正文为主的新仓库来说，首日这个量级说明它踩中了当下对 Agent 技能包的关注，但不构成采用率或效果的证据。它值得看的地方恰恰是克制：明确写出八家宿主各只有一例有限任务的验收记录、会议纪要 walkthrough 是教学样例而非实测、约十分钟的说法只在 Cursor CLI 已备好环境的条件下测到约 30 秒。读者宜把它当一套可照做的方法模板加案例来评估，而不是已验证的团队自动化产品。