Github Absorb

GitHub 代码仓库全流程评估与吸收引擎

定位：不是"看看这个仓库"的信息检索——是从业务价值判断→吸收执行→测试验证→网格化引用→能力报告的完整闭环。覆盖 AI、数字化、咨询、企业管理、FDE 五大业务域。

设计哲学

1. 价值先行，不行即止 — 业务价值为负或无关 → 立即停止，不浪费后续步骤
2. 最小化可用 — 优先独立创建技能；只在强互补+高契合时才吸收到现有技能
3. 工具优先安装 — 仓库本身是完整可安装工具（CLI/桌面应用/MCP Server）时，优先独立安装使用，而非强行吸收为技能
4. 技能纯粹性 — 不把不同职责塞进同一个技能；代码仓库能力与现有技能边界清晰
5. 自动触发 — GitHub 链接出现即启动，不需用户重复说"评估一下"
6. 闭环交付 — 从评估到测试到报告，产出完整可追溯的强化记录

触发条件

自动触发（默认）

当消息中出现以下任一信号时自动启动 Phase 1：

• 包含 github.com 且看起来像仓库链接（/owner/repo 模式）
• 用户说"帮我看看这个仓库/项目"
• 用户说"这个项目怎么样/能不能用/值不值得"
• 用户说"吸收/引入/用这个仓库"

不触发场景

• Gist 链接（gist.github.com）
• GitHub 非仓库页面（Issues/PRs/Discussions/profile）
• 用户只是提了一嘴 GitHub 作为上下文但没要求评估
• 纯代码片段引用（如"参考 github.com/xxx/blob/main/src/yyy.py 的写法"）

全局工作流（八阶段）

Phase 1 → Phase 2 → Phase 3 (Gate) → Phase 4 → Phase 5 → Phase 6 → Phase 7 → Phase 8
 触发      深度      价值判断       吸收策略    执行吸收   网格引用   测试验证   强化报告
 检测      分析      (停/续)        分类       创建技能   更新关联   双轨测试   最终交付

评估模式选择

快速评估模式（Quick Assessment）

当用户的问题是"这个仓库怎么样"、"是否适用于X"、"能不能用于Y场景"等评估性问题，而非"吸收这个仓库"、"创建技能"等执行性指令时，使用快速评估模式：

快速评估输出格式：

## {repo_name} 评估结论

**核心定位**：一句话说明仓库是什么
**业务域评分**：AI={X} 数字化={X} 咨询={X} 企业管理={X} FDE={X}
**适用场景**：✅ 适合 / ❌ 不适合 / ⚠️ 有限适用
**关键发现**：2-3 条核心洞察
**建议**：是否值得深入评估或直接吸收

快速评估仍需完成 Phase 1-3 的全部分析步骤（URL解析、README深度阅读、业务域评分），只是跳过 Phase 4-8 的执行环节。如果快速评估结果为正面（max评分≥3），主动询问用户是否需要进入完整吸收流程。

Phase 1: 触发检测与仓库定位

Step 1.1: 解析 GitHub URL

从用户消息中提取：

https://github.com/{owner}/{repo}

若用户给了非标准格式（如 owner/repo），补全为 https://github.com/{owner}/{repo}。

Step 1.2: 确认评估意图

若 URL 出现但意图不明确（如"你看过 github.com/xxx 吗"），追问确认：

你是想让我评估这个仓库对当前业务的价值吗？还是只是想了解这个项目是做什么的？

Step 1.3: 获取仓库元信息

# 仓库基本信息
curl -s https://api.github.com/repos/{owner}/{repo} | python3 -c "
import sys,json
r=json.load(sys.stdin)
print(f'Stars: {r.get(\"stargazers_count\",\"?\")}')
print(f'Forks: {r.get(\"forks_count\",\"?\")}')
print(f'Language: {r.get(\"language\",\"?\")}')
print(f'Topics: {\", \".join(r.get(\"topics\",[]))}')
print(f'Description: {r.get(\"description\",\"?\")}')
print(f'License: {r.get(\"license\",{}).get(\"spdx_id\",\"?\") if r.get(\"license\") else \"?\"}')
print(f'Last push: {r.get(\"pushed_at\",\"?\")}')
print(f'Archived: {r.get(\"archived\",False)}')
"

