PowerShell Refactor Skill
Intent
Use this skill to improve an existing PowerShell script that already works or mostly works but needs cleanup. The goal is to make the code smaller, clearer, more idiomatic, and easier to maintain without introducing unnecessary abstractions or changing the script's job.
Use When
- A PowerShell script feels repetitive, bloated, inconsistent, or hard to follow
- Function names, parameter names, or output patterns need to be standardized
- The user wants a script simplified, tightened, cleaned up, or refactored
- The script should be aligned with practical PowerShell conventions for real admin automation
Do Not Use When
- The main task is to create a brand new script from scratch
- The request is mostly about documentation, README writing, or tutorial content
- The user wants a major architecture redesign instead of a focused refactor
- The script's expected behavior is unclear and changing it would be risky
Workflow
- Read the existing script first and identify the real behavior that must stay intact.
- Find the highest value cleanup targets:
- duplicated logic
- dead code
- inconsistent naming
- unclear control flow
- noisy error handling
- unnecessary wrappers or abstractions
- Refactor in place with the smallest set of edits that materially improves the script.
- Prefer native PowerShell patterns:
- approved verbs
- clear parameter blocks
- pipeline-aware logic when it adds value
try and catch only where they improve control and diagnostics
Write-Verbose, Write-Warning, and structured output instead of ad hoc console noise
- Keep function boundaries practical. Split code only when it improves readability or reuse in a clear way.
- Recheck for behavior drift, naming consistency, and obvious lint or test issues before finishing.
Scope Presets
Let the user control how aggressive the pass is. Default to full cleanup when no preset is named:
naming only: rename functions to approved verbs, standardize parameter and variable casing, touch nothing else
deduplication only: collapse repeated logic into shared functions or loops, keep all names and structure otherwise
full cleanup: the complete workflow above
When the user names a preset, stay inside it even when other cleanup targets are visible; list the out-of-scope findings at the end instead of fixing them.
PSScriptAnalyzer Alignment
Run Invoke-ScriptAnalyzer on the script before and after when it is available, honoring any PSScriptAnalyzerSettings.psd1 in the repo. Fix the violations that fall inside the chosen scope preset, and list any remaining ones with a one-line reason they were left, such as a deliberate Write-Host for interactive output. The refactor should never introduce new violations.
Change Summary
End every refactor with a before-and-after summary so the user can review the pass at a glance:
Refactor Summary
- Behavior preserved: [yes / exceptions explicitly listed]
- Lines: [before] -> [after]
- Changes:
- [each behavior-preserving change in one line, e.g. "merged 3 duplicate retry blocks into Invoke-WithRetry"]
- Analyzer: [violations fixed] fixed, [count] remaining (listed above)
- Out of scope findings: [anything noticed but not touched]
Constraints
- Preserve the script's intended behavior unless the user explicitly asks for a behavior change
- Prefer editing existing files over creating new ones
- Remove obsolete code instead of keeping compatibility shims
- Do not add layers, helper classes, or extra modules unless the current script clearly needs them
- Keep output, parameters, and side effects predictable
- Use comments only where the logic would otherwise be hard to follow
- If a destructive or high risk action is present, preserve or improve safety controls such as
ShouldProcess, confirmation, or validation
References
shared/skill-standard.md
shared/naming-conventions.md
- Existing repo patterns in the target script's project
Help And Examples
Use this skill when the user already has a PowerShell script and wants it cleaned up, simplified, or standardized.
Minimum useful input:
- the
.ps1 or .psm1 file to refactor
- the behavior that must stay the same
- any style constraints such as approved verbs, no comments, or keeping it single file
Example prompts:
Refactor this PowerShell script to reduce duplication and make the error handling cleaner, but keep the same output and parameters.
Tighten this Intune reporting script. Keep it as one file. Rename functions to approved verbs and remove unnecessary abstraction.
Clean up this PowerShell module and standardize the parameter blocks without changing how the commands behave.
Validation Checklist
- The refactor preserves the intended behavior of the original script
- Naming, structure, and flow are more consistent than before
- Unnecessary duplication or dead code has been removed
- The result uses practical PowerShell conventions instead of generic abstractions
- Any tests, lint checks, or quick validation steps relevant to the target repo still pass
1---2name: powershell-refactor3description: Refactor existing PowerShell scripts to simplify flow, reduce duplication, standardize naming and structure, and tighten behavior without changing the intended outcome.4---56# PowerShell Refactor Skill78## Intent910Use this skill to improve an existing PowerShell script that already works or mostly works but needs cleanup. The goal is to make the code smaller, clearer, more idiomatic, and easier to maintain without introducing unnecessary abstractions or changing the script's job.1112## Use When1314- A PowerShell script feels repetitive, bloated, inconsistent, or hard to follow15- Function names, parameter names, or output patterns need to be standardized16- The user wants a script simplified, tightened, cleaned up, or refactored17- The script should be aligned with practical PowerShell conventions for real admin automation1819## Do Not Use When2021- The main task is to create a brand new script from scratch22- The request is mostly about documentation, README writing, or tutorial content23- The user wants a major architecture redesign instead of a focused refactor24- The script's expected behavior is unclear and changing it would be risky2526## Workflow27281. Read the existing script first and identify the real behavior that must stay intact.292. Find the highest value cleanup targets:30 - duplicated logic31 - dead code32 - inconsistent naming33 - unclear control flow34 - noisy error handling35 - unnecessary wrappers or abstractions363. Refactor in place with the smallest set of edits that materially improves the script.374. Prefer native PowerShell patterns:38 - approved verbs39 - clear parameter blocks40 - pipeline-aware logic when it adds value41 - `try` and `catch` only where they improve control and diagnostics42 - `Write-Verbose`, `Write-Warning`, and structured output instead of ad hoc console noise435. Keep function boundaries practical. Split code only when it improves readability or reuse in a clear way.446. Recheck for behavior drift, naming consistency, and obvious lint or test issues before finishing.4546## Scope Presets4748Let the user control how aggressive the pass is. Default to `full cleanup` when no preset is named:4950- `naming only`: rename functions to approved verbs, standardize parameter and variable casing, touch nothing else51- `deduplication only`: collapse repeated logic into shared functions or loops, keep all names and structure otherwise52- `full cleanup`: the complete workflow above5354When the user names a preset, stay inside it even when other cleanup targets are visible; list the out-of-scope findings at the end instead of fixing them.5556## PSScriptAnalyzer Alignment5758Run `Invoke-ScriptAnalyzer` on the script before and after when it is available, honoring any `PSScriptAnalyzerSettings.psd1` in the repo. Fix the violations that fall inside the chosen scope preset, and list any remaining ones with a one-line reason they were left, such as a deliberate `Write-Host` for interactive output. The refactor should never introduce new violations.5960## Change Summary6162End every refactor with a before-and-after summary so the user can review the pass at a glance:6364```text65Refactor Summary66- Behavior preserved: [yes / exceptions explicitly listed]67- Lines: [before] -> [after]68- Changes:69 - [each behavior-preserving change in one line, e.g. "merged 3 duplicate retry blocks into Invoke-WithRetry"]70- Analyzer: [violations fixed] fixed, [count] remaining (listed above)71- Out of scope findings: [anything noticed but not touched]72```7374## Constraints7576- Preserve the script's intended behavior unless the user explicitly asks for a behavior change77- Prefer editing existing files over creating new ones78- Remove obsolete code instead of keeping compatibility shims79- Do not add layers, helper classes, or extra modules unless the current script clearly needs them80- Keep output, parameters, and side effects predictable81- Use comments only where the logic would otherwise be hard to follow82- If a destructive or high risk action is present, preserve or improve safety controls such as `ShouldProcess`, confirmation, or validation8384## References8586- `shared/skill-standard.md`87- `shared/naming-conventions.md`88- Existing repo patterns in the target script's project8990## Help And Examples9192Use this skill when the user already has a PowerShell script and wants it cleaned up, simplified, or standardized.9394Minimum useful input:9596- the `.ps1` or `.psm1` file to refactor97- the behavior that must stay the same98- any style constraints such as approved verbs, no comments, or keeping it single file99100Example prompts:101102```text103Refactor this PowerShell script to reduce duplication and make the error handling cleaner, but keep the same output and parameters.104```105106```text107Tighten this Intune reporting script. Keep it as one file. Rename functions to approved verbs and remove unnecessary abstraction.108```109110```text111Clean up this PowerShell module and standardize the parameter blocks without changing how the commands behave.112```113114## Validation Checklist115116- The refactor preserves the intended behavior of the original script117- Naming, structure, and flow are more consistent than before118- Unnecessary duplication or dead code has been removed119- The result uses practical PowerShell conventions instead of generic abstractions120- Any tests, lint checks, or quick validation steps relevant to the target repo still pass