Declarative Task Syntax​

The flagship feature of psake 5 is a new hashtable-based syntax for defining tasks. Rather than relying on positional parameters, you can now describe tasks as structured data with named, validated keys:

Task 'Build' @{
    DependsOn = 'Clean'
    Action    = { dotnet build -c $Configuration }
}

Every key is validated at compile time—typos like DependsOn or Action are caught before a single task runs. The original parameter-based syntax still works, so your existing build scripts don't need to change.

Two-Phase Compilation​

psake 5 separates build file loading from task execution. When you call Invoke-psake, the dependency graph is built first via a topological sort, and circular dependencies are caught at compile time rather than halfway through a run. This means faster, clearer feedback—and no more builds that silently fail mid-execution.

You can also use the new -CompileOnly parameter to inspect the build plan without running anything:

Invoke-psake -CompileOnly

This is especially useful in code review and CI pre-flight checks.

Local File-Based Caching​

For tasks that process files—compilation, transpilation, packaging—psake 5 introduces content-addressed caching. Declare Inputs and Outputs on a task, and psake will SHA256-hash the inputs to determine whether the task actually needs to run:

Task 'Build' @{
    Inputs  = 'src/**/*.cs', 'src/**/*.csproj'
    Outputs = 'bin/**/*.dll'
    Action  = { dotnet build -c $Configuration }
}

Cache state is stored in .psake/cache/. If nothing changed, the task is skipped and the build report marks it as Cached. To bypass caching for a single run, pass -NoCache:

Invoke-psake -NoCache

And to clear the cache entirely, use the new Clear-PsakeCache function.

Structured Build Results​

Invoke-psake now returns a PsakeBuildResult object containing per-task metrics, success status, duration, and error information. Scripting against build output no longer requires parsing console text:

$result = Invoke-psake
$result.Tasks | Where-Object Cached | Select-Object Name, Duration

The $psake.build_success variable is still set after every run, so existing CI scripts that check build status continue to work without modification.

CI-Native Output Formats​

Building for GitHub Actions? Pass -OutputFormat GitHubActions and psake will emit workflow annotations—warnings and errors that surface directly in pull request diffs. For pipelines that consume build data programmatically, -OutputFormat JSON outputs the full PsakeBuildResult as structured JSON.

The output format can also be set via the PSAKE_OUTPUT_FORMAT environment variable, making it easy to configure in CI without changing your build scripts.

Quiet Mode​

The new -Quiet parameter suppresses all console output while still returning the full PsakeBuildResult object—including complete error records for any failed tasks. No output is swallowed; it's simply not printed.

This is particularly valuable when psake is invoked by an LLM agent or AI coding tool. Console build logs are noisy: progress messages, separator lines, and timing output all burn through context that the model could spend on the actual problem. With -Quiet, the agent gets silence on stdout and a precise, structured result it can inspect programmatically:

$result = Invoke-psake -Quiet
if (-not $result.Success) {
    # Full error records are available—no log scraping needed
    $result.Tasks | Where-Object { $_.Error } | ForEach-Object {
        Write-Host "Task '$($_.Name)' failed: $($_.Error.Message)"
    }
}

Rather than parsing wall-of-text build output, the agent can check $result.Success, iterate $result.Tasks, and read $_.Error directly—structured data that maps cleanly to a tool call response. Pair this with -OutputFormat JSON if you need to pass the result across a process boundary or into a prompt.

New Testing APIs​

Two new functions let you inspect and test your build scripts without running a full build:

• Get-PsakeBuildPlan — Returns the full execution plan for a build file without running it. Inspect task order, dependencies, and caching configuration in tests.
• Test-PsakeTask — Executes a single named task with custom variable overrides. Great for unit-testing individual task logic in isolation.

Version Declaration​

Build files can now declare the minimum psake major version they require:

Version 5

If someone runs your build script on an older psake installation, they get a clear error instead of a confusing failure deep inside a task.