Phase 2: 深度分析

Step 2.1: 读取文档层

按优先级读取：

1. README.md — 项目定位、核心功能、快速开始
2. CHANGELOG.md / RELEASE_NOTES — 版本演进、稳定性判断
3. CONTRIBUTING.md / ARCHITECTURE.md — 架构设计、贡献指南
4. docs/ 目录 — 详细文档
5. examples/ 目录 — 使用示例

优先使用 web_extract(urls=["https://raw.githubusercontent.com/{owner}/{repo}/main/README.md"]) 或 curl 分块读取。

⚠️ 文档读取超时是常态：web_extract 对大仓库 README 经常 60s 超时（如 AnythingLLM、LangChain 等 60K+ stars 项目），官方 docs 站点也常因 JS 渲染而超时。超时后不要反复重试同一工具——直接 git clone --depth 1 读本地文件（read_file /tmp/{repo}/README.md）。这个 fallback 对 README / CHANGELOG / docs / openapi.json 等所有文档读取都适用。

Step 2.1b: 读取配套文章/博客（如有）

当用户同时提供了仓库的配套文章链接（微信公众号 mp.weixin.qq.com、Medium、博客等），这些文章通常包含作者的完整设计思路和哲学背景，是评估仓库价值的高信号信息源。

微信文章访问：browser_navigate 直接访问微信文章通常超时或返回空白。必须使用 CDP 浏览器：

1. 确保 Windows Chrome CDP 已连接（加载 wsl-browser-cdp 按流程启动）
2. browser_navigate(url="微信文章URL") 打开页面
3. 页面加载后，用 browser_console 提取正文：

// 微信文章正文在 #js_content 容器中
document.querySelector('#js_content') ? 
  document.querySelector('#js_content').innerText : 
  document.body.innerText

browser_snapshot 会截断长文（~2000行），优先用 browser_console 直接提取全文。

提取后，将文章内容作为 Phase 2 分析的一部分，重点关注：

• 作者的设计哲学和核心洞察
• 与 README 互补的实现细节
• 无法从代码中直接读出的决策背景

Step 2.2: 分析目录结构 → API 限流检测

curl -s https://api.github.com/repos/{owner}/{repo}/contents/ | python3 -c "
import sys,json
for i in json.load(sys.stdin):
    print(f'{i[\"type\"]:5s} {i[\"name\"]}')
"

⚠️ API Rate Limit 降级：如果 GitHub API 或 raw.githubusercontent.com 返回 429/403，不要反复重试。立即 fallback 到浅克隆：

cd /tmp && rm -rf {repo} && git clone --depth 1 https://github.com/{owner}/{repo}.git 2>&1

克隆后所有文件读取改用 read_file 直接读本地文件（/tmp/{repo}/...）。这比等待 rate limit 恢复更快、更可靠。

Step 2.2b: 技能市场仓库检测

当目录结构分析发现 skills/ 目录包含多个以技能命名的子目录（如 brainstorming/、test-driven-development/），且每个子目录包含 SKILL.md 文件时，该仓库是 Agent 技能市场/方法论仓库。此时切换评估模式：

检测命令（克隆后在本地执行）：

