Review and retire an owned repository portfolio

Why use this

1. A repository owner may accumulate experiments, forks and abandoned projects without knowing which still have users or dependencies. Inactivity alone is a weak reason to change visibility or delete a project.

2. This job could prepare a portfolio-retirement proposal with ownership, purpose and consequences visible. Separating classification from action gives the owner a chance to preserve useful history and review irreversible or access-changing decisions individually.

Why an agent / simpler alternative

Useful judgment

Interpret repository purpose and activity, identify dependency questions and distinguish originals from forks without assuming dispensability.

Simpler alternative

Review a small repository list manually when ownership and purpose are obvious.

Unsuitable when

The task would delete uncertain assets, change collaborator access or treat inactivity as consent to retire work.

Proposed inputs

1. Name

   Repository inventory

   Owner

   Verified owner

   Minimum scope

   Owned repository IDs, metadata and visibility

   Quality check

   Check transfers, forks and collaborators

2. Name

   Retention brief

   Owner

   Owner

   Minimum scope

   Projects to preserve, retirement goals and known dependencies

   Quality check

   Distinguish public visibility from actual usage

Access and setup — proposed or unknown

Proposed minimum

1. Use fictional metadata and a proposed decision table; no GitHub access, archival, visibility changes or deletion.

Compatibility unknowns

1. Current ownership visibility, dependency evidence, recovery behavior and runtime compatibility are unknown.

External actions requiring approval

1. Visibility changes, archival, repository deletion and access effects require explicit approval; irreversible deletion requires action-time confirmation.

Expected deliverable and review checks

Proposed artifact

Repository decision queue with rationale, dependency/owner questions and separate approval states.

Critical checks

1. Verify ownership; preserve unresolved dependencies; reconcile inventory identities; distinguish proposed retirement from completed changes.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   An inactive repository supports another project

   Why it matters

   Cleanup may break a hidden dependency

   Proposed response

   Hold the decision and check known consumers.

2. Signal

   A fork contains unique unpublished work

   Why it matters

   Classification hides valuable differences

   Proposed response

   Inspect divergence before proposing retirement.

Effort and cost — unknown

Setup work

1. Define preservation rules and consequence categories.

Ongoing review

1. Owner reviews each material action and verifies any authorized outcome.

Unknowns

1. Usage evidence, collaborator impact, recoverability and review effort are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent four repositories: dormant dependency, modified fork, active original and empty experiment; prepare proposals only.

Acceptance checks

1. Hold uncertain assets; distinguish action types; make no visibility or deletion change.

Stop conditions

1. Stop if ownership, uniqueness, dependencies or action recoverability is unresolved.

Limits

1. A retirement classification cannot establish lack of users, safe deletion or successful cleanup execution.