feat: add /migration-analysis Claude command for Go-to-TypeScript planning

[zackverham]

Summary

• Adds a /migration-analysis Claude command that scans the live Go codebase to produce a migration roadmap for the Go-to-TypeScript effort
• Analyzes package inventory, dependency graph, migration tiers, TypeScript coverage, and reverse dependencies
• Shows only the final roadmap by default; pass --verbose to see intermediate step details
• Results are dynamic — re-run anytime to get an updated view as migration progresses

Type of Change

• Tooling

Approach

The command is a structured prompt in .claude/commands/migration-analysis.md that guides Claude through 6 analysis steps:

1. Package inventory — enumerates LOC, source/test files, subpackages
2. Dependency graph — extracts internal imports (excluding test files) at both top-level and subpackage granularity
3. Migration tiers — computes a topological ordering via a Python script, surfacing circular dependencies
4. TypeScript coverage — checks for existing TS equivalents of Go packages
5. Reverse dependencies — identifies foundation packages with the most consumers
6. Migration roadmap — compiles everything into a prioritized plan with tier visualization, subpackage extraction opportunities, risk assessment, and recommended order

A $ARGUMENTS check at the top controls verbosity: default mode suppresses intermediate output, --verbose shows all steps.

User Impact

None — this is a developer tooling command only used within Claude Code sessions.

Automated Tests

N/A — this is a Claude command prompt, not executable code. The Prettier formatting fix ensures CI check-format passes.

🤖 Generated with Claude Code

[dotNomad]

This is very helpful. Getting those tiers is a great way to grab the next step of this migration.

[dotNomad]

When it got to this block it had to re-run because of this:

Key insight: config only imports clients/types, not the full clients package. And bundles also only imports clients/types. This means the apparent config -> clients and bundles -> clients cycles can
be broken by extracting clients/types as an independent package.
Similarly, deployment imports inspect/dependencies/renv, not the full inspect package. And inspect imports bundles/matcher, not necessarily the full bundles package (though it also imports bundles).
Let me re-run the tier computation with subpackage-accurate dependencies

Thought that was worth noting.

[zackverham]

yeah I saw it catching some cycles like that we should investigate more closely.