ls /tmp/{repo}/skills/ | head -20  # 子目录列表
grep -l '^name:' /tmp/{repo}/skills/*/SKILL.md  # 验证技能文件

切换后：

1. 跳过 Step 2.3（pygount 代码分析）——仓库主体是 Markdown，非代码
2. 跳过 Step 2.4（代码文档质量评估）——技能仓库的文档标准不同
3. 替代分析：逐技能读取 SKILL.md，按 name: / description: frontmatter 提取核心能力清单
4. 检查插件架构：阅读 .claude-plugin/、.codex-plugin/、hooks/ 等目录了解跨平台分发机制
5. 优先读取元技能：读取 skills/using-{repo-name}/SKILL.md（如 using-superpowers/SKILL.md）——这是技能体系的引导入口，揭示了其设计哲学和技能间编排逻辑

案例：obra/superpowers 即典型的技能市场仓库（14 个技能 + 多平台插件架构）。评估重点从"代码质量"转向"方法论完整度"和"技能间协同编排"。

Step 2.2b: 技能仓库检测

当目录结构分析发现 skills/ 目录包含多个以技能命名的子目录（如 brainstorming/、test-driven-development/），且每个子目录包含 SKILL.md 文件时，该仓库是 Agent 技能市场/方法论仓库，而非传统代码仓库。此时需要切换评估模式：

检测信号：

# 列出 skills/ 下的技能目录
curl -s https://api.github.com/repos/{owner}/{repo}/contents/skills | python3 -c "
import sys,json
items=json.load(sys.stdin)
skills=[i['name'] for i in items if i['type']=='dir']
print(f'Skills count: {len(skills)}')
for s in skills: print(f'  - {s}')
"

切换到技能仓库评估模式后：

1. 跳过 Step 2.3（pygount 代码分析）——无意义（仓库主体是 Markdown）
2. 跳过 Step 2.4（代码文档质量）——技能仓库的文档标准不同
3. 替代分析：逐技能读取 SKILL.md，按 name: / description: frontmatter 提取核心能力清单
4. 检查插件架构：阅读 .claude-plugin/、.codex-plugin/、hooks/ 等目录，了解跨平台分发机制
5. 读取元技能：优先读取 using-{repo-name}/SKILL.md（如 using-superpowers/SKILL.md）——这是技能体系的引导入口

案例：obra/superpowers 即典型的技能市场仓库（14 个技能 + 插件架构）。评估重点从"代码质量"转向"方法论完整度"和"技能间协同关系"。

Step 2.3: 代码规模与语言分析

使用 codebase-inspection 技能的方法：

# 浅克隆（加速）
git clone --depth 1 https://github.com/{owner}/{repo}.git /tmp/{repo} 2>&1

# 语言/规模分析
pygount --format=summary \
  --folders-to-skip=".git,node_modules,venv,.venv,__pycache__,dist,build" \
  /tmp/{repo} 2>/dev/null

若仓库过大（>100MB 或 clone 超时 60s），跳过全量代码分析，仅基于文档层判断。

Step 2.4: 代码文档质量评估

检查以下信号：

• 是否有 docstring/注释（搜索 def + 下一行是否含 """）
• 是否有类型标注（Python .py 文件搜索 : str / -> 等模式）
• 是否有测试文件（test_*.py / *_test.go / *.spec.ts 等）
• 是否有 CI/CD 配置（.github/workflows/ / .gitlab-ci.yml 等）

Step 2.5: 业务域映射

核心判断：这个仓库解决什么问题？与当前五大业务域的关系？

每个域打分（0-5）：

• 0：完全无关
• 1-2：有弱关联，但不能直接用于业务
• 3：中等关联，可借鉴思想或部分组件
• 4：强关联，可直接用于核心业务场景
• 5：极强关联，填补关键能力空白

Phase 3: 价值判断门禁（Gate）

决策逻辑

if max(业务域评分) < 2:
    → 🛑 停止。输出"业务相关性不足"简要报告，不进入后续阶段。

if max(业务域评分) >= 3:
    → ✅ 继续。进入 Phase 4 吸收策略。

# 特殊：工具本身可作为独立软件安装使用（非吸收到技能库）
if 仓库是完整可安装工具（CLI/桌面应用/MCP Server/库）且 max(业务域评分) >= 2:
    → ✅ 继续。标记 📦 独立安装，不因低技能吸收价值而跳过。

门禁判断需考虑的负面信号

Phase 3 后高频追问（正面评估的延续）

当 Phase 3 门禁通过且用户给出正面信号后，用户常会追问以下三类问题而不等 Phase 4 吸收流程。这些追问不需重跑整个评估管线，直接基于已收集的信息回答：

回答风格：直接给结论 + 具体命令 + 集成拓扑，不套用 Phased 工作流模板。这些是实操问题，不是方法论评估。

Phase 4: 吸收策略分类

基于 Phase 2 的深度分析，对仓库进行能力拆解和分类标注。

Step 4.0: 现有技能重叠检查 🔴 CHECKPOINT

在拆解能力单元之前，必须先检查源仓库的技能与 Hermes 现有技能的命名重叠和功能重叠：

# 扫描源仓库技能名列表
for d in /tmp/{repo}/skills/*/; do
  name=$(grep '^name:' "$d/SKILL.md" 2>/dev/null | head -1 | sed 's/name: *//')
  [ -n "$name" ] && echo "$name"
