powershell-scripting
Skill0 starsChanged 8 months agoMITView on GitHub
Use when creating, modifying, or refactoring PowerShell scripts that require production-quality standards including OOP architecture, guard-clause validation, fail-fast error handling, comprehensive parameter validation, and parameterized design for reusability.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Himeyama/DESIGNtheir own version, first seen Aug 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Himeyama/DESIGN★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adr-generationSkill
- bash-scriptingSkill
- browser-controlSkill
- github-actionsSkill
- gitignore-standardsSkill
- git-operationsSkill
- html-reportSkill
- java-developmentSkill
- mermaid-diagramsSkill
- meta-workspaceSkill
- project-backlogSkill
- project-documentationSkill
- project-setupSkill
- python-developmentSkill
- refinement-tribunalSkill
- skill-cli-developmentSkill
- technical-writingSkill
- testing-standardsSkill
- typescript-developmentSkill
- web-auth-bridgeSkill
- worktree-isolationSkill
- writing-ai-instructionsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 12 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 80
Use #region <Name>/#endregion for major logical sections (Constants, Classes, Helpers, Main)
- Distinctive: line 90
Default to FullScript when ambiguous
- Distinctive: line 96
Use Write-Verbose for diagnostics and Write-Information for user-facing status
- Distinctive: line 100
Use Write-Host for diagnostics
- Distinctive: line 107
Keep global scope free of procedural logic
- Very specific: line 109
Start with help including .SYNOPSIS, .DESCRIPTION, .PARAMETER (for each parameter), .EXAMPLE, .NOTES
- Very specific: line 110
Document all classes and methods with <# #>
- Distinctive: line 111
Use guard clauses and specific exception types
- Distinctive: line 112
Use error messages with process, error, cause, and solution
- Distinctive: line 113
Use Set-StrictMode -Version Latest unless disallowed
- Distinctive: line 123
Prefer one line, maximum five lines
- Distinctive: line 124
Avoid classes and doc blocks
- Distinctive: line 126
Use -WhatIf or -Confirm for destructive actions unless user opts out
- Distinctive: line 130
Create a full script scaffold
- Distinctive: line 152
No classes or documentation blocks
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PowerShell Script Development
Objective
Produce PowerShell solutions in two modes: full scripts for persisted automation and one-offs for ad-hoc execution. Full scripts must be OOP-first, parameterized, and documented; one-offs must be short and runnable as a one-liner when possible.
Scope
In-scope:
- New .ps1 scripts and refactors
- One-offs and one-liners
- OOP design, guard clauses, fail-fast errors
- Parameter validation and naming conventions
- Script-level documentation
Out-of-scope:
- Module manifests (.psd1)
- DSC resources
- Remoting configuration
- PowerShell Workflows
- Cross-platform PowerShell Core nuances
Inputs
Required inputs:
- Purpose and functional requirements
- Target output form: FullScript or OneOff
- New development or refactor
Optional inputs:
- Mode selection override
- Existing patterns to mirror
- Domain context (registry, file, API)
- Performance constraints
Assumptions:
- PowerShell 7+ on Windows
- Admin access when required
- Standard execution policy
Outputs
Format:
- FullScript: .ps1 file that passes validation
- OneOff: snippet (1 line preferred, max 5 lines)
Full Script Structure:
- Comment-based help at the top with
.SYNOPSIS,.DESCRIPTION,.PARAMETER(for each parameter),.EXAMPLE,.NOTES - Constants (global scope only)
- Classes (all business logic)
- Helper functions (all except Main)
- Main function (defined last)
- Single Main invocation
Files produced:
- FullScript:
[Name].ps1 - OneOff: no file unless requested
Formatting requirements (FullScript):
- PascalCase for parameters and variables
- PascalCase for class names
- Verb-Noun function names (validate with
Get-Verb) - Max 3 levels of nesting
- One blank line between functions/classes
- Guard clauses at function entry
- Use
#region <Name>/#endregionfor major logical sections (Constants, Classes, Helpers, Main)
Constraints
Conflict resolution: User requirements override defaults unless they violate safety or explicit MUST rules.
Mode selection rules:
- OneOff when user asks for a one-liner, quick command, or terminal snippet
- FullScript when user asks for a .ps1 file, reusable automation, or multi-step workflow
- Default to FullScript when ambiguous
Global MUST:
- Choose FullScript or OneOff and follow the mode rules
- Return objects unless formatting is explicitly requested
- Use Write-Verbose for diagnostics and Write-Information for user-facing status
Global MUST NOT:
- Use Write-Host for diagnostics
- Reimplement built-in cmdlets
FullScript MUST:
- Encapsulate business logic in classes
- Validate all parameters with attributes
- Keep global scope free of procedural logic
- Define Main last and invoke it once
- Start with help including
.SYNOPSIS,.DESCRIPTION,.PARAMETER(for each parameter),.EXAMPLE,.NOTES - Document all classes and methods with
<# #> - Use guard clauses and specific exception types
- Use error messages with process, error, cause, and solution
- Use Set-StrictMode -Version Latest unless disallowed
FullScript MUST NOT:
- Hard-code paths or configuration
- Use mid-function
return - Catch and ignore errors
OneOff MUST:
- Prefer one line, maximum five lines
- Avoid classes and doc blocks
- Use pipeline-friendly cmdlets
- Use -WhatIf or -Confirm for destructive actions unless user opts out
OneOff MUST NOT:
- Create a full script scaffold
- Add long-form comments
Procedure
- Select mode using the mode rules.
- FullScript: write script-level help, then structure constants, classes, helpers, Main, and invocation.
- OneOff: build the minimal pipeline and keep length within limits.
- Apply validation, guard clauses, error handling, and naming conventions.
Validation
Pass Conditions (FullScript):
- Structure matches the Full Script Structure list
- Help includes
.SYNOPSIS,.DESCRIPTION,.PARAMETER(for each parameter),.EXAMPLE,.NOTES - Parameters are validated; classes and methods are documented
- Max nesting depth is 3; strict mode is enabled
Pass Conditions (OneOff):
- One line when possible, never more than five lines
- No classes or documentation blocks
- -WhatIf or -Confirm used for destructive actions unless opted out
Failure Modes:
- FullScript violates structure, help, or validation rules
- OneOff exceeds five lines without justification
Examples
OneOff:
Get-ChildItem -Path $Path -File -Recurse | Sort-Object Length -Descending | Select-Object -First 5 FullName, LengthFullScript (help block only):
<#
.SYNOPSIS
Process items under a path.
.DESCRIPTION
Validates input, executes processing logic, and returns objects for downstream use.
.PARAMETER InputPath
Path to the items to process.
.EXAMPLE
.\Example.ps1 -InputPath "C:\\Data"
Processes items under C:\\Data.
.NOTES
Use for reusable automation. Requires read access to InputPath.
#>Persona
Persona: Production-quality PowerShell architect
You are a PowerShell architect with deep production experience. You prioritize explicit validation, parameterization, and strict structure. You choose maintainability over shortcuts and keep scripts predictable and testable.
References
- Modes and selection guide: references/modes.md
- Templates: references/templates.md
- Standards and patterns: references/standards.md
- Examples: references/examples.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

