某段认证代码主要由谁维护，关键贡献者离开后是否还有人接手？security-ownership-map 用 Git 历史生成关系数据，再结合敏感路径规则找需要人工关注的地方。它可以导出 CSV、JSON 和可选图数据，适合安全交接讨论；提交记录只提供历史线索，不直接证明责任或能力。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer security-ownership-map
- 包含所需历史的本地 Git 仓库
- Python 3 和 networkx
- 明确的分析时间窗口、敏感目录和排除规则
Git 日志可按时间、作者和路径过滤。分析前先决定窗口：只看最近一年与看完整历史会回答不同问题，不能直接比较未说明口径的结果。 [4]
第一次怎么用
按项目实际目录调整下面的分析范围：
$security-ownership-map
分析当前仓库过去 12 个月的安全维护集中风险，重点是 auth/ 与支付签名相关代码。先确认历史是否完整，列出敏感路径规则和机器人排除方式。将 CSV/JSON 保存到 ownership-map-out，给出最需要人工确认的 5 个文件或模块，并与 CODEOWNERS 对照。不要把提交数量当作人员绩效。
接下来怎样推进
-
固定分析口径。 确定起止时间、作者或提交者身份、合并提交和机器人处理方式，确认敏感路径规则符合项目实际。
-
生成关系数据。 配套脚本构建人员与文件关系及共同变化图；先看 summary.json，再按问题读取有限的数据切片，避免把整张图塞进对话。
-
回到团队核对。 用结果寻找可能缺少交接的模块，对照 CODEOWNERS、实际职责和最近重构，形成需要确认的清单。
用 Git 历史提出交接问题
先选分析窗口和敏感路径，例如最近 12 个月的 auth/ 与 billing/，并确认重命名、机器人提交、合并提交如何计算。这个 Skill 的脚本需要 Python 3 与 networkx；让 Agent 先生成关系数据，再从 summary.json 和有限的 CSV 行里挑出值得核对的模块。历史太短或仓库只保留浅克隆时，结果会漏掉早期维护者，需先检查 Git 历史是否完整。
一个可用的问题是：“哪些认证文件近期只有一位常见修改者，且没有清晰的 CODEOWNERS 对应？” 这里的“常见修改者”由提交记录近似，不等于团队正式负责人。共同修改边还可能来自大型格式化或批量重构，不能直接推断两人一起设计了模块。
把图表转成团队可行动的清单
逐项核对候选文件、最近实际改动、当前负责人和交接文档。输出应包括要找谁确认、缺少哪份文档或复核、为什么会影响维护；不要产出个人排名或绩效判断。若一个安全目录显示“无人维护”，先排除路径改名和机器人身份，再将其标为需要团队确认的信号。
交付后先检查什么
输出目录通常包含 people.csv、files.csv、edges.csv、summary.json，以及启用共同变化分析时的相关数据。先检查时间窗口和排除规则，再看低维护冗余的敏感模块。共同提交可能只是一次批量改名，不能直接当作架构依赖。
所有权统计先看计算口径
把输出当成需要复核的线索，尤其别只凭一个“关键维护者”数字决定交接。独立代码核查曾发现旧版对 merge、bot 身份与时间衰减的处理会改变归属统计，孤立文件也可能没进社群图。对高风险目录，抽查几份真实提交，确认作者/提交者口径、是否纳入 merge、缓存是否按本次参数重建，再与实际值班和知识拥有者对照。
常见卡点
仓库很大、分析太慢。 缩小时间窗口或目录，并排除一次改动大量文件的噪声提交。
一个人被拆成多个身份。 先核对姓名、邮箱别名和历史迁移，避免把身份问题当作交接风险。
刚克隆的历史不全。 检查是否浅克隆；历史不足时标注覆盖范围，不输出全时期结论。