rewrite-in-rust

Rewrite in Rust

Carry the requested migration through to verified results within the authorized scope. Treat the original implementation, documented contracts, and observable behavior as evidence. Do not promise that every codebase has a practical complete Rust replacement.

When to use

Use this skill for requests to rewrite, port, migrate, or oxidize an existing codebase, library, module, application, or subsystem in Rust, including RIIR requests; for feasibility assessments of such a port; for incremental replacement of one component while the rest keeps working; and for resuming a migration that already has records under migration/. Do not use it for new Rust code with no original to preserve, for Rust-to-Rust refactors, or for adding a single Rust dependency to a project.

Operating rules

• Follow the user's scope and repository instructions. An assessment request authorizes assessment; an implementation request authorizes the necessary scoped work. Do not turn internal phase gates into repeated permission questions. Ask only when missing information changes correctness or scope, or an action needs authorization that has not been given.
• A fixed set of decisions belongs to the user. Collect them once after the assessment from references/DECISIONS.md, each with a recommended answer. Do not decide them silently, do not ask what the code already answers, and do not re-ask a recorded decision per unit.
• Keep one repository-specific migration contract as the source of truth. Separate compatibility requirements from intentional changes. Default to preserving observable behavior and module boundaries; do not combine migration with unsolicited redesign, dependency replacement, or feature development.
• Write idiomatic Rust, not a transliteration. Preserving structure means keeping behavior, interfaces, and module responsibilities; it does not mean copying sentinel return codes, out-parameters, index loops, manual cleanup, null pointers, or inheritance mechanics into Rust. See Idiomatic Rust target.
• Preserve defined behavior and required compatibility. Never recreate undefined behavior, memory corruption, or unsound Rust to imitate the source. Record a safe, specified replacement for those cases. Keep fixes to defined source defects separate and explicit unless the user requested them as part of the migration.
• Default to safe Rust. When a direct translation would need unsafe, rethink that unit's design instead of transcribing it. Use unsafe only at an unavoidable FFI boundary or in a small block where measured performance is the deciding requirement. See Unsafe policy.
• Inspect the repository before choosing tools, crate boundaries, or ownership types. Do not import another project's choices, such as a runtime ban, byte strings everywhere, or one crate per source directory, without evidence from this repository.
• The rulebook is read-only inside a batch. Queue amendments and apply them between batches under the authority the user chose (D-PROC-01). A failure seen three times is a rule defect, not three instances.
• This skill ships reference documents, not tooling. Read a reference when its section applies. Reuse existing project tooling first; write small repository-specific helpers only when needed, inspect and verify them, and keep them in the target project or a scoped temporary workspace. Never assume a helper, runtime, connector, or agent facility exists.
• Write migration records only when the request authorizes file changes. For an assessment-only request, return the assessment in the reply.
• Prefer the smallest useful workflow. A small module may need only a short contract, a patch, and direct verification. Use the large-scale path when the signals in Scale say so.
• Treat compilation, behavioral compatibility, Rust soundness, performance, and release readiness as separate claims. Attach evidence to each claim.