Port Code Between Languages

Translate code the safe way: characterization tests first, idiomatic (not literal) translation, and a checklist of the semantic drift traps.

Port this code from [SOURCE LANGUAGE] to [TARGET LANGUAGE].

The code:
"""
[PASTE THE MODULE/FUNCTIONS, or point an agent at the files]
"""
What it does in production: [THE REAL JOB + what depends on it]
Existing tests: [PASTE THEM / "none", if none, step 1 is mandatory, not optional]
Target conventions: [THE FRAMEWORK/STYLE THE PORT MUST FIT INTO: paste a representative file from the target codebase if possible]

Work in this order:
1. **Characterization tests BEFORE porting**: write tests that pin down what the source code ACTUALLY does, including its quirks and probable bugs (capture current behavior faithfully; flag suspected bugs separately, don't silently "fix" them: a port that fixes bugs is two changes wearing one diff). Cover: the mainline paths, boundaries (empty/zero/max), error behavior (what throws, with what), and any behavior sensitive to the drift traps below. These tests, translated, become the parity gate.
2. **The drift-trap audit**: before writing target code, check the source for each and state how the target language differs:
   - Numerics: integer division semantics, overflow behavior (wrapping vs arbitrary precision vs exception), float vs decimal, rounding mode.
   - Null/absence: null vs undefined vs None vs Option, and every place the source relies on truthiness (empty string/0/empty list falsiness differs across languages).
   - Strings: byte vs code-point indexing, unicode handling, locale-sensitive casing/compare.
   - Collections: sort stability, iteration order guarantees, reference vs value copy semantics.
   - Errors: exceptions vs error returns vs panics. Map the source's error CONTRACT, not its syntax.
   - Concurrency, if any: the source's threading assumptions and what the target's model (event loop / goroutines / threads) changes about race surfaces.
   Mark each trap found in the code: [DRIFT RISK: what + how the port handles it].
3. **The port, idiomatic**: write it as a native [TARGET] developer would: target-standard library, naming, error handling, and iteration patterns. A line-by-line transliteration that "works" is a maintenance defect: the point is code the target team can own.
4. **Parity verification**: the characterization tests translated and run: report which pass, and for any behavioral difference, classify it: bug in the port (fix), intentional idiom difference (document why it's acceptable), or source quirk deliberately not preserved (list for my sign-off).
5. **The seam note**: if this is part of a larger migration: how old and new versions can coexist (adapter/facade), so the cutover is a switch, not a leap.

Rules: no silent behavior changes, every difference between source and port appears in the step-4 report. If the source depends on something with no clean target equivalent, present options rather than picking silently.
Originated fromStan SedberryUpdated
Migrationsadvanced

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner
Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate
Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.

Codingintermediate

Search prompts

Find a prompt by title, description, tag, or category.