Decision frameworks for Rust refactoring, simplification, module decomposition, and incremental migration. Use this skill when simplifying Rust code, splitting large files, removing dead abstractions, migrating types incrementally, or cleaning up feature flags. Triggers on Rust refactoring, simplification, module splitting, parameter cleanup, or incremental type migration.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
rust-refactor
description
Decision frameworks for Rust refactoring, simplification, module decomposition, and incremental migration. Use this skill when simplifying Rust code, splitting large files, removing dead abstractions, migrating types incrementally, or cleaning up feature flags. Triggers on Rust refactoring, simplification, module splitting, parameter cleanup, or incremental type migration.
Rust Refactoring Frameworks
This skill teaches you to look at working Rust code and see unnecessary complexity. Every refactoring starts with a diagnostic question, follows a transformation pattern, and ends with a self-review checklist.
The Two Refactoring Philosophies
Before touching code, decide which mode you are in.
Defensive mode: Add abstraction for safety. Split types. Create From bridges. Audit every consumer. Use when: security-critical code, type evolution, multi-crate dependencies.
Offensive mode: Delete indirection. Remove forwarded parameters. Collapse layers. Use when: the abstraction adds complexity without adding safety, the mediator just forwards, the parameter is always None.
Know which mode you are in. Do not add abstraction when you should be deleting, and do not delete safety layers when you should be adding them.
The 4 Diagnostic Questions
Run these BEFORE touching any code. They determine WHAT to refactor.
1. "Is this parameter just being forwarded?"
Signal: The function body only passes the parameter to another function. No local logic depends on it.
Action: Remove it. Replace with ambient/global access at the point of actual use. Remove from the lowest layer first, fix compilation errors upward.
2. "Is this feature flag still needed?"
Signal: Stage is Stable or equivalent, default is enabled, no rollback planned.
Action: Remove the flag. Delete the conditional. Rename gated functions ( -> ). Remove monitoring scaffolding.
init_if_enabled
init
3. "Is this file doing too many things?"
Signal: File over ~500 lines with impl blocks operating on different domains (e.g., threads AND logs AND jobs).
Action: Split by domain (what it operates on), not by layer. See Module Decomposition Guide below.
4. "Does this struct have mutually exclusive optional fields?"
Signal: 2+ Option<T> fields where only one should be set at a time. Code like if a.is_some() { assert!(b.is_none()) } or fields named x_config that only apply to one mode.
Action: Convert to an enum where each variant carries only its relevant data.
// BEFORE: invalid states representablestructAuth { api_key: Option<String>, oauth_token: Option<String>, storage: Option<TokenStore> }
// AFTER: each variant carries only what it needsenumAuth { ApiKey(String), OAuth { token: String, storage: TokenStore } }
// BEFORE: three options, only one valid at a timestructShellMode {
direct_cmd: Option<String>,
zsh_fork_config: Option<ZshForkConfig>,
pty_handle: Option<PtyHandle>,
}
// AFTER: disjoint union, invalid states unrepresentableenumShellMode { Direct(String), ZshFork(ZshForkConfig), Pty(PtyHandle) }
Steps: Audit construction sites for valid combinations -> define enum variants -> replace struct construction -> replace if x.is_some() with match -> remove defensive assertions.
The "Rewrite, Don't Rewire" Principle
When the bug is in a function's LOGIC (not its wiring), rewrite the body with explicit ordered checks. Do not delegate to an existing API that happens to produce correct results.
// WRONG: rewire through existing API ("happens to work")fnresolve_policy(input: &Input) -> Policy {
default_policy(input).override_with(input.overrides())
}
// RIGHT: explicit ordered checksfnresolve_policy(input: &Input) -> Policy {
if input.is_admin() { return Policy::FullAccess; }
if input.has_restriction("network") { return Policy::NetworkDenied; }
if input.is_sandbox_mode() { return Policy::ReadOnly; }
Policy::Standard
}
The explicit version is more auditable, more testable, and more robust to future changes in the delegated implementation.
Module Decomposition Guide
Group code by WHAT it operates on, not by architectural layer. Each domain file contains the impl block for that domain's methods on the shared struct.
Tests move WITH their code. Never leave tests behind in the original file.
mod.rs contains only re-exports. Target ~30 lines.
Each file under 500 lines. If exceeded, it has sub-domains.
Named types over loose parameters. 2+ related values always passed together -> struct.
No logic changes in extraction commits. Move code as one unit. Verify with cargo test.
Self-Review Checklist
Run this after every refactoring. Every item must pass.
After refactoring, verify:
[ ] Every intermediate state compiles (no big-bang rewrites)
[ ] From bridges exist for any split types
[ ] Tests moved with their code (not left behind)
[ ] No new single-use helper functions introduced
[ ] Removed more code than you added (or justified why not)
[ ] No forwarded parameters remain (each param is used locally)
[ ] Module re-exports are clean (public API in mod.rs)
[ ] Feature flags for stable features removed
[ ] Structs with mutually exclusive options converted to enums
[ ] Build performance measured before/after crate extraction
[ ] Feature flag removal includes function renames and branch deletion
[ ] Chose the right refactoring mode (defensive vs offensive)
[ ] Function logic rewritten, not just rewired through delegation
If any item fails, you are not done. Fix it before declaring the refactoring complete.
