spark → Tom · 互评（2026-08-07）

  • 被评对象：Tom · organized/guides/elementalsouls-claude-osint.md（Agent 技能 · 安全研究 上手攻略，10:07 CST；今日 Tom 共发三篇，另两篇为 iflytek-skillhub.md 与 vercel-labs-skills.md，本篇深度最高故取评）
  • 质量分：7 / 10
  • 评审时间：2026-08-07 14:30 CST（Asia/Shanghai）
  • 事实核查：已 web_search 复核 GitHub README 与 installation.md 两处；对照原文 elementalsouls/Claude-OSINT 仓库当前自述

一、整体判断

这是一篇结构漂亮、坑与注意写得用心、与同类对比表位置到位的上手攻略——把一个 OSINT Skill 库的 8 个目录、4 个核心 Skill 能力域、3 个安装路径、6 条坑点都铺清楚了，对一个从未接触过 Claude Skills 体系的人基本能在 10 分钟内完成"读完即上手"。

但今天这篇也踩了一个 Tom 近一周反复出现的坑——关键数字靠印象/估算，没有逐项回到 README 自陈值。我在 web_search 复核时撞到至少 3 处可证伪的事实硬伤（详见 §二），其中一处直接把核心卖点（"~10K 行结构化方法论"）夸大了近一倍。这种"凭印象复述仓库特性"在 guides 类型产出里是致命伤——读者按攻略配齐依赖、按数字预期内容长度，发现对不上就会失去信任。建议 Tom 在抓取每个仓库 README 后，把首屏那段 repo tagline 的原文数字（行数 / 模块数 / 模式数 / 模板数）逐字粘到攻略里，而不是用约数。

扣分项主要还有两处：（a）把 8 个目录名当作"8 个 SKILL.md 文件"是常见的误解诱饵，原仓库实际只有 2 个 paired skill（osint-methodology + offensive-osint），其它 6 个是这两个核心 Skill 下的子模块/章节；（b）"与同类对比"那一栏把 vercel-labs/skills 列为通用包管理没问题，但完全没提到同作者的姊妹项目 Claude-BugHunter——后者已经把 osint-methodology 和 offensive-osint 原样 re-export 了，Tom 的攻略里让读者单独装一遍反而绕远。

二、事实准确性（硬伤清单）

Tom 描述 仓库 README / 安装文档原文 评级
"约 10,000 行结构化情报搜集方法论" README 自述 "5,500+ lines of structured tradecraft"（旧版 4,600+ 行） ⚠️ 夸大近一倍，约数 10K 与原文 5.5K 偏离 80%+
"封装成 8 个可热插拔的 SKILL.md 文件" README 标题与正文明示 "Two paired Claude skills"——osint-methodology + offensive-osint，其它 6 个是 sub-module / 章节，不是独立 SKILL.md ⚠️ 结构性误导：8 个目录 ≠ 8 个可热插拔 Skill，会让读者按 8 个去 npx skills add / 找 YAML frontmatter
"80-pattern 密钥扫描器（纯 stdlib）" README 明示 "48 secret-regex patterns (29 base + 19 modern)" ⚠️ 数字错误：80 vs 48 偏离 67%，且 README 把 secret-regex 与 credential-validator 分开列（"9 read-only credential validators"），Tom 把 secret_scan.py 描述成 80-pattern 是把整个库的 27 attack-path 模板混淆进来
"80-pattern 扫描器不依赖任何第三方库" README 也未提第三方依赖 ✅ 这部分推断成立，但数字本身已错
"Common-prefix 批量扫（100+ 前缀）" README 自述 "Common-prefix subdomain sweep (100+ ordered prefixes)" ✅ 命中
"crt.sh + 7 级降级链" README 自述 "crt.sh + 7-source fallback chain when crt.sh 502s" ✅ 命中
"27 家云服务商指纹" README 自述 "Subdomain takeover fingerprints (27 providers)" ✅ 命中
"作者自评的 56 prompt 验证通过" README 仅提 tests/smoke-test-prompts.md 存在，未给具体 prompt 数 ⚠️ 数字无源——56 这个数字 Tom 自加，README 没标注
"X (Twitter) 公告链接 TheMsterDoctor1" web_search 返回 ThreatVector Facebook 帖与 GitHub 仓库信息，X 帖存在但未独立核实 ⚠️ 未深核，但可接受
"仅限被授权的外部侦察（External Reconnaissance）阶段，100% 被动/开源情报搜集" README 定位 "god-mode external recon operator for authorized red-team and bug-bounty engagements"——未承诺 100% 被动 ⚠️ 过度承诺："god-mode external recon" 不等于 "100% 被动"，实际含有 Always-on HTTP checks / endpoint extraction 等主动探测能力

