1---2name: repo-modernization3description: stage legacy cleanup and modernization without losing the current operating path. use when a repo has dependency drift, weak validation, outdated frameworks, monolith friction, or repeated delivery pain that needs a phased plan instead of a rewrite impulse.4---56# Repo Modernization78## Trigger Signals910- the repo is legacy, inconsistent, slow to change, or missing dependable workflows11- dependencies, framework versions, or build tooling are clearly behind the desired support window12- repeated pain shows up in build fragility, onboarding cost, release risk, or architectural drag1314## Inspect First1516- build, test, and release entrypoints17- runtime and framework versions, dependency manifests, and lockfiles18- architecture seams, integration boundaries, and highest-risk hotspots19- observability, CI, documentation, and rollback surfaces that determine whether change is safe2021## Workflow22231. establish the current operating path and the minimum validation baseline needed to change the repo safely242. group problems into modernization layers: visibility, build and dependency health, codebase consistency, and architecture253. separate quick wins from seam-first refactors and from truly strategic platform changes264. produce a staged roadmap with validation and rollback expectations for each phase275. prefer incremental replacement and automation over big-bang rewrites unless evidence says otherwise2829## Output Contract3031- current-state summary with the biggest sources of drag or risk32- prioritized modernization themes and why they matter now33- phased roadmap with prerequisites, safety rails, and likely owners34- automation candidates, migration helpers, and explicit non-goals3536## Failure Modes3738- the repo lacks enough validation to support any meaningful modernization safely39- production topology or support commitments are too unclear to judge migration risk40- the proposed plan collapses into a rewrite with no intermediate value or rollback path4142## Escalation4344- escalate when modernization would break support or release commitments without a transition plan45- escalate when the work crosses multiple teams or service boundaries with no owner alignment46- escalate when data migration, security posture, or compliance constraints materially change the plan4748## References4950- `skills/repo-modernization/references/modernization-layers.md`51- `skills/repo-modernization/references/strangler-and-seams.md`52- `skills/repo-modernization/references/dependency-and-build-modernization.md`53- `skills/repo-modernization/references/safety-rails.md`54- `skills/repo-modernization/references/automation-candidates.md`55- `skills/repo-modernization/references/roadmap-template.md`56- `skills/repo-modernization/references/examples.md`