# Rust Port

Port code from C, C++, Python, Go, JavaScript, or TypeScript into idiomatic Rust that...

- Repository: https://github.com/morganlinton/BeautifulRust (1642 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add morganlinton/BeautifulRust --skill rust-port -g -a claude-code -y`
Codex: `npx skills add morganlinton/BeautifulRust --skill rust-port -g -a codex -y`
Cursor: `npx skills add morganlinton/BeautifulRust --skill rust-port -g -a cursor -y`
Gemini CLI: `npx skills add morganlinton/BeautifulRust --skill rust-port -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add morganlinton/BeautifulRust`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

1. **Read the code and its tests**, and anything that calls it, if you have it.
2. **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.
3. **Note what is incidental**, meaning things the original only does because of its
   language: manual memory management, out-parameters, `NULL` returns, global state,
   fixed-size buffers, a class that exists only to group functions, or `isinstance`
   checks. These don't carry over.
4. 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.

### From C and C++

The rest: https://github.com/morganlinton/BeautifulRust/blob/HEAD/skills/rust-port/SKILL.md