refactor-service

Run a diagnosis that maps the service boundary, traces the happy-path data flow, and records behavior invariants. Then produce a plan covering modularization, test coverage, lint/type checks, docs, and rollback risks before any implementation begins.

Capture behavior-preserving invariants such as schemas, output formats, idempotency, and retry semantics, and name the test that protects each one. Prefer small refactors with characterization tests around public behavior before moving internals.

No. It is planning-only and enforces a hard boundary: it reads files and runs safe diagnostic commands but never changes code, tests, configs, CI, or docs. Implementation happens only in a later, explicitly requested step.

It should list exact test files to add or update, fixtures needed, happy-path and failure-mode coverage, plus the exact ruff, pyright, test, and CI commands with expected passing results. Pre-existing failures are separated from failures the refactor must fix.

Avoid it for broad architecture brainstorming without a concrete service target, for generic bug-finding code reviews, for rewrites that change behavior from scratch, or for implementation after a plan is already approved.