Hashtable Properties​

The Properties block gains a more concise hashtable syntax alongside the original scriptblock form:

Properties @{
    Configuration = 'Release'
    OutputDir     = './artifacts'
}

Both styles are supported and can be mixed within the same build file.

NO_COLOR Support​

psake 5 respects the $env:NO_COLOR convention for suppressing colored output. Set it in environments where ANSI escape codes cause issues—terminals without color support, log aggregators, or accessibility tools.

Breaking Changes​

psake 5 is a major version, and it includes a few breaking changes. Most build scripts will work without modification, but there are three things to check:

1. Rename default.ps1 to psakefile.ps1 — The default.ps1 fallback file name is no longer auto-detected.
2. Replace the wrapper scripts — psake.ps1 and psake.cmd are removed. Use Import-Module psake; Invoke-psake instead.
3. Update Framework calls — .NET Framework versions below 4.0 are no longer supported, and the default is now 4.7.2. The $framework global variable is removed; use Framework '4.7.2' instead.

Additionally, the minimum required PowerShell version is now 5.1 (raised from 3.0), and the output handler configuration properties have been removed in favor of the new -OutputFormat and -Quiet parameters.

Full details are in the migration guide.

Upgrading​

# Install from the PowerShell Gallery
Install-Module -Name psake -MinimumVersion 5.0.0 -Force

# Verify the version
Get-Module psake -ListAvailable | Select-Object Version

Then run your existing build to check for any breaking changes. For most projects, it'll just work.

psake 5 is the result of years of community feedback, and we're excited to see what you build with it. If you run into anything unexpected, open an issue. And if you're using the new features in interesting ways, we'd love to hear about it.

psake itself doesn't ship a build.ps1 — it's a best practice that most projects adopt. A typical starter script covers the basics: bootstrap installation, help output, build environment detection, and proper CI exit codes. But once you're running concurrent CI jobs, managing internal package feeds, or onboarding new contributors, a few gaps start to show.

The script below addresses those gaps with clear error handling, dynamic tab completion, CI-safe module imports, internal repository support, and PowerShellGet version pinning. I cover each pattern in detail in the full post on my blog — but here's the complete script. Copy it into your project and adjust the repository name and URL to match your environment:

[Diagnostics.CodeAnalysis.SuppressMessageAttribute(
    'PSReviewUnusedParameter',
    'Command',
    Justification = 'false positive'
)]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute(
    'PSReviewUnusedParameter',
    'Parameter',
    Justification = 'false positive'
)]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute(
    'PSReviewUnusedParameter',
    'CommandAst',
    Justification = 'false positive'
)]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute(
    'PSReviewUnusedParameter',
    'FakeBoundParams',
    Justification = 'false positive'
)]
[CmdletBinding(DefaultParameterSetName = 'task')]
param(
    [parameter(ParameterSetName = 'task', Position = 0)]
    [ArgumentCompleter( {
            param($Command, $Parameter, $WordToComplete, $CommandAst, $FakeBoundParams)
            try {
                Get-PSakeScriptTasks -BuildFile './psakeFile.ps1' -ErrorAction 'Stop' |
                Where-Object { $_.Name -like "$WordToComplete*" } |
                Select-Object -ExpandProperty 'Name'
            }
            catch {
                @()
            }
        })]
    [string[]]$Task = 'default',
    [switch]$Bootstrap,
    [parameter(ParameterSetName = 'Help')]
    [switch]$Help
)

$ErrorActionPreference = 'Stop'
$psakeFile = './psakeFile.ps1'

