Architecture ownership topology
Skill Xopoko/plug-n-skills/plugins/architecture-intelligence/skills/architecture-ownership-topology
Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.
npx -y skills add Xopoko/plug-n-skills --skill architecture-ownership-topologyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when architecture crosses ownership or review boundaries: CODEOWNERS/OWNERS, module coverage, cross-owned dependencies, socio-technical coordination, and governance paths.
SKILL.md
3.0 KB, as published. Nobody here has run it
Architecture Ownership Topology
Bundled commands use $PLUGIN_ROOT ($env:PLUGIN_ROOT in PowerShell; same path suffix) for the plugin root. Set it once: use the host's plugin-root variable when defined (Claude Code: PLUGIN_ROOT="$CLAUDE_PLUGIN_ROOT"), otherwise the absolute path of this plugin's root directory.
Use when the question involves ownership, team boundaries, review paths, CODEOWNERS, OWNERS files, shared modules, Conway-style alignment, or coordination risk across modules/services.
Inputs
- Ownership sources:
.github/CODEOWNERS,CODEOWNERS,OWNERS,OWNERS_ALIASES,MAINTAINERS,GOVERNANCE.md,CONTRIBUTING.md. - Architecture sources: package/module layout, ADRs, architecture docs, service boundaries, public APIs, dependency rules.
- Coupling evidence: static imports, build/package graph, runtime integrations, deployment/IaC, data ownership, co-change history.
- Governance evidence: branch protection, review rules, release ownership, exception paths, waivers.
- User-provided organization facts, only when explicitly provided.
Do not infer actual communication, staffing, workload, or review enforcement from repository files alone.
Probe
python3 "$PLUGIN_ROOT/scripts/architecture_probe.py" <repo-path> --json
Use ownership_topology for ownership sources, top-level coverage, ownerless areas, and cross-owned static dependency edges.
The parser is conservative: no GitHub API, org membership lookup, branch-protection proof, or full CODEOWNERS semantics.
Lenses
- Coverage: significant modules, runtime surfaces, and docs have owner or review path.
- Coordination risk: dependency/runtime/data/co-change edges cross different owner sets.
- Conway alignment: code and ownership boundaries appear aligned, misaligned, or unknown.
- Governance: architecture-changing work has decision owner, review path, exception path, revisit trigger.
- Knowledge risk: critical areas are ownerless, shared without policy, or tribal.
Workflow
- Identify ownership documents and scope.
- Map owned, unowned, ambiguous architecture areas.
- Join ownership with dependency, runtime, and docs evidence.
- Separate observed facts from coordination hypotheses.
- Prioritize by quality impact, propagation risk, reversibility.
- Recommend the smallest mechanism: CODEOWNERS rule, ADR owner, review gate, exception policy, or fitness function.
Output
Compact: topology summary, ownerless significant areas, cross-owned risks, governance gaps, review-path recommendations, limitations, next validation.
Durable: architecture_intelligence.ownership_topology.v1.
Do not diagnose team dysfunction. Do not treat ownership files as complete organization truth. Do not enforce review gates without migration path, exception policy, and owner confirmation.