---
name: repository-fleet-governance
description: Inventory and govern a large fleet of GitHub, GitLab, Gitea, and Forgejo repositories. Use when classifying repositories, detecting duplicates and forks, finding abandoned projects, comparing implementations, standardizing CI and branch rules, identifying monorepo candidates, mapping shared packages, planning archival, or coordinating changes across many repositories without merging directly to protected branches.
compatibility: Requires repository read access. Write actions, archival, branch deletion, release publication, and merge operations require explicit authorization and must be separated from analysis.
license: Apache-2.0
---

# Repository fleet governance

Treat the repository collection as a portfolio with product families, shared platforms, forks, experiments, and historical archives—not as unrelated repositories.

## Inventory model

Record for every repository:

- owner, name, visibility, default branch, archived state, last activity, size;
- languages, package managers, frameworks, runtime versions, build systems;
- CI workflows, dependency automation, release process, coverage and security checks;
- deploy targets, domains, databases, external APIs and secret-variable names;
- product family, lifecycle stage, canonical implementation, predecessor and successor;
- duplicated components, copied templates, forks and remote relationships.

Suggested lifecycle values: `production`, `active`, `maintenance`, `prototype`, `fork`, `superseded`, `archive-candidate`.

## Required workflow

1. Establish scope and repository access before making claims.
2. Build a normalized inventory; do not infer technology solely from repository names.
3. Cluster by product family and technical domain.
4. Identify canonical repositories before recommending consolidation.
5. Compare manifests, APIs, schemas, shared components, commit recency and deployment ownership.
6. Produce a proposed action plan with impact and rollback.
7. Apply reversible metadata changes first: topics, descriptions, labels, documentation and issues.
8. Use dedicated branches and pull requests for code changes.
9. Never automatically merge into `main`, `master`, release, production, or protected branches.
10. Re-scan after changes and report remaining drift.

## Fleet checks

- inconsistent Node, pnpm, .NET, Rust and Unity versions;
- duplicated or stale lockfiles;
- missing `AGENTS.md`, README, license, security policy or ownership information;
- workflows using unpinned actions or excessive permissions;
- repositories with no successful build path;
- forks that have diverged without documented intent;
- packages copied instead of consumed from a shared library;
- environment variables with inconsistent names;
- abandoned domains, deploy targets and container images;
- duplicate products with conflicting customer or billing data models.

## Consolidation rules

Do not recommend a monorepo merely because repositories share a prefix. Consolidate when ownership, release cadence, dependency graph and deployment boundaries support it. Preserve separate repositories when credentials, compliance, licensing, blast radius or release independence require isolation.

## Safe operations

Analysis, issue creation, labels and documentation are low risk. Repository archival, visibility changes, force pushes, branch deletion, history rewriting, release replacement and cross-host mirroring are consequential and require explicit approval plus a verified backup or remote.

## Output

Return:

1. portfolio inventory and confidence;
2. product-family clusters;
3. canonical and duplicate repositories;
4. urgent security or maintenance gaps;
5. consolidation and archival candidates;
6. ordered remediation waves;
7. exact repositories affected;
8. verification and rollback requirements.