Architecture refactor guidance
Skill motao123/dev-workflow-kit/architecture-refactor-guidance
21 markdown-first software delivery workflow skills for Claude Code, Codex, and compatible agents. Standalone skill kit covering planning, debugging, CI, review, security, rollout, performance, data quality, and post-incident workflows.
npx -y skills add motao123/dev-workflow-kit --skill architecture-refactor-guidanceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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 the core problem is structural change: boundaries, coupling, module seams, interface extraction, or safe refactor sequencing. This skill helps decide how to reshape code without turning implementation into guesswork.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.0 KB, as published. Nobody here has run it
Architecture Refactor Guidance
Use this skill when the main uncertainty is structural rather than purely functional.
Trigger Conditions
Use this skill when:
- the user asks how to split, extract, or reorganize a module
- a refactor needs safer sequencing before implementation starts
- coupling, boundaries, ownership, or interfaces are the real issue
- a migration or structural cleanup should be staged carefully
- the code works today, but the structure is becoming the bottleneck
Do not use this skill for generic feature planning, direct implementation, or root-cause debugging.
Workflow
- Read the current structure and identify the relevant boundaries.
- Find the main structural pain points: coupling, leakage, unstable contracts, or oversized modules.
- Identify seams where change can happen safely.
- Choose the safest staging order for the refactor.
- Define how behavior preservation will be verified.
- Recommend the next implementation path.
Output
For non-trivial work, provide:
- current structural assessment
- pain points and risks
- proposed boundaries or seams
- staged refactor order
- preservation and verification strategy
- recommended next step
Coordination
After structural guidance:
- continue in the active implementation workflow for the implementation itself
- use
planningif broader scope or acceptance is still unclear - use
ship-readinessbefore merging large structural changes
Invocation Examples
- "Use architecture-refactor-guidance before we split this module into cleaner boundaries."
- "Use architecture-refactor-guidance to decide how to stage this refactor safely."
- "Use architecture-refactor-guidance to reduce coupling here without changing behavior."