Code Simplification

Remove unnecessary complexity while preserving observable behavior. Adapted from Addy Osmani's code-simplification workflow; see the bundled license and repository third-party notice.

Route precisely

• Use when the user asks to simplify or refactor working code without changing behavior.
• Use clean-code-comments when only redundant comments should change. Use code-review for a read-only assessment of a diff and review-arch for system-level boundaries.
• Do not broaden a feature or bug fix into unrelated cleanup merely because nearby code could be shorter.

Understand before editing

Read repository instructions, tests, callers, public contracts, and the reason for an apparent abstraction or branch. Note what must remain identical: API, serialized data, errors, side effects, ordering, concurrency, and user-visible behavior as applicable. Identify one concrete complexity cost, such as duplicated branching, indirection without a use, or a concept in the wrong owner.

Simplify in bounded steps

1. Choose the smallest change that removes a concept, branch, or repeated decision. Prefer clarity over minimum line count, and follow local style.
2. Preserve boundary behavior. If a simplification requires changing a test's expected behavior, treat it as a behavior change and stop or obtain the appropriate scope.
3. Apply one coherent transformation at a time. Use repository tooling for mechanical changes that exceed safe manual review.
4. Run focused tests or equivalent checks after each meaningful step, then the normal gate for the affected area. Inspect the diff for unrelated changes.

Go refactors, when applicable

For Go renames or package moves, inspect implementations, method sets, embeddings, build tags, generated contracts, and callers before changing a symbol. Prefer an available version-identified semantic tool such as gopls for a non-trivial rename; review its proposed edits and retain a search/manual fallback when it is unavailable. Do not install tooling or upgrade Go/dependencies automatically. Keep the supported build configurations and focused package tests as evidence; a green default build does not establish every build-tag or external-consumer contract. Use go-benchmark only when performance measurement is explicitly requested, not to justify a readability refactor by assumption.

These Go-specific checks adapt Samber's refactoring guidance, under the bundled LICENSE.samber-cc-skills-golang.

Report

State what complexity was removed, why the old structure existed when known, which contracts were checked, commands and results observed, and remaining behavior limits. Revert or revise a change that makes the code harder to understand or cannot be supported by proportionate verification.