Legacy Modernization & Migration

Ports a codebase across a breaking language or runtime version with compatibility shims, batched automated transforms, dual-runtime CI, and old-vs-new output diffing, ending in a flag-flip cutover with a rollback rule. Use when someone says "migrate us from Python 2 to 3", "we're jumping Node majors", "move to the next Java LTS", or any runtime upgrade where source must change to keep compiling or behaving correctly. Do NOT use for an application framework's major version (React, Rails, Spring) - use framework-upgrader instead; for proving a database schema or data migration is safe, use migration-safety-checker; and skip it entirely when the runtime change is purely operational (base image, CI matrix, deploy target) with no syntax or semantic breaks.

Produces a documented inventory of the implicit business rules, edge cases, and bug-as-feature behaviors that tangled code encodes, with real input-to-output examples, so a rewrite preserves behavior. Use when you are about to rewrite, port, or replace legacy code whose only specification is the source, and you see policy buried in conditionals, magic numbers, hardcoded dates, or per-customer special cases. Do NOT use when you need an executable safety net before refactoring - use characterization-test-writer instead; do NOT use when you need to find service boundaries in a monolith - use monolith-decomposer instead.

Writes pinning and characterization tests that lock in the current behavior of untested legacy code - bugs included - before a refactor, so any later behavior change trips an alarm. Use when someone says "I need a safety net before refactoring this", "this module has no tests and I have to change it", "capture what this function does today", or the correct behavior is simply whatever the code does now. Do NOT use for writing tests for new behavior built red-green - use tdd-expert instead; do NOT use to decide which code is worth testing or to rank coverage gaps - use coverage-gap-finder instead; do NOT use to verify existing assertions are strong - use mutation-test-runner instead.

Proves code is unreachable with converging evidence, then removes it and its tests, fixtures, and flags in reversible slices without breaking dynamic callers. Use when deleting suspected dead code, cleaning up after a migration or feature retirement, trimming a bloated module, or before estimating work on unfamiliar code. Do NOT use when you want to survey and rank an area's debt without committing to deletion - use find-tech-debt instead.

Finds and validates one bounded-context seam to extract from a monolith - gated on coupling-graph, co-change, data-ownership, and transaction-boundary evidence - and sequences an incremental strangler-fig extraction plan. Use when someone asks "where should we cut this monolith", "is this module ready to extract as a service", "plan the extraction of billing from the app", or is evaluating whether a candidate seam is clean. Do NOT use for designing the target service architecture, service communication, or greenfield service boundaries - use microservices instead; do NOT use to document the implicit business rules inside the code being moved - use business-rule-extractor instead. This skill decides where to cut and in what order.

Audits third-party dependencies for exploitable CVEs, abandonment, license exposure, and supply-chain hygiene, and delivers a ranked findings report with a remediation order. Use when someone asks "is this package safe to add", "audit our dependencies", "npm audit is screaming, what actually matters", "can we use this GPL library", or is preparing a security review or vendor questionnaire. Do NOT use for triaging vulnerabilities in first-party code or a full CVE queue - use vulnerability-triage instead; for reviewing the code you wrote for security flaws - use secure-code-review instead; for how secrets are stored and rotated - use secrets-hygiene instead; for assembling compliance evidence - use soc2-evidence-helper instead.

Drive development with strict Red-Green-Refactor discipline - write one failing test, write the minimum code to pass it, refactor on green - including test-list planning and a worked kata cycle. Use when someone asks "write this test-first", "do TDD on this feature", "help me practice red-green-refactor", "write a failing test for this bug", or wants tests to drive a new module's design. Do NOT use for adding tests to existing untested legacy code before a refactor - use characterization-test-writer instead - or for designing shared fixtures and factories - use test-data-builder instead.