What problem does it solve? Maintaining two sibling toolkits (gokit in Go, rskit in Rust) risks API drift, duplicated design mistakes, and inconsistent behavior. This Skill provides a disciplined workflow for deciding what to mirror, what to keep kit-only, and how to track cross-kit parity without sacrificing idiomatic Go. ## Core Features & Use Cases - Capability-first mirroring decisions: Classify each scope as fully mirrored, light version, or intentionally kit-only (e.g., heavy media transcoding stays rskit-only). - Idiomatic Go implementation guidance: Enforces generics-first design, typed errors (AppError/RFC 9457), options constructors, and no any in public APIs instead of transliterating Rust. - Parity tracking workflow: Records mirroring levels and deliberate divergences in rskit tracking issues referenced by full URL, and validates changes with toven tests. - Use Case: When porting a resilience or config module from rskit to gokit, use this Skill to study the stronger implementation, decide the mirroring level, implement it idiomatically, and log the parity decision. ## Quick Start Ask the assistant to align the gokit config module with its rskit counterpart and record the parity decision in an rskit tracking issue.