if ($Bootstrap) {
    # Patch TLS protocols for older Windows versions
    [System.Net.ServicePointManager]::SecurityProtocol = (
        [System.Net.ServicePointManager]::SecurityProtocol -bor
        [System.Net.SecurityProtocolType]::Tls12 -bor
        [System.Net.SecurityProtocolType]::Tls13
    )

    Get-PackageProvider -Name 'Nuget' -ForceBootstrap | Out-Null
    Set-PSRepository -Name 'PSGallery' -InstallationPolicy 'Trusted'

    # Pin PowerShellGet to v2
    $powerShellGetModule = Get-Module -Name 'PowerShellGet' -ListAvailable |
        Where-Object { $_.Version.Major -eq 2 } |
        Sort-Object -Property 'Version' -Descending |
        Select-Object -First 1

    $powerShellGetModuleParameters = @{
        Name           = 'PowerShellGet'
        MinimumVersion = '2.0.0'
        MaximumVersion = '2.99.99'
        Force          = $true
    }

    if (-not $powerShellGetModule) {
        Install-Module @powerShellGetModuleParameters -Scope 'CurrentUser' -AllowClobber
    }
    Import-Module @powerShellGetModuleParameters

    # Register internal repository (idempotent)
    $repositoryName = 'internal-nuget-repo'
    if (-not (Get-PSRepository -Name $repositoryName -ErrorAction 'SilentlyContinue')) {
        $repositoryUrl = "https://nuget.example.com/api/v2/$repositoryName"
        $registerPSRepositorySplat = @{
            Name                      = $repositoryName
            SourceLocation            = $repositoryUrl
            PublishLocation           = $repositoryUrl
            ScriptSourceLocation      = $repositoryUrl
            InstallationPolicy        = 'Trusted'
            PackageManagementProvider = 'NuGet'
        }
        Register-PSRepository @registerPSRepositorySplat
    }

    # Install PSDepend if missing
    if (-not (Get-Module -Name 'PSDepend' -ListAvailable)) {
        Install-Module -Name 'PSDepend' -Repository 'PSGallery' -Scope 'CurrentUser' -Force
    }

    # Try-import-first pattern
    $psDependParameters = @{
        Path          = $PSScriptRoot
        Recurse       = $False
        WarningAction = 'SilentlyContinue'
        Import        = $True
        Force         = $True
        ErrorAction   = 'Stop'
    }

    $importSucceeded = $false
    try {
        Invoke-PSDepend @psDependParameters
        $importSucceeded = $true
        Write-Verbose 'Successfully imported existing modules.' -Verbose
    }
    catch {
        Write-Verbose "Could not import all required modules: $_" -Verbose
        Write-Verbose 'Attempting to install missing or outdated dependencies...' -Verbose
    }

    if (-not $importSucceeded) {
        try {
            Invoke-PSDepend @psDependParameters -Install
        }
        catch {
            Write-Error "Failed to install and import required dependencies: $_"
            Write-Error 'This may be due to locked module files. Please restart the build environment or clear module locks.'
            if ($_.Exception.InnerException) {
                Write-Error "Inner exception: $($_.Exception.InnerException.Message)"
            }
            throw
        }
    }
}
else {
    if (-not (Get-Module -Name 'PSDepend' -ListAvailable)) {
        throw 'Missing dependencies. Please run with the "-Bootstrap" flag to install dependencies.'
    }
    Invoke-PSDepend -Path $PSScriptRoot -Recurse $False -WarningAction 'SilentlyContinue' -Import -Force
}

if ($PSCmdlet.ParameterSetName -eq 'Help') {
    Get-PSakeScriptTasks -buildFile $psakeFile |
        Format-Table -Property Name, Description, Alias, DependsOn
}
else {
    Set-BuildEnvironment -Force
    Invoke-psake -buildFile $psakeFile -taskList $Task -nologo
    exit ([int](-not $psake.build_success))
}

Why a VS Code Extension?​

A core part of our mission with psake is meeting developers where they already work. Whether that's through AI-assisted workflows with Agent Skills, CI/CD pipelines, or your daily editor—we want psake to feel native to your environment. With VS Code being the editor of choice for so many PowerShell developers, a dedicated extension was a natural next step.