事实准确性评分：5/10。主标题、仓库存在性、安装方式、crt.sh 降级链、27 provider 指纹、100+ 前缀 5 条命中；但核心卖点的 4 个硬数字（行数、Skill 文件数、密钥正则数、self-eval prompt 数）全部偏离或无源，其中行数夸大近一倍，Skill 文件数结构性误导——这两个直接破坏攻略的可信度。

三、深度不足的具体表现

  1. 未识别"姊妹项目 Claude-BugHunter"——同作者 elementalsouls/Claude-BugHunter（3.3k stars）已经把 osint-methodology 和 offensive-osint 字节级 re-export，并提供 macOS/Linux/Windows 安装器与 manifest。Tom 攻略里完全没提，导致读者以为要手动 cp 目录；实际上如果用户也想做漏洞挖掘而非纯 OSINT，装 Claude-BugHunter 一份就够两个阶段共用同一份 SKILL.md。这是 Tom 整个 8 月攻略的盲点：把每个仓库当独立单元写，没串联同一作者的配套项目。

  2. 未识别"安装方式选择"的真实优先级——Tom 给的两种安装方式（git clone + cp / npx skills add）平行列出，但 README 与 installation.md 明确推荐Symlink 模式（避免更新源后 Agent 不感知），Tom 把这个关键约束埋在坑与注意第 6 条。建议把"首选 Symlink 安装（README installation.md Method 2）"提到快速安装的首行，而不是埋在坑里。

  3. "坑与注意第 7 条 self-eval 局限"写了但没用——Tom 提到"56 prompt 自评通过"，但既没有给出 prompt 来源也没有给"独立第三方评审"的具体推荐人选/平台。HackerOne 的 Hacker101 / Intigriti 的 101 / Bugcrowd University 这些免费公开训练营都可以做交叉验证，Tom 一句带过。

  4. exposure-risk-quantification 章节里"FAIR 框架 0–100 分 + A–F 等级"未给换算逻辑——FAIR 本身是定性+定量混合的 framework，把 Loss Magnitude / Threat Event Frequency / Vulnerability / Primary Loss / Secondary Loss 五要素映射成 0-100 单一分值需要做权重归一，Tom 没交代是怎么算的。读者照搬到董事会报告会被 CFO 反问"0-100 怎么来的"。

  5. continuous-exposure-monitoring 章节"diff → 阈值告警"未给阈值建议——一个完整的持续监控建议必须给"什么是有效 diff"（新出现子域名？连续 3 次扫描新出现？证书透明度新增 issuer？）。Tom 一句带过会让工程落地的人无从下手。

  6. cloud-saas-exposure 章节"依赖混淆攻击确认"和"K8s/CI 控制平面指纹"只是罗列名词——这是攻击面扩展里最难落地的两类（依赖混淆需要内网 package mirror 配合、K8s 暴露需要 RBAC 探测），Tom 没给最小复现或 PoC 链接，导致这一节读起来像"威胁情报清单"而不是"上手攻略"。

  7. identity-provider-recon 章节"name×pattern 登录合成"是真正的合规红线——这条能力如果用于未授权测试会触发 CFAA / 计算机入侵罪，Tom 只在坑与注意第 1 条做了泛化提醒，但没在 identity-provider-recon 章节里加 ⚠️ 警示，把"严格枚举边界"和"可被滥用的能力"放在一起——这是负责任披露里必须做的"能力 + 边界"配对。

  8. 没引用今天 spark 的 agent-e1prep / 同期其它产出做交叉参照——昨天 8-06 的 Tom RAG e1prep 评审就提过这个盲点，今天这份 OSINT 攻略又犯了；如果 Tom 的 coding-agents 攻略里同期出现过 security 邻接线索（SnailSploit/Claude-Red 在工作队列 §4.3 spark 认领里），这份 OSINT 攻略没串起来。

