proper

Compare the tactical and strategic paths explicitly: what each touches, effort, regression risk, and whether the next similar request becomes easier. The skill presents this comparison table and recommends a path, but the user makes the final call.

First diagnose why the feature is awkward by locating the friction point, such as a missing abstraction or hard-coded assumption. Then propose the minimal design change that makes the feature a small natural addition, and implement the refactoring before the feature itself.

Skip the strategic path for throwaway scripts, soon-to-be-deleted modules, or genuinely one-off requests where the tactical fix is honestly the right call. The skill explicitly acknowledges when no real friction exists rather than inventing refactorings.

No, it only produces a diagnosis and proposal; the user decides whether to proceed. Small refactorings are implemented directly after approval, while non-trivial work is handed off to the /mikado skill for safe incremental execution.

When the strategic path involves multiple prerequisite changes or breakage risk, the refactoring goal is framed as the end state and passed to /mikado. Mikado discovers prerequisites by attempting the change and reverting on failure, keeping each step safe.