done | sort > /tmp/source-skills.txt

# 与 Hermes 现有技能逐个比对
while read skill; do
  found=$(find ~/.hermes/skills -maxdepth 3 -name "SKILL.md" -exec grep -l "name: $skill" {} \; 2>/dev/null)
  if [ -n "$found" ]; then
    echo "✅ OVERLAP: $skill → $(echo "$found" | head -1)"
  else
    echo "❌ NEW: $skill (not in Hermes)"
  fi
done < /tmp/source-skills.txt

重叠分类：

注意：同名不代表质量相同。Phase 2 已读取双方 SKILL.md，此时应对比：

• 行数/字节量 → 初步判断内容丰富度
• references/ 配套文件数 → 判断支撑材料密度
• 是否有 Iron Law / HARD-GATE 模式 → 判断方法论成熟度

若源仓库的技能显著更丰富（配套文件 3+ 个 / SKILL.md 行数高出 50%+），即使同名也标注 🔵 吸收增强。

Step 4.0: 现有技能重叠检查 🔴 CHECKPOINT

在拆解能力单元之前，必须先检查源仓库的技能与 Hermes 现有技能的命名重叠和功能重叠。这在技能市场仓库评估中尤其重要——你可能已经有同名技能了：

# 扫描源仓库技能名清单（克隆后在本地执行）
for d in /tmp/{repo}/skills/*/; do
  name=$(grep '^name:' "$d/SKILL.md" 2>/dev/null | head -1 | sed 's/name: *//')
  [ -n "$name" ] && echo "$name"
done | sort > /tmp/source-skills.txt

# 与 Hermes 现有技能逐个比对
while read skill; do
  found=$(find ~/.hermes/skills -maxdepth 3 -name "SKILL.md" -exec grep -l "name: $skill" {} \; 2>/dev/null)
  if [ -n "$found" ]; then
    echo "✅ OVERLAP: $skill → $(echo "$found" | head -1)"
  else
    echo "❌ NEW: $skill (not in Hermes)"
  fi
done < /tmp/source-skills.txt

重叠分类与处理：

注意：同名不代表同质。Phase 2 已读取双方 SKILL.md，此时应做质量对比：

• 行数/字节量对比 → 初步判断内容丰富度
• references/ 配套文件数对比 → 判断支撑材料密度
• 是否有 Iron Law / HARD-GATE / Red Flags 模式 → 判断方法论成熟度
• 是否有跨技能引用和编排逻辑 → 判断体系完整度

若源仓库的技能显著更丰富（配套文件 3+ 个，或 SKILL.md 行数高出 50%+），即使同名也标注 🔵 吸收增强，而非 🟡 跳过。

案例：超级力量仓库的 subagent-driven-development 在 Hermes 中已有同名技能（379 行 vs 418 行 + 2 个 reviewer prompt），差距不足以触发替换，但配套 prompts 值得迁移——标注 🔵 增强。

能力拆解

不是整个仓库作为一个整体吸收。先拆成独立的能力单元：

仓库 {owner}/{repo}
├── 能力单元 1: [核心算法/方法]
├── 能力单元 2: [工具/CLI]
├── 能力单元 3: [框架/库]
├── 能力单元 4: [设计模式/架构]
└── 能力单元 N: [文档/知识]

五类分类法

逐能力单元标注吸收类别：

吸收优先级

用户决策点 🔴 CHECKPOINT

展示吸收策略矩阵，等待用户确认后才进入 Phase 5：