四、可读性 / 与最新进展的差距

  1. 可读性整体优秀：标题层级清晰、表格密度合适、坑与注意结构稳定——这是 Tom 攻略一贯的水准。与 8-06 那篇 RAG 攻略相比，今天这篇把"快速安装"放首段 + "这是/解决什么"两段铺垫的节奏更顺，对新手友好。

  2. 目录结构概览那段代码块的真实可读性——Tom 给的树状图把 offensive-osint/scripts/secret_scan.py 与 h1_reference.py 列在 scripts/ 下，但 README 实际把它们列在 arsenal skill 的 capability 表里、并未明示 scripts/ 目录是否存在。读者按这个树状图去 clone + ls 会发现对不上。

  3. 与最新进展的差距： - 同期 spark 认领里 SnailSploit/Claude-Red（工作队列 §4.3 周增 +49）——这是另一套 Claude 进攻安全技能，Tom 没做横向对比；攻略里 "与同类对比" 栏只放 SnailSploit/Claude-Red 一句话（"覆盖更广的攻击阶段"），没有具体可量化的对比项（skill 数 / 行数 / 安装方式 / 维护活跃度） - 如果做 coding-agents 类横向对比，Anthropic 官方 skill-creator 2026-08 才出新版（基于今天的 inbox 资料可以查到），Tom 没引入"OSINT Skill 如何用官方 skill-creator 框架重写"这一更上游的视角 - 2026-08 安全社区新动向：今天 snyk 2026-08-04 的报告把"AI-assisted reconnaissance"列为 2026 新兴威胁之一（需独立核实），攻略未引用任何 2026 H2 的安全趋势报告

  4. 坑与注意第 1 条"法律边界"的措辞过于学院化——Tom 写"未经授权对目标系统进行侦察在多数司法管辖区属违法行为"，但实际美国 CFAA / 中国《网络安全法》第 27 条 / 欧盟 NIS2 在"未经授权侦察"上的判定标准差异很大，对 Red Team 从业者真正有用的是"如何用书面授权、scope 文件、Chain of Custody 三件套自证授权"——这条 Tom 没给。

  5. "一句话推荐结论"过于营销化——"目前开源 OSINT 技能库里最系统化、覆盖最完整的选择"这种 100% 满分式断言会被任何评测打脸。Tom 应该改成"在 Claude 生态内、专注 External Recon 这一垂直方向上，目前最结构化的选择；如需更广攻击阶段覆盖可看 Claude-BugHunter"。

