Skip to content
Back to skills

Refactor

ASecurity

Refactor code safely — establish a green baseline, change in small steps, keep tests passing

  • 8 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 12, 2026
ai-agentsphpbashrefactoringgit

Security analysis

A100/100

Scanned September 12, 2026

npx -y skills add Chemaclass/satscribe --skill refactor --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Refactor?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Refactor
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/chemaclass-refactor/badge)](https://www.skillsdirectory.com/skills/chemaclass-refactor)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
description: Refactor code safely — establish a green baseline, change in small steps, keep tests passing
argument-hint: "[file-or-description]"
allowed-tools: "Read, Write, Edit, Glob, Grep, Bash(vendor/bin/phpunit *), Bash(composer *), Bash(git diff:*)"
---

# Refactor

Refactoring changes structure, never behavior. If behavior must change, that's a feature — use `/tdd` instead.

## Before touching anything

1. **Tests must exist** for the code being changed. If they don't, write characterization tests first — capture what the code *does* today, not what it should do.
2. **Establish a green baseline**:
   ```bash
   composer test
   ```
   Never refactor on red.

## Steps

3. **Name the smell** before choosing a technique.

   | Smell | Move |
   |---|---|
   | Long method | Extract method |
   | Large class (> 200 lines) | Extract collaborator |
   | Long parameter list (> 3) | Introduce a `Transfer` object |
   | Duplicated logic | Extract to a shared method or Domain value object |
   | Feature envy | Move the method to the data's owner |
   | Primitive obsession (`string $txid` everywhere) | Value object in `Domain/Data/` |
   | Growing `switch` on a type | Interface + implementations, bound in the provider |
   | `new` inside business logic | Inject the interface, bind in the ServiceProvider |
   | Query in an Action | Move it into the repository |
   | Comment explaining *what* | Rename until the comment is redundant |

4. **One refactoring at a time.** Run the narrow test after each:
   ```bash
   vendor/bin/phpunit tests/Unit/<Module>/
   ```

5. **Watch the layer boundaries while moving code** — extracting a class is the moment things drift. Interfaces land in `Domain/`, policy in `Application/`, adapters in `Infrastructure/`. Anything extracted from Domain must stay Laravel-free.

6. **Update the binding** if an extraction introduced a new interface.

7. **Full gate + style**:
   ```bash
   composer fix
   composer test
   ```

8. **Commit with `ref:`** — small and atomic, one refactoring per commit.

## Constraints

- Public behavior stays identical — tests must pass **unchanged**. Editing a test to make a refactor pass means the behavior changed.
- Do not mix a refactor with a feature or a fix in the same commit.
- Extracting a class for its own sake is not an improvement — name the smell it removes.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…