| name | swe:ownership-risk-map |
| description | 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. |
| compatibility | Requires local repository access and works best with git history, CODEOWNERS files, test layout, and any CI or coverage signals that help separate risky hotspots from well-covered surfaces. |
| metadata | {"short-description":"Map repository ownership risk from repo evidence"} |
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:
- Scope reviewed
- Evidence summary
- Ranked ownership-risk surfaces
- Recommended maintenance actions
- 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.
