Architecture refactoring strategy
Skill Xopoko/plug-n-skills/plugins/architecture-intelligence/skills/architecture-refactoring-strategy
Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.
npx -y skills add Xopoko/plug-n-skills --skill architecture-refactoring-strategyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when code changes need staged structural design: boundary extraction, modularization, dependency inversion, migrations, anti-corruption layers, tests, rollout gates, and rollback.
SKILL.md
2.9 KB, as published. Nobody here has run it
Architecture Refactoring Strategy
Use when improving architecture needs staged code change rather than a one-shot rewrite.
Inputs
Gather current architecture map, hot paths, structure metrics, runtime topology, ownership topology, target quality attribute, constraints, tests, production signals, failure history, ADRs, and architecture principles.
For architecture-significant structural changes, require a baseline before code edits: dirty-tree state, observed boundary evidence, pre-refactor probe or explicit reason it was skipped, representative change/runtime scenario, and the focused skills used from the router.
Patterns
Use the smallest safe pattern:
- characterization tests before moving behavior;
- branch by abstraction behind stable interface;
- strangler fig for extracting flows;
- anti-corruption layer for old model or external API coupling;
- facade/adapter to stabilize callers;
- parallel run, shadow read, dual write for data migration risk;
- feature flag or compatibility window for reversibility;
- expand-contract migration for schema/API changes.
Multi-Objective Frame
For every refactor name:
- primary quality attribute to improve;
- secondary attributes that must not regress;
- accepted tradeoff and threshold;
- evidence signal before and after each slice.
Do not recommend a pattern without the measurable quality attribute it improves.
Slicing
Prefer one validated slice at a time: user flow, bounded-context seam, data ownership edge, dependency cycle, package boundary, ownership boundary, cross-owned dependency edge, runtime dependency, deployment boundary.
Avoid platform rewrites that do not reduce a named risk in the next increment.
Plan Format
Return:
- Current architecture risk.
- Target boundary or quality attribute.
- Migration slices in order.
- Guardrails and fitness functions.
- Tests and observability before each slice.
- Rollback path and stop conditions.
- ADRs to create/update.
- Quality-attribute tradeoffs accepted.
Keep behavior-preserving moves separate from behavior changes. Lock public interfaces before moving internals. Treat data ownership changes as release/operations work.
Proof Bundle
After implementation, report:
- architecture boundary moved or protected;
- before/after evidence, including post-probe when static structure was used;
- guardrail tests or fitness functions added;
- docs/ADR updated or explicit reason none was needed;
- runtime smoke, release gate, or explicit skip reason;
- dirty-tree separation for pre-existing changes;
- specialized architecture skills used and skipped with reasons.
Use architecture_intelligence.refactor_report.v1 when the result should be saved or reviewed later.