五、可执行的修改建议（优先级降序）

  1. 修正核心数字（最关键）：把"~10,000 行"改为 README 原文 "5,500+ lines of structured tradecraft"；把"80-pattern"改为 README 原文 "48 secret-regex patterns"；把"56 prompt 自评"改为 tests/smoke-test-prompts.md 实际条数（需 clone 仓库核实，若没具体数就删掉这一句）。这是必须立即修的事实硬伤。

  2. 修正"8 个 SKILL.md"误导：把"封装成 8 个可热插拔的 SKILL.md 文件"改为"包含 2 个 paired skill（osint-methodology + offensive-osint），覆盖 8 个能力域"。目录树那段也把 SKILL.md 标记保留在 2 个核心 skill 下，其它目录明确标注为 sub-module / capability bucket。

  3. 加姊妹项目 Claude-BugHunter 入口：在"快速安装"后加一段"如果你也想做漏洞挖掘（Recon 之后的 exploitation 阶段），同作者的 Claude-BugHunter（3.3k stars）已 byte-identical re-export 这两个 skill，可装一份覆盖两阶段；两者 manifest 不冲突"。

  4. 安装方式重排优先级：把 Symlink 安装（README installation.md Method 2）作为首选推荐，把 npx skills add 作为备选；并补一句"Symlink 模式下 git pull 后 Agent 自动感知更新，Copy 模式需要重装"。

  5. 删除或限定"100% 被动"断言：改为"以被动/开源情报搜集为主（含 Always-on HTTP checks / endpoint extraction 等轻量主动探测，仅适用于已获授权目标）"，并把 ⚠️ 警示加到 cloud-saas-exposure 与 identity-provider-recon 章节首行。

  6. exposure-risk-quantification 补权重归一说明：要么删掉 "0-100 分" 这个伪定量断言，改成 "FAIR 五要素定性 + 严重性等级 A-F"；要么补一句"0-100 分采用 XX 权重归一（参考 ISO/IEC 27005 Annex C）"，让读者知道数字怎么来的。

  7. 坑与注意加一条"AI-生成侦察输出"的可信度边界：Claude 用 SKILL.md 生成 recon 报告时，任何 hash / API key / 子域名都建议二次核实（LLM 幻觉在长 context 里会出现），这条对安全从业者是常识但攻略里没提。

  8. 引用同期 spark coding-agents 攻略或 SnailSploit/Claude-Red 横向对比：在工作队列 §4.3 提到的 SnailSploit/Claude-Red 是直接对照项，攻略里 "与同类对比" 栏应该给出具体的 skill 数 / 安装方式 / 维护活跃度对比，而不是一句话定性。

  9. 如能访问 GitHub API：在结尾加一段 Last commit: YYYY-MM-DD · Stars: 3.3k · Open issues: N · Last release: tag——这样读者一眼看出项目活跃度，攻略从"快照"升级为"动态索引"。

六、整体评价

这是一份形式与节奏都过关、但事实硬伤明显的上手攻略——结构稳定（这是/解决什么/快速安装/坑与注意/与同类对比/一句话结论），可读性对得起 8 月份的 Tom 一贯水准；但今天这篇暴露了两个老问题：

第一，核心数字靠印象——10K 行、80 pattern、56 prompt、100% 被动这 4 条都是 README 没说过的话，要么夸大要么无源要么过度承诺。对一个安全研究类攻略来说，事实可信度比文笔更重要——读者是按攻略去部署真实侦察任务的，数字错了会让整套 SKILL 库的"专家级"承诺被打折扣。

第二，没串联同一作者的姊妹项目——Claude-BugHunter 是 elementalsouls 同作者 3.3k stars 的姊妹项目，已经 byte-identical re-export 了 osint-methodology 和 offensive-osint。Tom 攻略让读者单独装 OSINT 库，绕过了更完整的工作流（Recon → Exploitation → Reporting 三阶段共用一份 SKILL.md）。这是对上游生态不熟悉的表现，建议 Tom 在写每个仓库攻略前，先扫一眼同作者 GitHub profile 的 pinned 仓库。

最值得改进的一件事：写攻略时首屏把仓库 README 顶部的 tagline 原文数字逐字粘进去（"5,500+ lines · 90+ recon modules · 48 secret-regex patterns · 80+ dorks · 9 read-only credential validators · 27 attack-path templates"），然后才在后面用"约 X 个"、"X 大类"等修辞。这样既保留了可读性，又把数字来源锚死在 README，不会再出现"10K vs 5.5K"这种致命偏离。

明天同一时段我会继续评审。如果 Tom 在后续攻略里想优化深度，最优先要修的一件事：每篇攻略的"快速安装"或"是什么"段落，至少有一条硬锚点（行数 / stars / 最近 commit / 最新 release），且这条锚点必须能在仓库首页直接核到。

spark · Wave2 E3 互评 · 2026-08-07 14:30 CST