前几轮拆解把代码审查、测试、重构、调试这几条主线都走完了：code-review/simplify/verify/run 四件套拆过，webapp-testing 拆过，二进制调试赛道也拆过。但翻开本地 ~/.claude/skills/ 目录，还有一组长期站在聚光灯外的样本：security-best-practices、security-threat-model、security-ownership-map，加上一个把「失败前置」写成艺术的 security-review。这一轮把样本范围收窄到「安全工程」这一小块，全部基于磁盘上的 SKILL.md 原文逐行阅读。核心发现有三：一是这组 Skill 覆盖了写代码时、设计时、提交门禁、仓库诊断四个互补层次，拼起来就是一条完整防线；二是其中一个样本的正文里出现了「projects being reviewed by codex」字样，留下了跨 Harness 搬运的文本痕迹；三是从中能提炼出四个可直接抄走的设计模式——预检门禁、算式开头、references 渐进加载、有界输出。
评分基于 SKILL.md 文本质量与设计推断（未做长周期实测），「社区活跃度」一列对出厂件不适用，按分发方式标注。
| Skill | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 分发方式 (15%) |
|---|---|---|---|---|---|
| security-best-practices | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | 已装即用 |
| security-threat-model | ★★★★ | ★★★★★ | ★★★★ | ★★★☆ | 已装即用 |
| security-ownership-map | ★★★★ | ★★★★ | ★★★☆ | ★★★☆ | 需 pip 依赖 |
| security-review | ★★★☆ | ★★★★☆ | ★★★★ | ★★★★★ | 已装即用 |
| gh-fix-ci | ★★★☆ | ★★★★ | ★★★★ | ★★★☆ | 本地单件 |
定位：不是让你跑一次安全扫描，而是在你写代码的全程当隐形安全顾问。它定义了三种工作模式，层次非常清楚：主模式是「从这里开始写 secure by default 的代码」，适合新项目起步；二模式是「被动检测」，干活路上顺手标记高危漏洞；三模式是用户点名要一份完整的安全报告，按严重程度分节、每条发现编号、关键发现配一句话影响声明。
设计拆解：它的第一步设计得很克制——先识别「ALL languages and ALL frameworks」，前后端都要识别，然后才去 references/ 目录按 <language>-<framework>-<stack>-security.md 的命名规则加载对应文档，找不到就退化到模型自身的通用知识。这是典型的渐进式披露：正文只放流程，规范细节全部外置到参考文件，按需加载。更难得的是它对「现实工程」的妥协写进了正文：Override 一节明确说「你可以向用户报告，但不要和他们对抗（do not fight with them）」，建议把绕过原因写进项目文档而不是反复阻拦。Fixes 一节甚至点破了安全债的社会学：「不安全的代码往往因为别的原因被依赖着，这正是它活了这么久的原因」——所以修复要一次一条、要考虑回归、要写清楚注释。通用建议里也有反直觉的干货：公开资源 ID 别用自增整数改用 UUID4；对 HSTS 直接建议别乱推荐，「用错会导致大面积宕机和用户被锁在门外」；非 TLS 环境设 secure cookie 会直接弄坏开发环境。
彩蛋：TLS 一节的原文写道「not generally recommended for the scope of projects being reviewed by codex」——一个 Claude 环境里的 Skill 正文里留着 codex 的名字，大概率是从别的 Harness 生态整段搬来改的。这也侧面证明安全规范类 Skill 的文本正在跨厂流通。
短板：三模式全靠模型自觉切换，没有像 code-review 那样的硬性输出契约；references 目录的覆盖面决定上限，冷门框架等于裸奔。
上手：零依赖。装好后在对话里说「给这个项目做一次安全评估报告」即可触发报告模式，平时写代码它按被动模式挂着。
定位：产出一份「AppSec 级」威胁模型文档，开头第一句就把野心写在脸上——「deliver an actionable threat model that is specific to the repository, not a generic checklist」。它要的不是 OWASP 十条念一遍，而是锚定你这个仓库的信任边界、资产和入口点。
设计拆解：八步流程里藏着三个非常成熟的提示词工程手法。第一步是「证据锚定」：「Do not claim components, flows, or controls without evidence」——模型不许凭空声称系统有什么组件，必须仓库里有实证。第五步是显式的定性风险公式：可能性 × 影响，各自给低/中/高加一句理由，还要求声明「哪些假设对排序影响最大」。第六步是全文最值钱的设计：强制暂停。「Pause and wait for user feedback before producing the final report」——在产出终稿前，模型必须把影响排序的关键假设列出来，问用户 1~3 个针对性问题（谁负责这个服务、部署模型是什么、有没有多租户），用户不回答也要明说「哪些假设仍未解决、它们如何影响结论」。这一步把威胁模型从「模型的自嗨文档」变成了「双向确认的交付物」。第八步还有一个出厂自检清单：入口点全覆盖了吗？每条信任边界都对应到威胁了吗？运行时和 CI/开发态分开了吗？输出格式对齐模板了吗？最后强制落盘为 <仓库名>-threat-model.md。
短板：八步走完交互成本不低，小项目用它有杀鸡用牛刀之感；references 的输出契约（prompt-template.md）是硬约束，改起来要动模板。
上手：已装即用，触发语建议直接用「对这个仓库做一次 threat model」，中途它会停下来问你问题——这不是卡住，是设计。
定位：四件里唯一的数据科学件。从 git 历史构建「人 × 文件」二部图，计算所有权风险（bus factor），再叠加一张文件共变图（共变 Jaccard 相似度），最后导出给 Neo4j/Gephi 做可视化。它回答的问题是传统扫描器永远不问的：「这段认证代码，是不是只有一个快离职的人看懂？」
设计拆解：它的工程素养全在默认值里。共变图默认忽略 lockfile、.github/*、编辑器配置这类「胶水文件」，否则集群全被共享基建的改动污染；默认排除 Dependabot 和 merge commit；甚至从作者提交的时区偏移里推断每个贡献者的主时区——这是给「外部承包商深夜改敏感代码」这类信号留的口子。敏感路径判定用一张 CSV 规则表（**/auth/**,auth,1.0 这样的三列格式），默认规则盖住 auth/crypto/secret 常见路径，可用 --sensitive-config 覆盖。最能体现「为 LLM 消费而设计」的是 query_ownership.py：它把结果切成「small, JSON-bounded slices」，明确说为了「without loading the full graph into context」——查某文件的共变邻居、查 bus factor ≤ 1 的加密文件、查 orphaned_sensitive_code（过期且低 bus factor 的敏感代码），每条都是小 JSON。这在 SKILL.md 设计上是个范式：脚本不只是自动化工具，更是上下文预算管理器。
短板：需要 Python3 + networkx；git log 特别大的仓库要自己记得加 --since；输出是 CSV/JSON 原料，结论要靠上层对话自己下。
上手：
pip install networkx
python ~/.claude/skills/security-ownership-map/scripts/run_ownership_map.py \
--repo . --out ownership-map-out --since "12 months ago" --emit-commits
python ~/.claude/skills/security-ownership-map/scripts/query_ownership.py \
--data-dir ownership-map-out summary --section orphaned_sensitive_code
这个 Skill 我没能看到正文：调用它时直接报错 Shell command failed for pattern "!git status" — fatal: not a git repository。但这次失败本身比多数成功样本更有教学价值——它的 SKILL.md 第一条指令是一个 ! 前缀的 shell 预检，不在 git 仓库里就当场终止，不进入任何后续流程。对比之下，很多 Skill 的失败模式是：模型硬着头皮在没有 diff 的环境里「脑补一次代码审查」，产出看起来专业、实际是幻觉的发现清单。预检门禁模式的本质，是把「这个 Skill 根本不该运行」的判断从模型判断降级为确定性判断——一行 shell 搞定，零 token，零幻觉空间。同目录下 code-review 的 Phase 0 也是同思路的软版本：先跑 git diff @{upstream}...HEAD，拿不到就逐级降级到 main...HEAD、HEAD~1、工作区 git diff HEAD，并在正文里解释「the review often runs before the commit」——降级链本身就在教模型理解真实工作流。
顺手看它的邻居：同为出厂件的 code-review 值得引用一句话作参照——它把 token 预算直接写成开篇算式 `high effort → 3+4 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings`，并用「PLAUSIBLE by default / REFUTED only when constructible from the code」锁死验证倾向。安全审查和正确性审查共享同一套多 Agent 骨架，差别只在finder 的攻击视角。
安全与质量发现之后，最后一步是修和回评。gh-fix-ci 把 GitHub CLI 的字段漂移都预案好了——自带的 inspect_pr_checks.py 注释里明说「handles gh field drift and job-log fallbacks」，gh pr checks --json 某个字段被拒就用 gh 实际支持的字段重跑；脚本「Exits non-zero when failures remain so it can be used in automation」，可以直接挂 CI。流程第六步明确要求先出修复计划、获批后再动手。gh-address-comments 更短：跑脚本拉取全部评论、给每条编号并给出修复成本摘要、让用户选号——又是一个「人在回路选单」设计。
flowchart LR
subgraph WRITE["写码时（被动免疫）"]
A["security-best-practices<br/>三模式:默认安全写法/被动检测/完整报告"]
end
subgraph DESIGN["设计时（评估）"]
B["security-threat-model<br/>八步流程·第六步强制暂停问人"]
end
subgraph GATE["提交门禁（确定性）"]
C["security-review<br/>!git status 预检·非git当场终止"]
end
subgraph AUDIT["仓库诊断（数据取证）"]
D["security-ownership-map<br/>git历史→bus factor·共变图·时区推断"]
end
subgraph TAIL["修复回路（运维尾巴）"]
E["gh-fix-ci<br/>字段漂移预案·非零退出码"]
F["gh-address-comments<br/>评论编号·人选单"]
end
A --> C
B --> C
C --> D
C --> E --> F
!git status``），不满足就地终止。适用一切依赖特定环境态的 Skill（git 仓库、docker、某个 MCP 在线）。<语言>-<框架>-<栈>-security.md 的文件名约定让模型自己路由到唯一需要的那份文档；threat-model 把输出契约整个放进 references/prompt-template.md 并要求「use it verbatim」。正文保流程，细节外置。query_ownership.py 把大图切成小 JSON 片；code-review 把发现硬性限到 10 条并规定 JSON 字段。共同点是替上下文窗口做预算，输出形状即接口。本文全部结论基于本机磁盘上的 SKILL.md 原文逐行阅读（样本即来源）：
~/.claude/skills/security-best-practices/SKILL.md — 三模式工作流、Override 政策、codex 字样出处~/.claude/skills/security-threat-model/SKILL.md — 八步流程、第六步强制暂停、输出契约~/.claude/skills/security-ownership-map/SKILL.md — 二部图/共变图设计、query 脚本有界输出~/.claude/skills/code-review/SKILL.md 与 ~/.claude/skills/simplify/SKILL.md — 算式开头、验证倾向、参照组~/.claude/skills/gh-fix-ci/SKILL.md、~/.claude/skills/gh-address-comments/SKILL.md — 修复回路两件!git status`` 门禁设计的直接证据延伸阅读（本期未抓取，供自行验证）：anthropics/skills 官方仓库、skillsmp.com 与 skills.sh 的安全类榜单——本文为纯本地样本拆解，跨站热度数据留待后续周报核补。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。