Who has recently maintained an authentication module, and is there a handoff gap if one contributor leaves? This Skill builds relationship data from Git history and combines it with sensitive-path rules. CSV, JSON and optional graph outputs support a security handoff discussion. Commit history is a clue, not proof of formal responsibility or expertise.
Install and prepare
This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.
Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.
$skill-installer security-ownership-map
- A local Git repository with the required history
- Python 3 and networkx
- A defined date window, sensitive paths and exclusion rules
Git history can be filtered by date, author and path. Choose the window first: a recent year and the full history answer different questions. Results with different unstated scopes are not directly comparable. [4]
Try a first task
Adjust the paths below to match the repository you want to analyze:
$security-ownership-map
Analyze security maintenance concentration over the last 12 months, focusing on auth/ and payment-signature code. First verify history coverage and explain sensitive-path and bot rules. Save CSV/JSON to ownership-map-out. Identify five files or modules most needing human confirmation and compare them with CODEOWNERS. Do not use commit counts as a performance score.
Work through the task
-
Define the sample. Choose dates, author versus committer identity, merge handling and bot filters. Make sensitive-path rules specific to the project.
-
Build relationship data. The bundled analysis produces ownership and co-change data. Read summary.json first, then query bounded slices instead of loading the entire graph into a conversation.
-
Validate with the team. Compare candidate handoff gaps with CODEOWNERS, actual responsibilities and recent refactors. Produce questions to confirm, not personnel judgments.
Use Git history to raise handoff questions
Choose a time window and sensitive paths, such as the last 12 months of auth/ and billing/, and decide how renames, bot commits and merge commits should count. The bundled script needs Python 3 and networkx. Ask the agent to generate relationship data, then inspect summary.json and a bounded slice of CSV rows for modules worth checking. A shallow clone or short history can omit earlier maintainers, so verify that the Git history is sufficient first.
A useful question is: “Which authentication files have only one frequent recent editor and no clear matching CODEOWNERS entry?” A frequent editor inferred from commits is not necessarily the formal owner. Co-change edges can also arise from mass formatting or large refactors; they do not prove two people jointly designed a module.
Turn the graph into an actionable team list
For each candidate, compare the file, recent functional changes, current owner and handoff documents. The output should say whom to ask, what documentation or review is missing, and why the gap affects maintenance. Avoid turning the graph into a people ranking or performance score. If a sensitive directory appears “ownerless,” rule out renamed paths and bot identities before treating it as a signal for team confirmation.
Check the result
Typical outputs include people.csv, files.csv, edges.csv and summary.json, plus co-change data when enabled. Check the window and exclusions before interpreting sensitive modules with few maintainers. A shared commit may be a bulk rename, so co-change alone does not establish an architectural dependency.
Common blockers
Analysis is slow. Narrow the time range or scope and exclude noisy commits that touch many files.
One person appears as several identities. Check name and email aliases before treating the split as an ownership risk.
The checkout has incomplete history. Check for a shallow clone and state coverage limits instead of making all-time claims.
Check the ownership calculation before trusting the map
Treat the map as a lead to verify, not a single-number handoff decision. An independent code audit found that merge handling, bot attribution, time weighting, and isolated files could affect older results. For a sensitive directory, inspect representative commits, confirm author-versus-committer settings and merge inclusion, rebuild caches when parameters change, then compare the map with the team’s real on-call knowledge.