---
name: powershell-centered-project-development
description: Develop mixed-language projects where Windows PowerShell 5.1 or PowerShell 7 is the primary automation, orchestration, installation, build, or recovery layer.
---

# PowerShell-Centered Project Development

Use this skill when a project combines PowerShell with Python, Node, .NET, native tools, web assets, JSON/YAML, Markdown, or other formats.

1. Run `../../scripts/Resolve-PowerShellWorkbenchContext.ps1` from the active workspace and use its `Technologies` result as a fast initial map. It performs bounded nested discovery because PowerShell entrypoints commonly live in `Scripts`, `tools`, or module folders. Inspect repository manifests and entry points before making cross-stack decisions.
2. For work spanning several roots or a project-profile registry, use `../../scripts/Get-PowerShellWorkbenchProjectInventory.ps1`. Scan only explicit roots or registered scopes; never infer permission to crawl whole drives, cloud stores, archives, or protected paths.
3. Treat PowerShell 5.1 and PowerShell 7 as equal supported hosts. Keep shared scripts on their common syntax surface and isolate host-specific behavior behind explicit capability checks.
4. Preserve native component ownership: Python dependencies stay in Python metadata, Node dependencies in `package.json`, .NET dependencies in project files, and schema/config rules with their corresponding formats.
5. Use PowerShell as the orchestration boundary only where it adds value. Exchange structured data instead of scraping display output, preserve process exit codes, and avoid shell-constructed command strings when argument arrays are available.
6. Apply templates from `powershell-scaffold` for PowerShell, JSON/YAML, Markdown, and CI support. Do not force a PowerShell template onto a non-PowerShell component.
7. Route requested validation through `powershell-quality-gate`, selecting the smallest native checks for the changed technologies. MegaLinter is an optional broad aggregator, not a replacement for repository-declared tools.
8. Do not add, upgrade, or publish dependencies, packages, Actions, or external services unless the user explicitly requests that change.


## Generated-code checkpoint

For generated or adapted executable code, apply `../powershell-scaffold/references/component-pipeline.md` before execution. This mandatory registration/parser/hash checkpoint is explicitly requested by the user and takes precedence over the general opt-in rule for validation of generated code. Broader lint, security scans and operational execution retain their existing scope. Every member and assembly requires a component ID; unavailable parsers block execution through this workflow.