From codeguard-security
Guide secure migration of code from memory-unsafe languages (C, C++, Assembly) to memory-safe languages (Rust, Go, Java, C#, Swift). Use when migrating or rewriting legacy C/C++ code, designing FFI boundaries between safe and unsafe code, writing new modules in existing C/C++ codebases, reviewing mixed-language projects, planning memory safety roadmaps, or when an AI agent is about to generate new C/C++ code that could be written in a memory-safe language instead. Also triggers on CISA/NSA memory safety compliance discussions.
npx claudepluginhub cosai-oasis/project-codeguard --plugin codeguard-securityThis skill uses the workspace's default tool permissions.
- User asks to migrate, port, or rewrite C/C++ code to Rust, Go, Java, C#, or Swift
Implement memory-safe programming with RAII, ownership, smart pointers, and resource management across Rust, C++, and C. Use when writing safe systems code, managing resources, or preventing memory bugs.
Provides cross-language patterns for memory-safe programming including RAII, ownership, smart pointers, and resource management. Useful for preventing leaks, use-after-free, and debugging memory issues.
Reviews unsafe Rust code and FFI for soundness, valid use cases, SAFETY docs, common errors like null derefs/data races, and alternatives like MaybeUninit/bindgen.
Share bugs, ideas, or general feedback.
Before writing any new code, ask:
If the project is predominantly C/C++, write the new module in an MSL and integrate via FFI. See references/ffi-security.md for boundary rules.
Follow these steps for every migration task:
Run the assessment script to evaluate migration priority and feasibility:
python scripts/assess-migration.py --file <source_file>
Or manually evaluate using the checklist in references/assessment-checklist.md.
Priority order for migration:
Never migrate a component without test coverage. If no tests exist, write them against the C/C++ implementation before touching anything. These tests become the correctness oracle for the new implementation.
One function or module at a time. Never rewrite an entire codebase in one pass. Follow the Android model: new code in MSL, existing stable code stays in place, proportion of unsafe code decreases over time.
For common migration patterns (buffers, strings, concurrency, error handling), see references/migration-patterns.md.
Every interface between safe and unsafe code is a security boundary. Follow all rules in references/ffi-security.md. Key rules:
unsafe blocks — wrap only the minimum necessary operationunsafe block with a // SAFETY: commentstd::panic::catch_unwind at FFI entry pointsAfter every migration unit, verify:
unsafe surface without documented safety invariantsclippy for Rust, go vet for Go)rustfmt, gofmt)unsafe without annotation, dependency audit)Never do these during migration:
unsafe to replicate C-style patterns in Rust — if extensive unsafe
is needed, the approach should be redesigned or the code should remain in CResult,
Go uses multiple returns. Every error path must be explicitly mappeddefer, try-with-resources,
using, or with patternsFor detailed guidance on specific topics: