---
name: book--refactoring-guru--nano
description: >-
  Refactoring Guru (Refactoring.Guru) — Minimal rules — essential one-liners only. Use when asked to apply Refactoring Guru principles or review code against Refactoring Guru standards.
origin: "github.com/ciembor/agent-rules-books (MIT)"
license: MIT
version: "1.0.0"
compatibility: "yamtam-engine >= 0.14.0"
---

# OBEY Refactoring.Guru

## When to use

Use as a compact always-on bias for safe, smell-driven refactoring during existing-code changes.

## Primary bias to correct

Refactoring is not cleanup for its own sake: diagnose one smell, treat it with the smallest behavior-preserving move, verify, then stop.

## Decision rules

- Separate structural refactoring from feature and bug behavior; if behavior changes, name and isolate it.
- Diagnose the smell before choosing a technique: symptom, cost, smallest treatment, verification, and stop condition.
- Prefer small named transformations over broad redesign.
- Keep the program runnable and run relevant checks after risky movement, state-flow changes, public API changes, or algorithm replacement.
- Stop when the diagnosed smell is reduced; do not chase new smells unless they block the current change.
- Prefer extraction, naming, movement, inlining, and encapsulation before adding hierarchy, polymorphism, wrappers, or method objects.
- Do not create abstractions from coincidental similarity, random parameter bags, simple conditionals, or speculative future needs.
- Keep behavior with the data it changes unless separation intentionally supports interchangeable behavior.
- Preserve public compatibility when changing signatures, constructors, visibility, hierarchy, or externally reachable code.
- Delete or inline dispensable code only after checking public, generated, reflected, serialized, plugin-facing, framework, and test-only uses.

## Trigger rules

- When a method needs comments or local-state reconstruction, extract a named method after checking inputs, outputs, and mutated variables.
- When a class changes for unrelated reasons, extract the responsibility; use subclass/interface only for stable variants or real client subsets.
- When conditionals repeat by type or state, isolate the decision before using polymorphism; leave simple honest conditionals alone.
- When duplicate code appears the third time, refactor unless the similarity is likely to diverge.
- When parameter lists or primitive clumps carry one concept, model the concept; do not pass a huge object to hide dependency.
- When clients navigate chains or internals, hide the delegate or move behavior; remove pass-through middle men that add no policy.
- When null, error code, assertion, value/reference, or association changes are considered, verify semantics before changing structure.

## Final checklist

- Smell named?
- Smallest treatment?
- Behavior verified?
- Stop condition reached?
- No hidden feature change?
- No speculative abstraction?