Translate Programming Language

Use this skill to migrate production server/application code from one language/runtime to another without losing externally observable behavior. Preserve parity first, then simplify toward the target language after the old runtime is removed.

Core Rules

• Treat the source runtime as the initial oracle, but check a public standard when one exists.
• Never hand-write expected fixtures. Generate them from a pinned source runtime or a standards-conformance harness.
• Keep reusable migration docs free of domain-specific names, URLs, schemas, customers, or product facts.
• Put language/runtime quirks in a compatibility layer, not in domain logic.
• Attach every compatibility layer to a deletion plan: source behavior, target behavior, standard/spec reference, callers, and post-cutover migration target.
• Do not trust unit parity alone. Verify with shadow/replay traffic and production-shaped benchmarks before switching.

Workflow

1. Scope the migration boundary
   • Choose a narrow contract: function, module, endpoint, message type, or protocol handler.
   • Inventory inputs, outputs, side effects, state, clocks, randomness, locale, environment variables, filesystem/network usage, and error behavior.
   • Decide whether the externally visible contract is byte-exact, structurally equivalent, or semantically equivalent.