What's in v1.0​

This isn't a minimal snippet pack. The v1.0 release is a full-featured integration that makes VS Code aware of your psake build system.

Task Provider​

The extension automatically detects tasks from your psakefile.ps1 and surfaces them in VS Code's built-in task system. Your default task maps to the Build group, so Ctrl+Shift+B just works. Tasks refresh automatically when you save your build file—no manual reload needed.

psake Tasks Explorer​

A dedicated sidebar panel in the Explorer view gives you an at-a-glance view of every task in your project, complete with descriptions and dependency chains. Click any task to navigate directly to its definition, or hit the run button to execute it immediately.

CodeLens Integration​

Every Task declaration in your build file gets a "Run Task" CodeLens action. See a task, run it—right from the editor gutter. It's the fastest path from reading build logic to executing it.

Smart Build Script Detection​

If your project uses a wrapper script like build.ps1 (a common pattern in the psake ecosystem), the extension detects it automatically and routes task execution through it. This means your bootstrapping, dependency installation, and any custom setup all run correctly—just as they would from the terminal.

tasks.json IntelliSense​

When you configure psake tasks in .vscode/tasks.json, the extension provides autocomplete for task names. Combined with the new "psake: Sync Tasks to tasks.json" command, you can quickly wire up your build tasks into VS Code's task runner with full IntelliSense support.

Nine Code Snippets​

Scaffolding new tasks and build file structures is faster with nine built-in snippets covering everything from basic task definitions to Properties, Include, Framework, FormatTaskName, TaskSetup, and TaskTearDown blocks.

Quick Start​

1. Install the psake extension from the VS Code Marketplace
2. Make sure you have the PowerShell extension installed
3. Open a project that contains a psakefile.ps1 or build.ps1
4. The extension activates automatically—check the Explorer sidebar for the psake Tasks panel

That's it. No configuration required—but there's plenty available if you need it.

Fully Configurable​

The extension works out of the box, but every aspect of its behavior can be tuned to fit your workflow. Toggle CodeLens on or off, point to a custom PowerShell executable, pass extra parameters to Invoke-psake or your build script, and customize shell arguments—all without restarting VS Code.

For the full list of settings, check out the VS Code extension docs.

Part of a Growing Ecosystem​

The VS Code extension joins a growing set of tools designed to make psake easy to use wherever you are:

• psake — The build automation engine
• PowerShellBuild — Common build tasks for PowerShell modules
• psake Agent Skill — AI-assisted psake expertise for Claude and GitHub Copilot
• psake VS Code Extension — First-class editor integration

We're committed to making psake feel at home in every part of your development workflow. If you have ideas for where psake should go next, open an issue or join the conversation.

Give the extension a try and let us know what you think!

PowerShellBuild Docs Are Now on the psake Site​

If you've been looking for guidance on using PowerShellBuild to streamline your PowerShell module builds, you no longer need to piece things together from the README alone. The psake docs site now has a dedicated PowerShellBuild section covering:

• Introduction — What PowerShellBuild is and how it relates to psake
• Getting Started — Installation and first-build walkthrough
• Configuration — Deep dive into $PSBPreference and how to customize every aspect of your build
• Task Reference — Complete listing of all available tasks and their dependencies
• Real-World Example — A practical end-to-end project setup

What's New in v0.8.0 — Authenticode Signing​

The headline feature in PowerShellBuild v0.8.0 is full Authenticode code-signing support for PowerShell modules. This was a highly requested capability, and it's now baked right into the standard build pipeline.

Three New Public Functions​

Get-PSBuildCertificate resolves a code-signing X509Certificate2 from five different sources:

• Auto — Automatically detects from environment variables or the certificate store
• Windows certificate store — With optional thumbprint filtering
• Base64-encoded PFX — From environment variables, ideal for CI/CD pipelines
• PFX file on disk — With optional password protection
• Pre-resolved certificate object — For custom providers like Azure Key Vault

