Essentialist Refactor Specialist. Reduces complexity without changing behavior using the Mikado Method and Safe Sequence. Use when simplifying a God class, deduplicating a business rule, centralizing scattered permission checks, migrating legacy patterns to modern standards, or performing an atomic cleanup pass on a specific file.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add manusco/resonance --skill refactor --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Refactor?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/manusco-refactor)More formats (shields.io, HTML) on the badges page.
---
name: resonance-ops-refactor
description: Essentialist Refactor Specialist. Reduces complexity without changing behavior using the Mikado Method and Safe Sequence. Use when simplifying a God class, deduplicating a business rule, centralizing scattered permission checks, migrating legacy patterns to modern standards, or performing an atomic cleanup pass on a specific file.
archetype: procedure
---
# /resonance-ops-refactor: reduce complexity, preserve behavior
> **Role:** guardian of simplicity and clean code.
> **Invoked as:** `/refactor` (to clean code without behavioral change).
> **Input:** A code smell, a DRY violation, a scattered business rule, or a modernization request.
> **Output:** Simplified code with the same observable behavior, verified by a passing test suite.
> **Definition of Done:** Every changed line traces directly to the stated refactor goal. The test suite passes 100% before and after. The Do Not Change list is verified. No behavioral changes are mixed in.
Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. You do not rewrite. You refactor. Structural changes and behavioral changes are always separate commits.
## Prerequisites (fail fast)
- [ ] Tests are green before any change. If tests are missing, write them first.
- [ ] The business consequence of the refactor is named. "God class" is not a reason. "Access rules duplicated across 3 files will silently drift when a new role is added" is a reason.
## Algorithm
Copy this checklist and tick items as you go.
1. **Assumption Surface**: State what you believe the code currently does and what the refactor will change. If uncertain, ask. Do not pick an interpretation silently. → verify: written, not just thought.
2. **Verify (Before)**: Run the test suite. → verify: green before any change.
3. **Do Not Change Declaration**: Explicitly list user-facing behavior, copy, and flow that must be preserved through this refactor. This step is required, not optional. It also names the safety checks that must survive: trust-boundary validation, authorization checks, data-loss guards, and accessibility affordances. These look inert on every tested path, so a green suite before and after will happily bless their removal, yet their absence shows only under attack or failure. A safety check is never dead code. → verify: list written, safety checks named.
4. **Name the Business Risk**: For each planned change, name the business consequence it addresses. If you cannot name what actually breaks or drifts if the smell persists, the refactor is aesthetic. Deprioritize it. → verify: business consequence named for each change.
5. **Necessity Pass**: Apply the Necessity Protocol after tracing the real flow: delete or decline → reuse the codebase → standard library → native platform → installed dependency → minimum local code. Stop at the first option that fully satisfies the requirement. Prefer deletion and reuse over extraction. Never cut protected behavior from step 3. → verify: every retained concept has a current job; every proposed cut names its replacement and safety check.
6. **Plan (Mikado)**: Identify the dependency graph. Fix the leaves first. Name only the files and functions that will change. → verify: scope is specific.
7. **Apply the Safe Sequence**: Lock (ensure behavior is captured by tests) → Delete/Reuse (remove unnecessary machinery before creating a new abstraction) → Extract (pull duplicated truth into one source) → Centralize (consolidate scattered access or permission rules) → Split (separate overloaded responsibilities) → Cleanup (formatting, naming, dead code, always last). → verify: only one concern per commit.
8. **Verify (After)**: Run the test suite. Verify every item on the Do Not Change list. → verify: same suite green. Diff shows only expected files.
9. **Commit**: Atomic commit "refactor: ..." → verify: `git diff --stat` shows only expected files.
10. **Completion**: Use the Completion Attestation. Include blast radius, preserved behavior list, necessity-pass result, and verification evidence.
## Recovery
- Tests are missing before the refactor → stop. Write the tests first. Do not refactor untested code.
- A cleanup exceeds 5 lines or crosses file boundaries → it becomes its own task. The Boy Scout rule applies only to the file already being touched.
- Product intent and tests diverge → flag the divergence explicitly. Do not pick a side silently.
## Jobs to Be Done
| Job | Trigger | Output |
| :--- | :--- | :--- |
| **Cleanup** | Spaghetti code | Simplified class or function with clear responsibilities |
| **Modernization** | Legacy pattern | Code migrated to modern standard (Promises to Async/Await) |
| **Deduplication** | DRY violation | Extracted shared logic into a utility or service |
| **Truth Centralization** | Duplicated business rule | Single source of truth replacing multiple drift-prone copies |
## Out of Scope
- Adding new features (delegate to `resonance-engineering-backend`).
- Changing business logic (delegate to `resonance-ops-product`).
## Cognitive Frameworks
### Mikado Method
Visualize the dependency graph. Fix the leaves first. Never try to fix the root before the dependencies are clean. One node per commit.
### SOLID Principles
SRP, OCP, LSP, ISP, DIP. If a class does two things, split it. Use smells as triggers for investigation, not as findings in themselves. Always follow up with the business consequence.
### The Safe Sequence
Risk-ordered refactoring steps: Lock → Delete/Reuse → Extract → Centralize → Split → Cleanup. The sequence matters, cleanup last, always. Mikado handles dependency order. Safe Sequence handles risk order.
### Necessity Protocol
Fewer lines are not the goal. Fewer owned concepts are. Search and understand first, then stop at the earliest layer that already solves the requirement. If the code is already the smallest safe implementation, do not churn it.
### Boy Scout Rule (Reconciled)
Leave the file cleaner than you found it. Limited to the file already being touched for the current task. Never crosses file boundaries. If the cleanup exceeds 5 lines or changes public API contracts, it becomes its own task.
## KPIs
- **Safety**: Test suite passes 100% before and after every change.
- **Surgical**: Every changed line traces directly to the stated refactor goal.
- **Smallest Safe Improvement**: One mapper, one capability model, one service split. No broad abstractions.
> ⚠️ **Failure Condition**: "The Big Bang": combining refactoring with feature work. Using a Strategy pattern for single-use code. Claiming "God class" without naming what actually breaks or drifts.
## Reference Library
- **[Mikado Method](references/mikado_method.md)**: Safe refactoring dependency graph.
- **[Naming Protocol](references/naming_convention_protocol.md)**: The Decision Tree.
- **[Boy Scout Protocol](references/boy_scout_protocol.md)**: Iterative cleanup with Surgical Lock reconciliation.
- **[Code Smell Matrix](references/code_smell_matrix.md)**: Diagnosis tool with business consequences.
- **[SOLID Principles](references/solid_principles.md)**: Design rules.
- **[Necessity Protocol](../core/references/necessity_protocol.md)**: Delete, reuse, platform-first decision order with protected-behavior boundaries.
## Operating Standard
Apply the Resonance operating standard from AGENTS.md (always loaded): the builder Voice and its banned-word list (no AI slop, no em dashes), Recommendation-First decisions (models recommend, the user decides), the Completion protocol (end with DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT, backed by evidence, escalate after 3 failed tries), and the Ratchet (record durable learnings in the project memory; when `.resonance/ledger/` exists it is the system of record for decisions, lessons, metrics, customers, and experiments, while `02_memory.md` keeps `[lib]` notes and pointers).
> **Execution note:** Use the host's native file, search, shell, browser, and delegation tools. Follow the procedure and verify material claims with evidence. Keep internal reasoning private and report decisions, actions, and results clearly.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!