Rust Port
Port code from C, C++, Python, Go, JavaScript, or TypeScript into idiomatic Rust that...
Install
npx skills add morganlinton/BeautifulRust --skill rust-port -g -a claude-code -y- Repository
- morganlinton/BeautifulRust1.6k
- Category
- Testing
- Updated
- 5d ago
- License
- MIT
- Context cost
- Mediumabout 1,915 tokens
- Runs scripts
- Yes, review before use
What it does
Port code from C, C++, Python, Go, JavaScript, or TypeScript into idiomatic Rust that keeps the original behavior: ownership instead of manual memory, Result instead of error codes and exceptions, enums instead of flag ints and magic strings, and tests that prove the port matches. Use this whenever the user asks to port, translate, convert, migrate, or rewrite code in Rust ("rewrite this in Rust", "what would this look like in Rust", "move this module to Rust"), even if they don't say "port". Pairs with the rust-best-practices skill, which covers the target code's style.
Rust port
The goal is the Rust a Rust developer would have written to solve the same problem, with
the same observable behavior. A line-by-line transliteration (C written in Rust syntax,
or Python with Box<dyn Any>) compiles but keeps every problem the original had and adds
the borrow checker on top. Port the behavior, not the structure.
1. Understand the original before writing anything
- Read the code and its tests, and anything that calls it, if you have it.
- List the observable behavior: every public function, its inputs, its outputs, and every way it can fail. Include the quiet parts, which are where ports go wrong: ordering of results, how ties break, what happens on empty input, whitespace and case handling, integer limits, and what counts as an error versus a valid edge case.
- Note what is incidental, meaning things the original only does because of its
language: manual memory management, out-parameters,
NULLreturns, global state, fixed-size buffers, a class that exists only to group functions, orisinstancechecks. These don't carry over. - If the original has a bug or an ambiguity, keep its behavior, flag it in the porting notes, and let the user decide. A port is not the place to silently fix things.
2. Port the tests first
Translate the original tests into Rust tests before porting the implementation. Keep one Rust test per original test, with a name that maps back to it, so a reader can check coverage. The tests are the definition of "same behavior". If the original has no tests, write characterization tests from the behavior list in step 1.
3. Design the Rust API, then implement it
Decide the public types and signatures from the behavior list, not from the original's shape. Then implement against the ported tests.
