# Swe:ownership Risk Map > Maps engineering ownership risk in a repository using repo evidence such as git history, churn, bus factor, CODEOWNERS coverage, test density, and orphaned or unclear-owner surfaces. Use when a user says `map ownership risk`, `find bus factor hotspots`, `which files look orphaned`, `high-change low-test areas`, or asks for a recurring maintenance pass that identifies risky surfaces before they become incidents. Do NOT use for org charts, HR ownership assignments, or generic maintainer lists without repo evidence. - Skill: `ckorhonen/swe-ownership-risk-map` (Agent Skill) - Install (CLI): `npx skillmds@latest add ckorhonen/swe-ownership-risk-map` - Raw SKILL.md: https://api.skillmd.com/api/skills/ckorhonen/swe-ownership-risk-map/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ckorhonen (https://skillmd.com/u/ckorhonen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ckorhonen/swe-ownership-risk-map --- # SWE Ownership Risk Map ## What This Skill Does Use this skill to identify where a repository is most exposed to ownership risk, not to build a people directory. The goal is to produce a ranked map of surfaces that are likely to become fragile because of: - concentrated commit ownership - high churn with few distinct contributors - unclear or missing CODEOWNERS coverage - low test density near important code paths - stale or orphaned modules, scripts, or configs - recent turnover or repeated handoffs in the same surface The output should be suitable for scheduled maintenance: short, repeatable, and easy to compare across runs. ## When To Use Use this skill when the user wants to: - find the highest-risk ownership hotspots in a repo - identify likely bus-factor problems before a change or release - run a recurring maintenance pass over high-churn or low-ownership areas - see which surfaces need better ownership, tests, or documentation ## Do Not Use Do not use this skill for: - assigning people to teams or building an org chart - generic repo orientation with no ownership-risk goal - general bug hunting or refactor planning - security audits that are not specifically about ownership risk ## Inputs To Confirm Confirm or infer: - repository or package scope - time window for the analysis, if any - whether the user wants the whole repo or a selected folder/package - whether CODEOWNERS or similar ownership metadata is available - whether the user wants a report-only pass or a ranked maintenance backlog If the scope is missing, infer the current repository root and use a recent history window, but say so explicitly. ## What To Optimize For - concrete repo evidence - honest unknowns when ownership is unclear - a short ranked list instead of a flat dump of names - actions that reduce ownership risk without broad rewrites - repeatable maintenance output that can be run on a schedule ## Instructions ### Step 1: Define The Scope State the exact repo, package, folder, or service being reviewed. If the user gives a time window, respect it exactly. If they do not, use the smallest recent-history window that still gives useful signal. ### Step 2: Collect Ownership Evidence Gather evidence from sources such as: - git history and commit authorship - churn over the chosen time window - CODEOWNERS or similar ownership files - test files and nearby validation coverage - CI or flaky-test signals tied to the surface - recent PRs or handoff clues in commit messages when available Prefer direct evidence over inference. When you infer ownership risk from a pattern, label it as an inference. ### Step 3: Identify Risk Surfaces Look for surfaces such as: - files with a single dominant committer - high-change areas with only one or two contributors - code paths with weak tests or no nearby validation - configs, scripts, or glue code that seem maintained by no one - modules that have changed recently but lack clear ownership metadata - cross-cutting surfaces touched by many changes but few distinct owners Rank each surface by the combination of: - bus factor - change frequency - test or validation coverage - ownership clarity - operational blast radius ### Step 4: Separate Facts From Inference For every risky surface, say: - what is directly observed - what is inferred - what remains unknown Do not invent a maintainer just to make the map look complete. ### Step 5: Propose Maintenance Actions For the highest-risk surfaces, propose the smallest sensible follow-up actions such as: - add or update CODEOWNERS coverage - add a small validation test near the hotspot - document the ownership boundary in repo guidance - reduce hidden coupling with a narrow refactor - add a recurring review item for the surface Keep the actions small and ownership-focused. Do not turn the map into a general cleanup backlog. ### Step 6: Make It Recurring-Friendly If the user implies a scheduled pass, include what should be compared across runs: - changed ranking - new or removed hotspots - surfaces that improved after prior follow-up - surfaces that remain orphaned or under-covered ### Step 7: Keep The Output Evidence-Backed If the repo does not have enough signal for a confident map, say so directly and list the missing evidence rather than guessing. ## Output Requirements Provide a report with these sections: 1. Scope reviewed 2. Evidence summary 3. Ranked ownership-risk surfaces 4. Recommended maintenance actions 5. Unknowns or gaps For each ranked surface, include: - area or files - observed evidence - inferred risk signal - why it matters - confidence level - smallest follow-up action For any surface where evidence is weak, include: - what made the signal weak - what would strengthen it - explicit no-guess decision ## Quality Bar - Rank by ownership risk, not by contributor count alone. - Keep the output short enough to compare between recurring runs. - Distinguish evidence from inference. - Prefer repository signals over people assumptions. - Be honest when ownership is unclear or missing. - Recommend only actions that directly reduce ownership risk.