Invoke-PSBuildModuleSigning signs your module files (.psd1, .psm1, .ps1) with Authenticode signatures. It supports configurable timestamp servers and hash algorithms including SHA256, SHA384, and SHA512.

New-PSBuildFileCatalog creates Windows catalog (.cat) files that record cryptographic hashes of your module's contents for tamper detection.

Four New Build Tasks​

These tasks slot into the existing build pipeline with proper dependency ordering: Build → SignModule → BuildCatalog → SignCatalog.

Certificate Sources​

PowerShellBuild supports four ways to supply a certificate, listed here in order of common use:

1. Automatic (CI/CD) — Base64 PFX in an env var

# Store your PFX as a base64 secret (e.g. GitHub Actions secret SIGNCERTIFICATE)
# PowerShellBuild picks it up automatically when Sign.Enabled = $true
$PSBPreference.Sign.Enabled = $true
# CertificateSource defaults to 'Auto' — done

2. Local dev — certificate store

$PSBPreference.Sign.Enabled           = $true
$PSBPreference.Sign.CertificateSource = 'Store'
# picks first valid, unexpired code-signing cert in Cert:\CurrentUser\My

# Or pin to a specific one by thumbprint:
$PSBPreference.Sign.CertificateSource = 'Thumbprint'
$PSBPreference.Sign.Thumbprint        = 'AB12CD34EF...'

3. PFX file on disk

$PSBPreference.Sign.Enabled           = $true
$PSBPreference.Sign.CertificateSource = 'PfxFile'
$PSBPreference.Sign.PfxFilePath       = './codesign.pfx'
$PSBPreference.Sign.PfxFilePassword   = (Read-Host -AsSecureString 'Password')

4. Pre-resolved object (Azure Key Vault, HSM, etc.)

# Get the cert however you like, then hand it directly:
$cert = Get-AzKeyVaultCertificate -VaultName 'MyVault' -Name 'CodeSignCert' |
    Get-AzKeyVaultSecret | ... # your Key Vault retrieval logic

$PSBPreference.Sign.Enabled     = $true
$PSBPreference.Sign.Certificate = $cert   # bypasses CertificateSource entirely

All of these go in your Properties {} block (psake) or before dot-sourcing (Invoke-Build), before the task file is loaded. To also sign before publishing:

$PSBPublishDependency = @('Sign')

All signing operations include platform checks (Windows-only) with appropriate warnings, and verbose logging throughout makes troubleshooting straightforward.

Get Started​

• Read the docs: Check out the PowerShellBuild documentation for a complete walkthrough
• Upgrade: Install-Module PowerShellBuild -RequiredVersion 0.8.0
• Release notes: v0.8.0 on GitHub
• Feedback: Open an issue on GitHub — we'd love to hear how you're using the signing tasks

What is the psake Agent Skill?​

The psake Agent Skill is part of our growing collection of LLM tools designed to enhance how developers work with psake. Built on the open Agent Skills standard, it provides AI assistants with deep knowledge of psake patterns, syntax, and best practices. This portable format means the same skill works across different AI platforms—whether you're using Claude, GitHub Copilot, or other compatible AI tools.

Key Features​

The skill includes four comprehensive knowledge components:

SKILL.md – Core psake fundamentals covering command syntax, task definitions, dependencies, and troubleshooting patterns. This ensures your AI assistant understands the basics before diving into more complex scenarios.

PowerShell Modules Reference – Detailed guidance on using PowerShellBuild for module development workflows, including task patterns, build configurations, and testing integration.

Build Types Reference – Practical patterns for .NET, Node.js, and Docker builds, providing real-world examples for different project types.

Advanced Reference – Coverage of sophisticated topics like dynamic task generation, custom logging implementations, and CI/CD pipeline integration.

What Can AI Assistants Do With This Skill?​

