| name | adopt-from-external-repo |
| description | 调研开源 repo 看「可偷什么」时，用这个流程——克隆读全源、按 ROI 排清单、审视现有系统、偷抽象不偷代码、融入现有机制不做加法。Use when 用户发 GitHub 链接 + 问「可以偷师 / 借鉴什么」，或你提议要参考外部项目。 |
| provenance | user-authored |
Adopt From External Repo — 抽象收敛而非功能堆砌
核心原则
偷代码是加法，偷抽象是结构性收敛。
当现有系统已经有一套机制在转（Orb 有 18 cron / 4 文档轴 / holographic / handlers），加功能几乎总是错的——应该找「把现有机制闭环起来的缺失抽象」。
五步工作流
1. 克隆 + 读全源（不要只看 README）
cd /tmp && rm -rf <name> && git clone --depth 1 <url>
wc -l <name>/**/*.{py,js,ts,md}
小仓库（<2000 行）全部读。大仓库按 README 的核心模块图挑 3-5 个关键文件。
2. 列「可偷清单」，按 ROI 初排
按什么标准判 ROI：
- P0 立即可落地 — 一段可复用的工具函数 / 一个简单 pattern
- P1 新能力 — 当前系统没有的机制（发散采样 / lifecycle / 反馈通道）
- P2 治理增强 — doctor / schema / 日志
- P3 小增强 — 命名 / 模板 / 辅助
3. 审视自身系统（最关键的一步，别跳）
盘 3 件事：
- 有多少类似机制已在跑？（cron 数 / 文档轴数 / 积累的候选池 / 已有 handler）
- 哪些是「沉淀但不晋升」「产出但不消费」「存了但不打分」的断点？
- 偷的清单里哪些是复制现有（不做），哪些是补断点（做）？
运行真实命令查数据（见 lesson data-reality-before-design）：
wc -l <pool>
sqlite3 <db> "SELECT COUNT(*) WHERE ..."
ls <cron-jobs>
4. 翻转清单：从「加法」收敛为「一件结构性事」
最终输出不是偷来清单的子集，是一个把现有 N 处断点连起来的抽象。剩下的清单条目分类为：
- ✅ 做（1-2 件结构性）
- 🔧 小补丁（健壮性级）
- ❌ 不做（加法 / 已有功能重复 / 概念负担）
每条「不做」都要写出为什么不做（避免未来某天又想加）。
5. 融入而非叠加
铁律：零新 cron、零新文档轴、零新概念。新逻辑插进现有 cron 的 prompt / 现有 handler / 现有 pipeline。
实战手法：
- 新功能接进已存在但空转的基础设施（如
skill-candidates.jsonl 空着就直接用它）
- 周期性任务挂在现有 cron 的附加步骤，用「失败不阻塞主体」模式
- Slack 按钮复用
handlers/ 框架（新增 handler 脚本 + action_id）
反模式
- ❌ 读 README 就开始列清单（源码里的约束 / 边角机制全漏掉）
- ❌ 直接抄单个脚本（加了新 cron、新文档轴、新概念负担）
- ❌ 跳过「审视自身」→ 叠加式膨胀
- ❌ 把「偷清单」本身当交付（应该是收敛后的一件结构性事）
验收标准
出结果时能清晰回答：
- 真正做的那一件 是什么？解决哪 N 处断点？
- 不做的每条 的理由是什么？
- 改动文件数 和 新增概念数 分别是多少？（后者应该接近 0）
案例
本 profile 2026-04-23 的 six6 → Seed Lifecycle 调研就是典型落地：
- six6 6 模块 906 行全读
- 列出 9 条可偷（deadletter / atomic write / daydream / lifecycle / doctor / schema / pulse 语义 / evolution.md / tag 输出）
- 盘自身：Orb 有 18 cron / 4 文档轴 / 3 候选池但都不闭环 / trust_score = 0 的隐藏 bug
- 收敛为：Seed Lifecycle 抽象 一件事，把
skill-candidates + evolution/suggestions + idea 三池用 maturity + 浇水 + 晋升统一
- 零新 cron（复用 01:15 自进化 + 周一 10:30 归档建议周检），零新 handler 框架（复用现有）
