Ownership Risk Map
Skill Verified ActiveMaps 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.
To provide engineers with a clear, evidence-backed map of ownership risk within a repository, enabling proactive maintenance and identification of potential fragility before incidents occur.
Features
- Maps engineering ownership risk using repo evidence
- Analyzes git history, churn, and bus factor
- Assesses CODEOWNERS coverage and test density
- Identifies orphaned or unclear-owner surfaces
- Provides ranked output for recurring maintenance
Use Cases
- When a user asks to map ownership risk in a repository.
- When a user wants to find bus factor hotspots.
- When identifying files or modules with unclear ownership.
- For running recurring maintenance passes to identify risky surfaces.
Non-Goals
- Assigning people to teams or building org charts.
- Generic repo orientation without an ownership-risk goal.
- General bug hunting or refactor planning.
- Security audits not specifically focused on ownership risk.
Practical Utility
- info:Usage examplesWhile the README provides installation and development examples, the SKILL.md itself lacks specific end-to-end usage examples demonstrating input, invocation, and output for the ownership risk mapping.
- info:Edge casesThe SKILL.md mentions handling unknowns and missing evidence, but detailed documentation of specific failure modes, symptoms, and recovery steps is not explicitly provided.
Installation
/plugin install swe-skills@ckorhonen-swe-skillsQuality Score
VerifiedTrust Signals
Similar Extensions
Evolve Team
99Evolve an existing team composition by refining its structure in-place or creating a specialized variant. Covers assessing the current team against template and coordination patterns, gathering evolution requirements, choosing scope (adjust members, change coordination pattern, split/merge teams), applying changes to the team file and CONFIG block, updating version metadata, and synchronizing the registry and cross-references. Use when a team's member roster is outdated, coordination pattern no longer fits, user feedback reveals workflow gaps, a specialized variant is needed alongside the original, or agents have been added or removed from the library affecting team composition.
Project Session Manager
100Worktree-first dev environment manager for issues, PRs, and features with optional tmux sessions
Sync Profiles
100Use when the user wants to list, create, switch, delete, compare, or inspect config sync profiles.
Using Git Worktrees
100Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Unslop Commit
100Rewrites commit messages so they sound like a careful human engineer wrote them. Strips AI/marketing slop ("comprehensive solution", "robust implementation", "leverage", "enhance", "seamlessly", "This commit..."). Keeps Conventional Commits format. Subject ≤72 chars (aim ≤50), imperative mood. Body only when "why" isn't obvious from the subject. Use when user says "humanize commit", "de-slop commit message", "make this commit sound human", "/unslop-commit", "/commit", "write a commit", or pastes a draft commit to clean up. Auto-triggers when staging changes.
Rule Effectiveness Analysis
100Analyze which rules are actively used vs inert. Detect coverage gaps. Recommend pruning to reduce token consumption.