┌──────────────────────────────────────────────────────────┐
│              吸收策略决策矩阵                               │
├────────────────┬──────┬──────┬──────────┬─────────────────┤
│ 能力单元        │ 分类  │ 优先级 │ 吸收方式   │ 目标技能         │
├────────────────┼──────┼──────┼──────────┼─────────────────┤
│ 工具CLI        │ 📦   │ P0   │ 独立安装   │ brew/npm install  │
│ 核心算法        │ 🟢   │ P0   │ 独立创建   │ [新技能名]       │
│ 工具CLI        │ 🔵   │ P1   │ 吸收增强   │ [现有技能名]     │
│ 设计模式        │ 🟡   │ P3   │ 仅记录    │ —               │
└────────────────┴──────┴──────┴──────────┴─────────────────┘

是否按以上策略执行吸收？（可选择调整分类/优先级）

Phase 5: 执行吸收

5A: 独立创建技能

根据以下标准创建 Hermes 技能：

技能结构要求

~/.hermes-feishu/skills/{category}/{skill-name}/
├── SKILL.md              # 核心：触发条件 + 执行流程 + 反例
├── references/           # 参考文件（方法论、模板、案例）
├── scripts/              # 可执行脚本
└── templates/            # 输出模板

SKILL.md 写作标准

• name: 英文小写+连字符，≤64字符
• description: 必须包含"做什么 + 何时用 + 触发词"，≤1024字符
• triggers: 至少 3 个中文触发词
• 执行流程: 编号步骤，每步有明确输入/输出
• 失败模式: 显式编码 if-失败-→ fallback
• 检查点: 关键决策前用 🔴 CHECKPOINT
• 反例: "不要做什么"的独立章节

触发机制设计

确保技能可通过以下方式触发：

1. 关键词自动触发 — 在 description 中声明 ≥ 3 个中文触发词
2. 上下文语义触发 — 触发词覆盖核心场景的不同表述
3. 关联触发 — 若该技能与现有技能强相关，在 existing skill 的 related_skills 中添加

创建完成后立即用 darwin-skill 的 L1 静态检查验证：

# 基本结构检查
grep -c "^## " SKILL.md  # 至少 3 个二级标题
grep -c "🔴 CHECKPOINT" SKILL.md  # 至少 1 个检查点
grep -c "❌" SKILL.md  # 至少 1 个反例

吸收策略用户级 vs 项目级设计模式

当吸收的工具/方法论设计为「项目级安装」（如 npx ai-viz init 每个项目独立配置），但用户场景是多项目 + 统一偏好时，应遵循以下模式：

模式：用户级全局默认 + 项目级可选覆盖

Layer 1: 用户级默认（~/.hermes-feishu/）
  · 全局配置文件（如 design-language.yaml）
  · 所有技能共享此默认
  · 零摩擦——不需要任何项目级 setup

Layer 2: 项目级覆盖（可选）
  · 项目根目录放置同名配置文件
  · 技能检测到项目级配置 → 覆盖全局默认
  · 未检测到 → 使用全局默认

Layer 3: 对话级临时覆盖
  · 用户口头指定（如"配色用暗色主题"）
  · 仅本次对话有效，不污染文件

何时应用：

• 工具要求每个项目手动 init
• 用户的项目太多，手动 init 不现实
• 用户有稳定的全局偏好

反模式：为每个项目写适配器——适配器模式（Adapter Pattern）适用于不同接口的标准化，不适用于「同一接口的不同配置」。区别在于：适配器解决格式差异，本模式解决配置差异。

对 🔵 类能力单元，执行以下操作：

1. 定位注入点 — 确定目标技能的哪个 Phase/步骤可以增强
2. 提取核心方法论 — 从源仓库提取算法、模式、检查项
3. 本地化适配 — 转换为 Hermes 原生措辞和工具调用
4. 注入 — 用 skill_manage(action='patch') 精确插入新内容到 SKILL.md
5. 迁移配套文件 — 将源仓库技能目录中的支持文件复制到目标 Hermes 技能的 references/ 下
6. 更新元数据 — 在目标技能的 frontmatter 中：bump version、添加 source: 字段标注吸收来源
7. 记录来源 — 在目标技能正文末尾添加 > 吸收自: {repo_url} 引用标注

5B.1: SKILL.md 注入

用 skill_manage(action='patch', file_path='SKILL.md') 精确插入新内容。原则：

• 只加内容，不改原有核心逻辑
• 新增内容放在对应 Phase 的末尾（不打断现有流程）
• 保持原有技能的结构和命名风格

