code-cleanup

Refactors Go code in this repository while preserving observable behavior and reducing mechanism.

4|Updated Dec 1, 2025
One-click install
npx skills add https://github.com/simplyblock/simplyblock-operator --skill code-cleanup-simplyblock
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-cleanup
Source: https://github.com/simplyblock/simplyblock-operator/tree/main/.claude/skills/code-cleanup
Command: npx skills add https://github.com/simplyblock/simplyblock-operator --skill code-cleanup-simplyblock

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Refactoring working code is risky: cleanups often change behavior silently, add mechanism instead of removing it, or touch generated files and shipped API fields that must never be edited. This Skill provides a disciplined, measurement-driven process for cleaning up Go code in the simplyblock Kubernetes repository without changing what it does. ## Core Features & Use Cases - Behavior and mechanism gates: Runs the test suite before editing, then compares baseline and post-cleanup metrics (function length, nesting, duplication, hand-rolled primitives) via scripts/measure.sh so reductions are proven, not claimed. - Nine ordered cleanup passes: Dead code, comments, atlas-lib modernization, deduplication, complexity, function sizing, restructuring, pattern unification, and constants, each with preserve-lists and known failure modes. - Duplication and hand-rolled primitive detection: scripts/find-twins.sh finds identical function bodies across the operator and CSI driver and flags places where atlas-lib primitives were rewritten by hand. - Use Case: Ask to simplify a 180-line controller function; the Skill locks behavior with tests, applies guard-clause flattening and extraction, verifies generated manifests are unchanged, and reports measured before/after metrics. ## Quick Start Ask the assistant to clean up and simplify the functions in operator/internal/controller using the code-cleanup skill, keeping behavior unchanged.

Frequently Asked Questions about code-cleanup

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor Go code without changing its behavior?

Run the target's test suite before editing to lock behavior, apply behavior-preserving passes such as extraction, deduplication, and guard-clause flattening, then re-run tests and compare measured metrics. Any finding that changes behavior is reported separately, never folded into the cleanup.

How to find duplicated code across Go modules?

Use the bundled find-twins.sh script, which compares normalized function bodies across the operator, CSI driver, and atlas-lib modules. It reports cross-module copies, within-module duplicates, and hand-rolled reimplementations of atlas-lib primitives.

What files should never be edited during a cleanup?

Never touch generated code such as *.gen.go and zz_generated.deepcopy.go, synced Helm charts, installer output, the Arm copyright blocks in the CSI driver, or shipped CRD field names under operator/api. The retiring operator/internal/webapi package also takes no investment.

When should a cleanup stop instead of continuing?

Stop when the next step requires a behavior change, when the mechanism gate is net-neutral twice in a row, when the diff exceeds roughly 400 lines, or when a pass needs a path from the never-touch list. Diagnosis without edits is a legitimate outcome.

Does this refactoring approach work for untested code?

Untested code gets a characterization test first to pin current behavior before any edit. If the code cannot be covered, for example because it needs a real cluster or hardware, the cleanup stops at diagnosis rather than claiming unverifiable equivalence.