Once you've loaded the psake skill, your AI assistant can help with tasks like:

• Building complete psakefiles with integrated Pester testing frameworks
• Establishing build configurations for .NET solutions and PowerShell modules
• Implementing dynamic task generation from configuration files
• Troubleshooting build failures and dependency issues
• Integrating psake workflows into CI/CD pipelines
• Creating custom logging mechanisms
• Developing cross-platform build scripts

Getting Started​

The psake Agent Skill works with multiple AI platforms thanks to the open Agent Skills standard.

Using with Claude​

1. Visit the psake-llm-tools repository
2. Download the psake.skill file from the releases section
3. Upload it to Claude through the skills interface
4. Start building with AI-assisted psake expertise

Using with GitHub Copilot​

1. Download the psake.skill file from the repository
2. Follow the VS Code instructions for using shared skills
3. Configure the skill in your workspace or user settings
4. Access psake expertise directly in your editor

The same skill file works across both platforms, making it easy to maintain consistent AI assistance regardless of which tool you prefer.

Open Standard, Open Source​

By building on the Agent Skills open standard, we ensure that psake expertise is portable across AI platforms. As more tools adopt this standard, your investment in configuring the psake skill will continue to pay dividends across your entire development toolchain.

The psake-llm-tools repository is open source and welcomes community contributions. If you have patterns, examples, or improvements that would benefit other developers using psake with AI assistants, we'd love to see your pull requests.

Whether you're new to psake or a seasoned automation expert, the psake Agent Skill can help streamline your workflow and provide intelligent guidance when you need it most. Give it a try and let us know what you think!

Check out the project at github.com/psake/psake-llm-tools.

Latest Versions​

Since launching this documentation site, we haven't been great about announcing new versions here. You could say we've been in stealth mode (though we're definitely not that cool).

psake​

Back in October, we released psake 4.9.1, and since then we've merged several pull requests, including some fantastic community contributions.

Check out the psake Changelog for all the details.

The next release will introduce a new way to override the psake logging mechanism. This will allow teams to integrate additional logging frameworks or create improved CI/CD-specific workflows.

PowerShellBuild​

Just a few days ago, we updated PowerShellBuild - our collection of common tasks for psake and Invoke-Build - to support overriding task dependencies. We also added localization support (more on that below). This brings us to version 0.7.3 as our latest release. Since version 0.6.2, we've seen 4.5k downloads, and we hope to keep improving the project based on your feedback.

See the PowerShellBuild Changelog for complete details.

Welcome Our Newest Team Members​

You may have noticed them working on and reviewing code in our repositories, but we'd like to formally welcome Joshua Hendricks and Trent Blackburn as new members of the psake core team!

Joshua is our resident MVP who's well-known for presenting at PowerShell + DevOps Global Summit on building beautiful docs and sending notifications. He's a developer at Milestone Systems where he maintains their PowerShell module.

Trent currently develops PowerShell automations at Tesla, previously specialized in PowerShell at Amazon, and has also presented at the annual PowerShell + DevOps Global Summit.

Both bring incredible expertise to the team, and we're excited to have them aboard! If you're interested in contributing to psake, please consider opening an issue or submitting a pull request—we'd love to hear from you.

Expanding Global Accessibility with Localization​

psake has long had the framework in place for supporting localization (l10n), but until now has only been available in English. One of our key goals is making psake as accessible as possible for users worldwide.

To make community contributions easier, we've set up a Crowdin project that enables straightforward translation requests and suggestions.

With the Crowdin project now live, we have a streamlined pipeline for introducing new localized versions. We'd love your help in making psake available in more languages - please consider contributing translations!

This first iteration is composed of the original docs on the psake repository. I'll be slowly reviewing all the docs and updating them to make it easier for folks to get started.

In the near future, I'll be looking at more common CI/CD workflows and making sure we have good examples. Have suggestions? PR's are welcome!