5B.2: References 文件迁移（模式）

当源仓库技能包含独立的支持文件（如 reviewer prompts、anti-patterns 文档、技术参考手册），将其复制到目标 Hermes 技能的 references/ 目录：

# 批量迁移 references 文件
SRC=/tmp/{repo}/skills/{source-skill}
DST=~/.hermes/skills/{target-skill}/references
mkdir -p "$DST"

# 复制所有非 SKILL.md 的支持文件
for f in "$SRC"/*.md "$SRC"/references/*.md; do
  [ -f "$f" ] && cp "$f" "$DST/$(basename "$f")"
done

适用场景：

• implementer-prompt.md / task-reviewer-prompt.md → 子代理调用的独立 prompt 模板
• code-reviewer.md → 代码审查的详细检查清单
• testing-anti-patterns.md → TDD 反模式参考手册
• root-cause-tracing.md / defense-in-depth.md → 调试技术深度文档
• plan-document-reviewer-prompt.md → 计划文档审查标准

迁移后验证：确认目标 SKILL.md 中已有或新增对 references 文件的引用句（一句即可）：

详见 `references/{filename}.md`。

不要迁移：

• ❌ 脚本文件（scripts/）——除非经过 Hermes 环境适配
• ❌ 测试文件——源仓库的测试框架与 Hermes 不兼容
• ❌ 平台特定配置（plugin.json, hooks.json）——Hermes 有独立触发机制

5B.3: 版本与来源标注

每次 🔵 吸收增强后，更新目标技能的 frontmatter：

# Before
name: systematic-debugging
version: 1.0.0
description: "..."

# After (bump MINOR version + add source)
name: systematic-debugging
version: 1.1.0
metadata:
  hermes:
    related_skills: [newly-discovered-deps]
  source: 增强自 https://github.com/{owner}/{repo} (v{X.Y.Z})

5B.4: 批量执行策略

当多个 🔵 增强涉及"纯文件复制 + 元数据更新"（无 SKILL.md 内容注入），可使用 terminal 批量操作；涉及 SKILL.md 内容改变时必须逐个 patch。典型执行顺序：

# Step 1: 批量复制 references 文件（terminal）
# Step 2: 逐个 patch frontmatter（skill_manage patch）
# Step 3: 如有 SKILL.md 正文注入，逐个 patch

案例：在超级力量吸收中，5 个 🔵 增强全部是"references 迁移 + frontmatter 更新"模式（无正文注入），仅 1 个（answer 设计门禁）需要实际内容注入。

Phase 6: 网格化引用网络

每次独立创建 / 吸收增强后，必须更新技能间的引用关系。

⚠️ 重要：不是所有反向引用都值得补。通用工具被调用、格式引用、方法论启发等场景不需要反向引用——盲目补全会制造假耦合。引用过滤标准见 references/filtering-criteria.md。

审计工具：scripts/audit-reference-network.py 可随时对本地+GitHub 双源执行全库引用网络健康检查。用法见底部「工具集」。

6A: 双向引用

# 新技能 → 关联技能
metadata:
  hermes:
    related_skills: [skill-a, skill-b, skill-c]

# 关联技能 → 新技能（反向引用）
# 在 skill-a 的 related_skills 中添加新技能名

6B: 引用指引生成与注入

related_skills 元数据只是索引——技能加载时并不会自动知道"什么时候该用"关联技能。必须为每个关联技能生成引用指引段落并注入到其 SKILL.md 正文中，实现"技能知道何时加载另一技能"。

引用指引格式

根据引用维度，为每个关联技能生成一段具体的指引：

指引编写要求

• 必须具体：不是"与 X 协同使用"，而是"当需要将评测结果转换为业务报告时，与 X 协同使用"
• 必须给出触发条件：让技能能自行判断"现在我该不该加载 X"
• 必须说明衔接方式：输入什么、期望得到什么、结果用在哪一步

注入位置

在目标技能的 SKILL.md 中查找以下章节（按优先级）：

1. ## 与其他技能的关系 → 在该章节末尾追加指引
2. ## 关联技能 → 在该章节末尾追加指引
3. 以上都不存在 → 在技能末尾新增 ## 关联技能指引 章节

注入方式

使用 skill_manage(action='patch', file_path='SKILL.md') 精确插入指引行，只追加、不改写。

注入内容示例

假设在 Phase 5A 独立创建了 skill-evaluator-extended 技能，它与 skill-evaluator 形成 upstream 关系（skill-evaluator 的输出可由新技能进一步处理）。对 skill-evaluator 注入：

## 关联技能指引

> 以下指引由 `github-absorb` Phase 6 自动生成，来源于 {repo_url}

- **upstream → `skill-evaluator-extended`**：本技能的三维评测结果可由 `skill-evaluator-extended` 进一步扩展为包含「业务适配度」的四维评测。当需要面向业务决策层输出评测报告时，先加载 `skill-evaluator-extended` 追加第四维度。

引用指引质量自检

每条指引注入前自问：

• 是否说明了什么场景下需要加载关联技能？（不能泛泛说"需要时使用"）
• 是否说明了衔接方式？（输入什么、期望输出什么）
• 是否使用了具体的技能名和阶段名？（不能只说"相关技能"）
• 技能是否无需上下文就能判断触发条件？（按 "if 用户说 X / 当前处于 Y 阶段" 来写）

6C: 执行清单

对每个新创建或增强的技能，逐项执行并确认：

• 新技能自身的 related_skills 元数据已填写（6A）
• 对每个关联技能，确定了引用类型（6B 维度）
• 对每个关联技能，编写了引用指引段落（6B 格式）
• 已将引用指引注入到每个关联技能的正文中（6B 注入）
• 对注入后的关联技能执行 L1 结构检查（结构未损坏）
• GitHub awesome-skills README 索引标记 TODO

5C: 独立安装与验证

对 📦 类能力单元，执行以下操作：

0. 安装类型识别（先判断再行动）：

• CLI / 库 / Docker 镜像 → 走步骤 1-5，全自动完成。
• Desktop GUI 安装器（.exe / .dmg / .AppImage）→ 下载到用户路径后停止自动化。告知用户手动完成 GUI 安装向导，原因：
  • SYSTEM 会话无法在用户桌面会话中创建可见窗口（Session 0 隔离）
  • UAC / 管理员密码弹窗运行在隔离的安全桌面，任何自动化工具（含 cua-driver）均无法交互
  • 安装器本身的 GUI 向导（"下一步"/"我同意"/"选择路径"）需要人类点击
  • 用户安装完成后回到自动化流程做后续配置（环境变量、LLM 接入、工作区创建等）

1. 确定安装方式 — 从 README/文档提取安装命令（brew/npm/pip/cargo/docker/二进制下载）
2. 执行安装 — 在本地环境执行安装（仅 CLI/Docker 类型）
3. 验证可用性 — 至少执行 3 项验证（仅 CLI/Docker 类型）：

• 版本号检查（--version 或等效）
• 基础命令验证（CLI --help 或 API 健康检查）
• 端到端功能验证（使用实际数据执行一个完整操作）

4. 记录环境约束 — 运行时依赖（Node/Bun/Python 版本）、平台限制、已知问题
5. 创建速查卡 — 记录到最终报告的工具信息表中

常见问题：运行时不匹配、端口不一致、MCP Accept 头、国内下载慢需代理直连、Docker Hub 被墙需镜像/代理、GUI 安装器无法自动化——详见 references/tool-install-pitfalls.md。

Phase 7: 测试验证

7A: 单元测试（能力和功能）

对每个新创建或增强的技能：

L1 静态合规（自动）

# SKILL.md 结构完整性
- [ ] name/description/version 完整
- [ ] trigger 列表 ≥ 3 个
- [ ] 执行流程有编号步骤
- [ ] 至少 1 个 🔴 CHECKPOINT
- [ ] 至少 1 个反例章节
- [ ] references/ 中引用的文件全部存在
- [ ] scripts/ 中 .py/.sh 文件语法正确

L2 功能测试（手动/AI驱动）

# 对每个 trigger 信号，测试技能是否能正确触发
测试集:
  1. 典型触发场景（happy path）
  2. 边界场景（模糊/不全的触发信号）
  3. 负样本（不应触发的场景）

L3 吸收完整性检查

- [ ] 源仓库的核心能力是否完整提取
- [ ] 吸收后的技能是否可独立运行（不依赖源仓库）
- [ ] 是否有遗漏的关键方法/算法
- [ ] 文档中是否标注了原始来源

7B: 全业务链路测试

基于当前系统的实际功能与历史会话/记忆中的主要业务场景，构建端到端测试链：

链路定义

需求 → 转换 → 洞察 → 分析 → 校验 → 输出

测试场景生成

从以下来源提取测试场景：

1. 当前任务地图（从 SOUL.md 和当前会话）

   • 当前身份和业务域
   • 正在进行的项目
   • 记忆中的主要业务场景

2. 历史高频任务（从 session_search）

   • 搜索最近 1 个月的高频操作类型
   • 提取 3-5 个典型端到端场景

3. 技能依赖链（从技能 related_skills 图）

   • 找出涉及新技能的最长调用链
   • 测试链上每个节点的输入输出兼容性

测试执行示例

假设新技能为 {new-skill}，测试链为：

场景: AI Agent 应用探讨
  demand  → 用户提出"帮我设计一个 Agent 架构"
  convert → {new-skill} 从 GitHub 仓库中提取 Agent 设计模式
  insight → {new-skill} 映射到当前业务（数字化/企业管理系统）
  analyze → cross-project-adaptation 分析适配成本
  verify  → skill-evaluator 验证产出质量
  output  → 生成架构方案文档

每个环节检查：

• 输入格式是否兼容下游
• 输出是否满足上游预期
• 是否有信息丢失或格式断裂
• 端到端耗时是否合理

多业务体系适配验证

确保新技能在以下业务体系中均可正常工作：

Phase 8: 能力强化报告

生成最终的结构化报告，包含以下全部内容：

报告模板

完整报告模板见 references/report-template.md。使用时替换所有 {placeholder} 为实际内容。报告包含七个章节：

1. 仓库概览 — 基本信息表
2. 业务价值评估 — 五大业务域评分
3. 吸收执行摘要 — 能力单元×分类矩阵
4. 创建/增强的技能 — 新技能详情 + 增强注入点
5. 引用网格 — ASCII 图 + 维度明细表
6. 测试结果 — 单元测试 + 全链路测试 + 多业务适配
7. 后续行动 — Checklist

反例（禁止）

• ❌ 不读完 README 就下结论 — 仓库价值在文档细节中
• ❌ 跳过业务域评分直接分类 — 业务价值是吸收决策的锚
• ❌ 把整个仓库作为一个整体吸收 — 必须拆成能力单元逐项评估
• ❌ 创建技能后不更新引用网格 — 孤立的技能就是死技能
• ❌ 跳过 Phase 7 测试 — 未测试的技能不可信
• ❌ 用户没有确认就执行 Phase 5 吸收 — 吸收决策必须人审
• ❌ 对低价值仓库继续执行后续阶段 — Phase 3 门禁必须严格执行
• ❌ 吸收时破坏原有技能结构 — 注入内容必须放在对应 Phase 末尾
• ❌ 不加判断地补全所有反向引用 — 通用工具被调用/格式引用/方法论启发等不需要反向引用，补了制造噪音和假耦合。过滤标准见 references/filtering-criteria.md
• ❌ 用户提出"更高维度评估"时仍用原策略矩阵回答 — 用户问"能不能改成Hermes""吸收后正负面影响""用户级vs项目级最优方案"等问题时，说明原策略矩阵不够，需要重新从范式/架构/能力边界三个维度审视。案例见 references/ai-viz-absorption-case.md

与其他技能的关系

• ❌ 不加判断地补全所有反向引用 — 通用工具被调用/格式引用/方法论启发等不需要反向引用，补了制造噪音和假耦合。过滤标准见 references/filtering-criteria.md

工具集

运行审计脚本：

python3 ~/.hermes-feishu/skills/methodology/github-absorb/scripts/audit-reference-network.py \
  /path/to/awesome-skills ~/.hermes-feishu/skills

异常与边界条件