
Oxidizer Workflow
- 54 installs
- 70 repo stars
- Updated July 26, 2026
- rysweet/amplihack
Helps with automation & workflows tasks.
About
oxidizer-workflow is a Claude Code skill for automation & workflows. It helps solo builders move faster with AI-assisted development.
- oxidizer-workflow
- Automation & Workflows
- AI-coding skill
Oxidizer Workflow by the numbers
- 54 all-time installs (skills.sh)
- +1 installs in the week ending Jul 26, 2026 (Skillselion tracking)
- Ranked #1,056 of 2,719 Automation & Workflows skills by installs in the Skillselion catalog
- Data as of Aug 2, 2026 (Skillselion catalog sync)
npx skills add https://github.com/rysweet/amplihack --skill oxidizer-workflowAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 54 |
|---|---|
| repo stars | ★ 70 |
| Last updated | July 26, 2026 |
| Repository | rysweet/amplihack ↗ |
What it does
Helps with automation & workflows tasks.
Files
Oxidizer Workflow Skill
Purpose
Orchestrates the oxidizer-workflow recipe to migrate Python codebases to Rust. The workflow is recursive and goal-seeking — it loops until 100% feature parity is achieved, with quality audit and silent degradation checks on every iteration.
When to Use
- Migrating a Python module, package, or CLI to Rust
- Porting a Python library to a standalone Rust crate
- Creating a Rust binary that replaces a Python tool
Core Principles
1. Tests first — Python test coverage must be complete before any porting begins 2. Zero tolerance — 100% parity required; partial results are not accepted 3. Quality gates — Every iteration runs clippy, fmt, and a full test suite 4. No silent degradation — Every feature, edge case, and error path must be preserved 5. Iterative convergence — Module-by-module, loop until converged
Required Inputs
| Input | Example | Description |
|---|---|---|
python_package_path | crates/amplihack-recipe/src | Path to the package to migrate |
rust_target_path | rust/recipe-runner | Where to create the Rust project |
rust_repo_name | amplihack-recipe-runner | GitHub repo name for the Rust project |
rust_repo_org | rysweet | GitHub org or user for the repo |
Execution
Via Recipe Runner
amplihack recipe run amplifier-bundle/recipes/oxidizer-workflow.yaml \
-c python_package_path=src/mypackage \
-c rust_target_path=rust/mypackage \
-c rust_repo_name=my-rust-package \
-c rust_repo_org=myorgWorkflow Phases
Phase 1: Analysis
└─ AST analysis, dependency mapping, type inference, public API extraction
Phase 1B: Test Completeness Gate
└─ Measure coverage → write missing tests → re-verify → BLOCK if < 100%
Phase 2: Scaffolding
└─ cargo init, add dependencies, create module structure
Phase 3: Test Extraction
└─ Port Python tests to Rust test modules → quality audit tests
Phase 4-6: Iterative Convergence Loop (× N until 100% parity)
├─ Select next module (priority order from Phase 1)
├─ Implement module in Rust
├─ Compare: feature matrix diff against Python
├─ Quality gate: cargo clippy + fmt + test
├─ Silent degradation audit: check for lossy conversions
├─ Fix any degradation found
└─ Convergence check: if < 100% parity → loop again
Final: Summary report with parity matrixConvergence Rules
- Each iteration processes one module at a time (core-out strategy)
- Up to 5 unrolled loops in the recipe, plus
max_depth: 8for sub-recipes - The recipe terminates when
convergence_status == "CONVERGED"or
iteration_number > max_iterations (default 30)
- If max iterations reached without convergence, the final summary reports
which modules are still incomplete
Recipe Location
The oxidizer recipe is at:
amplifier-bundle/recipes/oxidizer-workflow.yamlThe recipe is the executable workflow — this skill is the discovery and activation layer. When investigating or customizing the workflow phases, agent prompts, or convergence rules, start with the recipe file above.
Effective Rust Compliance
The oxidizer workflow enforces idiomatic Rust practices aligned with the Effective Rust guide by David Drysdale. Key rules baked into every iteration:
Types (Items 1–6)
- Use Rust's type system to make invalid states unrepresentable (
enumwith data) - Use
Option<T>for optional values — never sentinel values like-1ornull - Use
Result<T, E>for fallible operations — never panic on expected errors - Use the newtype pattern for domain-specific semantics (units, IDs, validated strings)
- Prefer
From/Intoconversions overascasts - Use
thiserrorfor library error types,anyhowfor application error handling
Unsafe (Item 16)
- Avoid writing `unsafe` code — use standard library and crate abstractions instead
- If
unsafeis absolutely required (FFI), isolate it in a wrapper module with safety comments - Run Miri over any
unsafecode - Enable the
unsafe_op_in_unsafe_fnlint
Parallelism (Item 17)
- Prefer channels (
std::sync::mpsc) over shared state when possible - Use
Arc<Mutex<T>>for shared state — keep lock scopes small - Group related data under a single lock to prevent deadlocks
- Never invoke closures or return
MutexGuardwith locks held - Include deadlock detection in CI (
parking_lot::deadlock, ThreadSanitizer)
Tooling (Items 29, 31, 32)
cargo clippy -- -D warningson every iterationcargo fmt --checkon every iterationcargo docto verify documentation compilescargo-udepsto detect unused dependenciescargo-denyfor license and advisory checkscargo benchwithstd::hint::black_boxfor realistic benchmarks
What Success Looks Like
- Rust project builds cleanly (
cargo build) - All tests pass (
cargo test) - Zero clippy warnings (
cargo clippy -- -D warnings) - Formatted (
cargo fmt --check) - Feature parity matrix shows 100% coverage
- No silent degradation detected
- Zero
unsafeblocks (or justified, isolated, and Miri-tested) - Idiomatic Rust types — no sentinel values, no stringly-typed APIs