[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7APKJSYPQV80DFH9M8XSPCS":3,"skill-same:01M7APKJSYPQV80DFH9M8XSPCS":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M7APKJSYPQV80DFH9M8XSPCS","open-source-teardown",null,"明星开源项目拆解：从宣传\u002FPPT\u002FREADME 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent\u002Fruntime、外部 skill\u002Ftool 框架，或问“它到底有什么真本事\u002F我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue\u002FPR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions\u002FYYYY-MM-DD-{project}-deep-dive\u002F 下的代码证据报告 + 对比结论 + 候选 lesson\u002Fskill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。","peps1666\u002FBuildCrew-AI","peps1666","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128503359?v=4","01M7APD9BQ6NTJ79J9FTB6YZGT","junhao zhou","01M7APD9CD06Q6CCJ22FYVG2AK",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopen-source-teardown\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: open-source-teardown\ndescription: >\n  明星开源项目拆解：从宣传\u002FPPT\u002FREADME 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。\n  Use when: operator要求拆解热门 GitHub 项目、竞品 agent\u002Fruntime、外部 skill\u002Ftool 框架，或问“它到底有什么真本事\u002F我们能学什么”。\n  Not for: 普通资料搜索（用 deep-research）、社区 issue\u002FPR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。\n  Output: feature-discussions\u002FYYYY-MM-DD-{project}-deep-dive\u002F 下的代码证据报告 + 对比结论 + 候选 lesson\u002Fskill。\n  GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。\ntips_exempt: Existing teardown quality contract refinement; no new user-facing capability or discovery moment.\ntriggers:\n  - \"拆解明星开源项目\"\n  - \"拆解开源项目\"\n  - \"竞品拆解\"\n  - \"热门 GitHub 项目\"\n  - \"它有什么真本事\"\n  - \"我们能学什么\"\n  - \"marketing vs reality\"\n  - \"算法含量\"\n  - \"拆解 hermes\"\n  - \"看看 letta 怎么做的\"\n  - \"codex cli 源码\"\n  - \"agent runtime 拆解\"\n---\n\n# Open Source Teardown\n\n明星项目拆解不是“读 README 做竞品分析”，而是**宣传 claim → 源码证据 → 能力边界 → 我们的 tradeoff** 的审计流程。\n\n## When to Use\n\n触发：operator看到 PPT、博客、README、社区讨论后问“这个项目是不是很强？”；需要拆解 agent runtime、skill 系统、memory\u002FRAG、MCP\u002Fgateway、RL\u002Feval、插件架构等工程系统；或需要把一次竞品分析沉淀为 lesson \u002F ADR \u002F skill。\n\n排除：只需要查公开资料或论文综述用 `deep-research`；只需要处理外部 issue\u002FPR\u002Fintake 用 `opensource-ops`；还没有明确目标项目、只是在讨论方向用 `collaborative-thinking`。\n\n灰例：如果用户同时要求“查社区 issue 情报 + 读源码”，先用本 skill 建代码证据骨架，再按需补 `deep-research` 或 `opensource-ops`。\n\n## Required Output\n\n默认落盘：`feature-discussions\u002FYYYY-MM-DD-{project}-deep-dive\u002F`，包含 README、architecture-map、明星特性深挖、comparison、lessons\u002Fnext steps。\n\n最小合格产物必须包含：\n\n- source repo URL、local path、commit SHA、更新时间。\n- 宣传 claims ledger：claim \u002F evidence files \u002F Source verdict \u002F Decision fit \u002F unknowns。\n- 架构图或模块地图：entrypoints、state stores、extension points、empty dirs；用 ASCII tree 或 Mermaid，参考 *(internal reference removed)*。\n- 明星特性深挖：每个特性都写到代码路径和运行链路。\n- 算法剥皮表：真算法 \u002F LLM judge \u002F 启发式 \u002F 规则 \u002F 外部服务。\n- Clowder AI 对比：能学、不能学、我们因为 tradeoff 不 follow 的理由。\n\n报告模板见 [refs\u002Freport-template.md](refs\u002Freport-template.md)；八审计镜头 + 命令见 [refs\u002Fteardown-method.md](refs\u002Fteardown-method.md)；用户视角第一性原理（第 9 镜头）见 [refs\u002Fuser-mind-evaluation.md](refs\u002Fuser-mind-evaluation.md)。\n\n## 进度纪律\n\n- **分次推进**：每只猫每次只做 1-2 份产物，commit 后传球，不一气呵成。\n- **双视角交叉**：架构\u002F明星特性\u002F合流\u002Fskill draft 至少跨两只猫完成。\n- **对口 review**：最终报告或 skill draft 必须由非作者猫 review，跨族优先。\n\n### Step 0 — 定边界和真相源\n\n1. 记录用户原始问题和最关心的 claims。\n2. `search_evidence` 查我们是否已有同项目\u002F同类系统讨论、lesson、feature anchor；有矛盾就 flag。\n3. clone 或 update 到 `\u002Fhome\u002Fuser\u002Fprojects\u002Fref\u002F{project}`。\n4. 记录 `git rev-parse HEAD`、最新 tag\u002Frelease、`git status --short`。\n5. 把 README\u002FPPT\u002F官网中的明星特性拆成 claims ledger。\n\n不要先评价。先把“它声称自己有什么”列成可验证对象。\n\n### Step 1 — 架构地图\n\n用 `git ls-files`、`find . -type d -empty`、`rg` 建第一版地图：\n\n- entrypoints：CLI\u002Fserver\u002Fworker\u002Fdaemon\u002Fweb。\n- state stores：DB、files、cache、memory、lockfile、config。\n- extension points：plugin\u002Fprovider\u002Fadapter\u002Fregistry。\n- suspicious placeholders：空目录、TODO-only、docs-only 模块。\n- community signals：高赞 issue、roadmap、真实 bug\u002Ffeature 请求，验证宣传和用户痛点是否一致。\n\n### Step 2 — 明星特性逐个追链路\n\n每个 claim 单独拆：\n\n```text\nclaim -> public API\u002Fcommand -> entrypoint -> core module -> state mutation -> future behavior\n```\n\n如果 claim 说“self-improving \u002F learns \u002F evolves”，必须画：\n\n```text\nsignal -> decision -> state mutation -> future behavior\n```\n\n断一环，就只能写“有 UX\u002Ftelemetry\u002FCRUD”，不能写“闭环进化”。\n\n**scoped ledger 审计（性能\u002F成本类 claim 必做）**：宣称“节约 token \u002F 更快 \u002F 更省”的\nclaim，追完链路真实性后，还要重建**足以支持当前决定的边界账本**，而不是宣称掌握了\n“完整总账”：\n\n- 固定目标 workload、provider\u002Fmodel、版本、时间窗与 comparator；\n- 写清 numerator、denominator、排除项和 benchmark 是否被反复用于挑方案；\n- 分开统计 ingest\u002Fextract、query\u002Fretrieval、generation、cache write\u002Fread\u002Fmiss、维护和人审；\n- 并列报告 quality、coverage\u002Fabstention、latency、reliability、privacy\u002Frisk；\n- 未报告或无法复核的项写 `unknown`，不得用常识猜成 0。\n\nContext 变短可能减少输入，也可能改变可复用前缀和缓存经济性；结果取决于供应商规则、\nbreakpoint、请求序列和实际命中率。必须读取 usage\u002Fbilling 或做配对实验，不能把“中间\ncontext 变化”直接写成“cache 全 miss”或固定倍率。**claim 真实 ≠ 足以支持产品决定。**\n\n### Step 3 — 算法剥皮\n\n把被宣传成“算法”的点分栏：真算法 \u002F LLM judge \u002F 启发式 \u002F 规则 \u002F 外部服务。\n\n硬规则：\n\n- LLM prompt judge 不是算法，除非有独立 eval、score、threshold、rollback。\n- Hash update 不是知识过期。\n- Usage dashboard 不是生命周期治理。\n- Reward 只说明 reward 覆盖的任务类型，不自动证明开放任务能力。\n\n### Step 4 — 反馈链和评价主体\n\n检查谁在判断“更好”：\n\n| 任务类型 | 可接受评价主体 |\n|----------|----------------|\n| 客观任务：测试、编译、错误修复 | 机器\u002FCI\u002Feval |\n| 专业任务：架构、review、审美、产品判断 | 对口专家\u002Fpeer review |\n| 主观\u002F愿景任务：PPT、品牌、方向选择 | operator\u002F用户明确反馈 |\n\n如果项目把三层都压给同一个模型自评，要明确写风险：它可能能沉淀步骤，但不能证明质量提升。\n\n### Step 5 — 和 Clowder AI 对比\n\n不要写“我们有\u002F没有”流水账。每个维度都写价值函数：\n\n- **Learn**：立刻值得学的工程手法。\n- **Gap**：我们承认缺口，需要立项或排优先级。\n- **Do Not Follow**：我们不做，并写清哲学理由。\n\n**按决策向量重新判适用性**：外部 SOTA \u002F benchmark 分数是它所测构念的证据，不是\n产品总效用，也不能因为不覆盖我们的病灶就贬成“只是线索”。先写清它实际测了什么，\n再映射到当前目标 workload 的决策向量：\n\n```text\nquality\u002Fcorrectness | coverage\u002Fabstention | lifecycle cost | latency\nreliability | operability | privacy\u002Frisk\n```\n\n用约束或 Pareto frontier 做 Learn \u002F Gap \u002F Do Not Follow 判断（例如“污染率不超 ε 时\n最大化 coverage”）。不同量纲不得直接相乘成一个“猫咖总 loss”；只有 operator 明确给出\n权重、单位换算和决策场景时，才允许生成标量总分。若 benchmark 与目标只部分重合，\n写 `partial` 和未覆盖维度，不得写“高分证明产品强”或“与我们正交所以分数无效”。\n\n### Step 6 — 沉淀\n\n1. 把候选 lesson 写进报告，不直接改全局 lesson，等operator确认。\n2. 如果形成稳定方法论，更新本 skill 或相关 skill。\n3. docs 产物 commit + push；如果是新 skill，还要跑 `pnpm check:skills` 和 `pnpm sync:skills`。\n\n## Common Mistakes\n\n| 错误 | 后果 | 修正 |\n|------|------|------|\n| 只看 README\u002FPPT 就下结论 | 被营销话术带跑 | 每个 claim 必须有代码路径 |\n| 把“有命令\u002F有 UI”当成“有闭环” | 误判能力成熟度 | 追到 state mutation 和 future behavior |\n| 把 LLM judge 当算法 | 高估系统可验证性 | 算法表强制分栏 |\n| 把 hash update 当 stale | 混淆上游版本和知识失效 | 分开写 package update \u002F knowledge stale |\n| 把 telemetry 当治理 | `last_used_at` 被过度解读 | 看它是否进入排序\u002F淘汰\u002F晋升 |\n| 只看源码不看社区 | 错过用户真实痛点和官方 roadmap | 查高赞 issue \u002F bug \u002F enhancement |\n| 用”我们没有”替代 tradeoff \u002F 用”对方有”误报为”对方强” | 把设计选择误报成缺口 \u002F 接口齐全度误读为质量 | 写清价值函数 + 用户视角第一性原理（refs\u002Fuser-mind-evaluation.md）|\n| 把不同量纲乘成“总 loss” | 权重和单位被藏进公式，结论任意 | 保留决策向量；有明确权重和场景才标量化 |\n| 把缓存风险写成固定倍率 | provider \u002F model \u002F workload 一换就失真 | 读 usage\u002Fbilling，报告 cache read\u002Fwrite\u002Fmiss 与请求序列 |\n| 把“不覆盖我们的病灶”写成“benchmark 无效” | 否定了它在原测量构念上的证据价值 | 分开写 source validity 与 decision fit |\n| 一只猫写完不找 review | 方法论未经挑战 | skill\u002Freport 交对口猫 review |\n\n## 和其他 Skill 的区别\n\n- `deep-research`：多源资料调研；本 skill 是**源码优先的能力审计**。\n- `opensource-ops`：社区 issue\u002FPR\u002Fintake；本 skill 是**项目架构和宣传真实性拆解**。\n- `expert-panel`：多猫观点碰撞；本 skill 是**固定产物和检查项**。\n- `writing-skills`：写 skill 的质量纪律；本 skill 可产出候选 skill，但写入时仍要加载 `writing-skills`。\n\n下一步：工程\u002F产品决策 → `collaborative-thinking` 或 `feat-lifecycle`；新 skill\u002F修改 skill → `writing-skills`；外部社区情报 → `deep-research` 或 `opensource-ops`。\n","# Open Source Teardown\n\n明星项目拆解不是“读 README 做竞品分析”，而是**宣传 claim → 源码证据 → 能力边界 → 我们的 tradeoff** 的审计流程。\n\n## When to Use\n\n触发：operator看到 PPT、博客、README、社区讨论后问“这个项目是不是很强？”；需要拆解 agent runtime、skill 系统、memory\u002FRAG、MCP\u002Fgateway、RL\u002Feval、插件架构等工程系统；或需要把一次竞品分析沉淀为 lesson \u002F ADR \u002F skill。\n\n排除：只需要查公开资料或论文综述用 `deep-research`；只需要处理外部 issue\u002FPR\u002Fintake 用 `opensource-ops`；还没有明确目标项目、只是在讨论方向用 `collaborative-thinking`。\n\n灰例：如果用户同时要求“查社区 issue 情报 + 读源码”，先用本 skill 建代码证据骨架，再按需补 `deep-research` 或 `opensource-ops`。\n\n## Required Output\n\n默认落盘：`feature-discussions\u002FYYYY-MM-DD-{project}-deep-dive\u002F`，包含 README、architecture-map、明星特性深挖、comparison、lessons\u002Fnext steps。\n\n最小合格产物必须包含：\n\n- source repo URL、local path、commit SHA、更新时间。\n- 宣传 claims ledger：claim \u002F evidence files \u002F Source verdict \u002F Decision fit \u002F unknowns。\n- 架构图或模块地图：entrypoints、state stores、extension points、empty dirs；用 ASCII tree 或 Mermaid，参考 *(internal reference removed)*。\n- 明星特性深挖：每个特性都写到代码路径和运行链路。\n- 算法剥皮表：真算法 \u002F LLM judge \u002F 启发式 \u002F 规则 \u002F 外部服务。\n- Clowder AI 对比：能学、不能学、我们因为 tradeoff 不 follow 的理由。\n\n报告模板见 [refs\u002Freport-template.md](refs\u002Freport-template.md)；八审计镜头 + 命令见 [refs\u002Fteardown-method.md](refs\u002Fteardown-method.md)；用户视角第一性原理（第 9 镜头）见 [refs\u002Fuser-mind-evaluation.md](refs\u002Fuser-mind-evaluation.md)。\n\n## 进度纪律\n\n- **分次推进**：每只猫每次只做 1-2 份产物，commit 后传球，不一气呵成。\n- **双视角交叉**：架构\u002F明星特性\u002F合流\u002Fskill draft 至少跨两只猫完成。\n- **对口 review**：最终报告或 skill draft 必须由非作者猫 review，跨族优先。\n\n### Step 0 — 定边界和真相源\n\n1. 记录用户原始问题和最关心的 claims。\n2. `search_evidence` 查我们是否已有同项目\u002F同类系统讨论、lesson、feature anchor；有矛盾就 flag。\n3. clone 或 update 到 `\u002Fhome\u002Fuser\u002Fprojects\u002Fref\u002F{project}`。\n4. 记录 `git rev-parse HEAD`、最新 tag\u002Frelease、`git status --short`。\n5. 把 README\u002FPPT\u002F官网中的明星特性拆成 claims ledger。\n\n不要先评价。先把“它声称自己有什么”列成可验证对象。\n\n### Step 1 — 架构地图\n\n用 `git ls-files`、`find . -type d -empty`、`rg` 建第一版地图：\n\n- entrypoints：CLI\u002Fserver\u002Fworker\u002Fdaemon\u002Fweb。\n- state stores：DB、files、cache、memory、lockfile、config。\n- extension points：plugin\u002Fprovider\u002Fadapter\u002Fregistry。\n- suspicious placeholders：空目录、TODO-only、docs-only 模块。\n- community signals：高赞 issue、roadmap、真实 bug\u002Ffeature 请求，验证宣传和用户痛点是否一致。\n\n### Step 2 — 明星特性逐个追链路\n\n每个 claim 单独拆：\n\n```text\nclaim -> public API\u002Fcommand -> entrypoint -> core module -> state mutation -> future behavior\n```\n\n如果 claim 说“self-improving \u002F learns \u002F evolves”，必须画：\n\n```text\nsignal -> decision -> state mutation -> future behavior\n```\n\n断一环，就只能写“有 UX\u002Ftelemetry\u002FCRUD”，不能写“闭环进化”。\n\n**scoped ledger 审计（性能\u002F成本类 claim 必做）**：宣称“节约 token \u002F 更快 \u002F 更省”的\nclaim，追完链路真实性后，还要重建**足以支持当前决定的边界账本**，而不是宣称掌握了\n“完整总账”：\n\n- 固定目标 workload、provider\u002Fmodel、版本、时间窗与 comparator；\n- 写清 numerator、denominator、排除项和 benchmark 是否被反复用于挑方案；\n- 分开统计 ingest\u002Fextract、query\u002Fretrieval、generation、cache write\u002Fread\u002Fmiss、维护和人审；\n- 并列报告 quality、coverage\u002Fabstention、latency、reliability、privacy\u002Frisk；\n- 未报告或无法复核的项写 `unknown`，不得用常识猜成 0。\n\nContext 变短可能减少输入，也可能改变可复用前缀和缓存经济性；结果取决于供应商规则、\nbreakpoint、请求序列和实际命中率。必须读取 usage\u002Fbilling 或做配对实验，不能把“中间\ncontext 变化”直接写成“cache 全 miss”或固定倍率。**claim 真实 ≠ 足以支持产品决定。**\n\n### Step 3 — 算法剥皮\n\n把被宣传成“算法”的点分栏：真算法 \u002F LLM judge \u002F 启发式 \u002F 规则 \u002F 外部服务。\n\n硬规则：\n\n- LLM prompt judge 不是算法，除非有独立 eval、score、threshold、rollback。\n- Hash update 不是知识过期。\n- Usage dashboard 不是生命周期治理。\n- Reward 只说明 reward 覆盖的任务类型，不自动证明开放任务能力。\n\n### Step 4 — 反馈链和评价主体\n\n检查谁在判断“更好”：\n\n| 任务类型 | 可接受评价主体 |\n|----------|----------------|\n| 客观任务：测试、编译、错误修复 | 机器\u002FCI\u002Feval |\n| 专业任务：架构、review、审美、产品判断 | 对口专家\u002Fpeer review |\n| 主观\u002F愿景任务：PPT、品牌、方向选择 | operator\u002F用户明确反馈 |\n\n如果项目把三层都压给同一个模型自评，要明确写风险：它可能能沉淀步骤，但不能证明质量提升。\n\n### Step 5 — 和 Clowder AI 对比\n\n不要写“我们有\u002F没有”流水账。每个维度都写价值函数：\n\n- **Learn**：立刻值得学的工程手法。\n- **Gap**：我们承认缺口，需要立项或排优先级。\n- **Do Not Follow**：我们不做，并写清哲学理由。\n\n**按决策向量重新判适用性**：外部 SOTA \u002F benchmark 分数是它所测构念的证据，不是\n产品总效用，也不能因为不覆盖我们的病灶就贬成“只是线索”。先写清它实际测了什么，\n再映射到当前目标 workload 的决策向量：\n\n```text\nquality\u002Fcorrectness | coverage\u002Fabstention | lifecycle cost | latency\nreliability | operability | privacy\u002Frisk\n```\n\n用约束或 Pareto frontier 做 Learn \u002F Gap \u002F Do Not Follow 判断（例如“污染率不超 ε 时\n最大化 coverage”）。不同量纲不得直接相乘成一个“猫咖总 loss”；只有 operator 明确给出\n权重、单位换算和决策场景时，才允许生成标量总分。若 benchmark 与目标只部分重合，\n写 `partial` 和未覆盖维度，不得写“高分证明产品强”或“与我们正交所以分数无效”。\n\n### Step 6 — 沉淀\n\n1. 把候选 lesson 写进报告，不直接改全局 lesson，等operator确认。\n2. 如果形成稳定方法论，更新本 skill 或相关 skill。\n3. docs 产物 commit + push；如果是新 skill，还要跑 `pnpm check:skills` 和 `pnpm sync:skills`。\n\n## Common Mistakes\n\n| 错误 | 后果 | 修正 |\n|------|------|------|\n| 只看 README\u002FPPT 就下结论 | 被营销话术带跑 | 每个 claim 必须有代码路径 |\n| 把“有命令\u002F有 UI”当成“有闭环” | 误判能力成熟度 | 追到 state mutation 和 future behavior |\n| 把 LLM judge 当算法 | 高估系统可验证性 | 算法表强制分栏 |\n| 把 hash update 当 stale | 混淆上游版本和知识失效 | 分开写 package update \u002F knowledge stale |\n| 把 telemetry 当治理 | `last_used_at` 被过度解读 | 看它是否进入排序\u002F淘汰\u002F晋升 |\n| 只看源码不看社区 | 错过用户真实痛点和官方 roadmap | 查高赞 issue \u002F bug \u002F enhancement |\n| 用”我们没有”替代 tradeoff \u002F 用”对方有”误报为”对方强” | 把设计选择误报成缺口 \u002F 接口齐全度误读为质量 | 写清价值函数 + 用户视角第一性原理（refs\u002Fuser-mind-evaluation.md）|\n| 把不同量纲乘成“总 loss” | 权重和单位被藏进公式，结论任意 | 保留决策向量；有明确权重和场景才标量化 |\n| 把缓存风险写成固定倍率 | provider \u002F model \u002F workload 一换就失真 | 读 usage\u002Fbilling，报告 cache read\u002Fwrite\u002Fmiss 与请求序列 |\n| 把“不覆盖我们的病灶”写成“benchmark 无效” | 否定了它在原测量构念上的证据价值 | 分开写 source validity 与 decision fit |\n| 一只猫写完不找 review | 方法论未经挑战 | skill\u002Freport 交对口猫 review |\n\n## 和其他 Skill 的区别\n\n- `deep-research`：多源资料调研；本 skill 是**源码优先的能力审计**。\n- `opensource-ops`：社区 issue\u002FPR\u002Fintake；本 skill 是**项目架构和宣传真实性拆解**。\n- `expert-panel`：多猫观点碰撞；本 skill 是**固定产物和检查项**。\n- `writing-skills`：写 skill 的质量纪律；本 skill 可产出候选 skill，但写入时仍要加载 `writing-skills`。\n\n下一步：工程\u002F产品决策 → `collaborative-thinking` 或 `feat-lifecycle`；新 skill\u002F修改 skill → `writing-skills`；外部社区情报 → `deep-research` 或 `opensource-ops`。\n",{"name":5,"triggers":24,"description":37,"tips_exempt":38},[25,26,27,28,29,30,31,32,33,34,35,36],"拆解明星开源项目","拆解开源项目","竞品拆解","热门 GitHub 项目","它有什么真本事","我们能学什么","marketing vs reality","算法含量","拆解 hermes","看看 letta 怎么做的","codex cli 源码","agent runtime 拆解","明星开源项目拆解：从宣传\u002FPPT\u002FREADME 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent\u002Fruntime、外部 skill\u002Ftool 框架，或问“它到底有什么真本事\u002F我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue\u002FPR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions\u002FYYYY-MM-DD-{project}-deep-dive\u002F 下的代码证据报告 + 对比结论 + 候选 lesson\u002Fskill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。\n","Existing teardown quality contract refinement; no new user-facing capability or discovery moment.","main","e43f83d5ceb309323cae7e0f31e5e48fd816a57d",".claude\u002Fskills\u002Fopen-source-teardown","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI","https:\u002F\u002Fgithub.com\u002Fpeps1666","https:\u002F\u002Fwww.cug.edu.cn\u002F","My name is Zhou Junhao, and I am from China University of Geosciences (Wuhan). My major is Resources and Environment, and my research direction is Remote Sensin","2026-08-16 00:25:38",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add peps1666\u002FBuildCrew-AI --skill open-source-teardown",{"tool":53,"command":54},"bunx","bunx skills add peps1666\u002FBuildCrew-AI --skill open-source-teardown",{"tool":56,"command":57},"pnpm","pnpm dlx skills add peps1666\u002FBuildCrew-AI --skill open-source-teardown","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopen-source-teardown\u002FSKILL.md",true,[61,67,71],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"refs\u002Freport-template.md","REFERENCE","参考文档",2507,"https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopen-source-teardown\u002Frefs\u002Freport-template.md",{"path":68,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":69,"sourceHtmlUrl":70},"refs\u002Fteardown-method.md",3587,"https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopen-source-teardown\u002Frefs\u002Fteardown-method.md",{"path":72,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":73,"sourceHtmlUrl":74},"refs\u002Fuser-mind-evaluation.md",9573,"https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopen-source-teardown\u002Frefs\u002Fuser-mind-evaluation.md",[76,82,89,96,103,110],{"skillNo":77,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7APYYSHV2SSSRV5Q15JWWPF","plugin-reconcile-skill","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fplugins\u002Ftest-reconcile-plugin-regr\u002Fskills\u002Fplugin-reconcile-skill\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7APYWAJ119TPF079F2AXWAS","weixin-mp","通过 Limb 体系操作微信公众号：发布文章、上传图片、管理草稿。 Use when: 需要发布内容到微信公众号、查看草稿、检查公众号连接状态。 Not for: 其他平台的发布、纯文本聊天、非公众号相关操作。 Output: 微信公众号操作结果（发布ID、草稿列表、图片URL等）。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fpackages\u002Fapi\u002Fsrc\u002Fplugins\u002Fweixin-mp\u002Fskills\u002Fweixin-mp\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M7APYNNEMBP2T62WT0JT7GNE","writing-skills","创建或修改 Clowder AI skill \u002F MCP tool description 的元技能（含质量标准、范本、发布）。 Use when: 写新 skill、修改现有 skill、写\u002F改 MCP tool description、验证 skill 质量； 或者功能实现中产出了 SKILL.md \u002F cat-cafe-skills\u002F 新目录 \u002F manifest.yaml skill 条目。 Not for: 使用 skill（直接触发对应 skill）。 Output: 新\u002F更新的 SKILL.md + manifest 条目 + symlinks。 GOTCHA: 软硬同重——skill\u002FMCP 质量 = 代码质量；不要写模型已知的通用教程，先过价值门禁。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fwriting-skills\u002FSKILL.md",[],[],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":19},"01M7APYHJDXRH9EDP5D3JZHSVN","writing-plans","将 spec\u002F需求拆分为可执行的分步实施计划。 Use when: 有 spec 或需求，准备动手前需要拆分步骤。 Not for: trivial 改动（≤5 行）、已有详细计划。 Output: 分步实施计划（含 TDD 步骤和检查点）。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":19},"01M7APYD2SSZ6Y6CF5SD3YZ5C0","worktree","为代码、脚本、API 与第一方执行面创建隔离 Git worktree，并配置 Redis 6398；classifier 放行的 co-creation docs direct push 不进入本流程。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fworktree\u002FSKILL.md",[],[],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":19},"01M7APY8R4E7RR2WZVPH9V8WWP","workspace-navigator","猫猫把“打开文档、代码或日志”等模糊意图解析成本地绝对路径或 worktree 相对路径，并返回 applied、queued、blocked 或 unconfirmed 的真实 Workspace 投递状态。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fworkspace-navigator\u002FSKILL.md",[],[]]