Port code to another language

Have Claude Code port a module to another language while keeping the API and behavior you name, with the tests ported and run against the new code.

Task: Port code to another language · Other tasks

Fill in the details

Code to port (required)

A file, module or package. In Claude Code you can type @ to reference it.

Target language (required)

What must stay the same (required)

Constraints for the new code

Optional. Where the code goes, libraries to use or avoid, error handling style.

Command that runs the ported tests

Optional. Leave empty and Claude will find how the project runs tests in that language.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Port [fill in: Code to port] to [fill in: Target language], keeping the same [fill in: What must stay the same].

1. Read the source and its tests first. Write down what the port must preserve: public functions and types, inputs and outputs, error cases, side effects, and behavior the tests rely on. Show me this list before you write the port.
2. List anything without a direct equivalent in [fill in: Target language], such as dynamic typing, exceptions, null values, integer overflow or third-party libraries, and say how you will handle each one. Ask me where the choice changes behavior.
3. Write idiomatic [fill in: Target language], not a line-by-line transliteration. Follow the project's existing [fill in: Target language] code if there is any. Prefer the standard library and dependencies the project already has, and ask before adding new ones.
4. Port the tests as well, so the same cases run against the new code. Run them and keep going until they pass. Do not drop or weaken a test case to make it pass.
5. Leave the original code in place. Do not delete it or switch callers over to the port.

If part of the source is unclear or looks like a bug, ask before deciding whether to carry it over.

Finish with the files you created, a table mapping each original public item to its port, any behavior that differs and why, and anything you could not port.

3 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

A module needs to move to another language, for speed, for a shared runtime, or because the rest of the system has moved, and its behavior must not change on the way.
The original code has tests, so there is something concrete to port alongside it and run against the new version.
You know the target language less well than the source and want an idiomatic result, with the places where the languages differ called out for you.

When not to use it

You want to move a whole codebase at once. Port it module by module, using this template for each piece, and plan the order first.
The original code has no tests and its behavior is not written down anywhere. Add tests first with the write and run tests template, or the port has nothing to be checked against.
The goal is to redesign the module as well. Changing the language and the design in one step makes it hard to tell which change caused a difference; port first, then refactor.

Why this structure

The opening line names what must stay the same, not only the target language. That turns "port it" into something Claude can check the result against.
Step 1 asks for the list of what must be preserved before any code is written. You can add a forgotten case or correct a misreading while it is still cheap.
Step 2 brings the hard parts forward. Differences in typing, errors and number handling are where ports change behavior quietly, so Claude has to name them and ask where it matters.
Porting the tests and running them in step 4, with your command when you give one, gives Claude a pass or fail check and a reason to keep going until the new code behaves like the old.
Step 5 keeps the change additive. The original stays in place and callers are untouched, so you can compare both versions and switch over when you are ready.
The closing table maps each public item to its port, which makes gaps easy to see in review.

Example input (fictional)

Code to port

the Python module billing/invoice.py

Target language

Rust

What must stay the same

public API and test behavior

Constraints for the new code

Put it in the existing crate under rust/billing. Return errors as Result values and never panic on bad input. Use rust_decimal for money.

Command that runs the ported tests

cargo test -p billing

Follow-ups to send Claude

Run the original tests and the ported tests on the same inputs and list any case where the results differ.
Which parts of the port are least idiomatic for this language? Rewrite them and keep the tests passing.
Plan how to switch callers from the old module to the port in small steps, without changing anything yet.

Common mistakes

Naming only the target language. Without a statement of what must stay the same, Claude has to decide on its own which behavior matters.
Porting the code but not the tests. The tests are the main way to show the new version behaves like the old one.
Accepting a port that copies the source line by line. It may pass the tests but is harder to maintain in the new language; ask for idiomatic code.

Migrate a pattern across a codebase: Move every use of an old API, library or pattern to its replacement: Claude Code lists each place first, then changes them in checked batches.
Write tests, run them, fix failures: Ask Claude Code to write tests for a file, run them and work through the failures in one go, without weakening a test just to make it pass.
Plan a code change before editing: Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
How Anthropic teams use Claude Code (Anthropic documentation)
Claude Code docs: Common workflows, refactor code (Anthropic documentation)
Claude Code best practices: Give Claude a way to verify its work (Anthropic documentation)