PSScriptTools: a PowerShell toolbox of console helpers with a generated PDF manual

What the module is: functions, variables and format files, not a framework

The abstract states that the module contains a collection of functions, variables and format files that you can use to enhance your PowerShell scripting work or get more done from a PowerShell prompt with less typing. The second half of that sentence is the more important one, because it describes the module's position accurately. This is not a PowerShell framework, it is a toolbox. Most of the commands are designed to work cross-platform, and the repository description adds that most should work cross-platform and cross-version, with operating system limitations handled on a per command basis. The project is on the PowerShell Gallery, the licence is MIT, and the primary language is PowerShell. The category list in the README runs to General Tools, File Tools, Editor Integrations, Graphical Tools, Hashtable Tools, Select Functions, Time Functions, Console Utilities, Format Functions, Scripting Tools, CIM Tools, ANSI Tools and Other Module Features.

Installing and the two restructurings the module has been through

Installation is a single command, Install-Module PSScriptTools, with a variant in PowerShell 7 that takes an optional scope and a force switch, and the documentation recommends installing from the PowerShell Gallery and not from GitHub. Removal is equally ordinary, using Get-Module with Remove-Module and Uninstall-Module with -AllVersions. The interesting history is in the design. Starting in v2.2.0 the module was restructured to better support Desktop and Core editions, and then, starting with v2.13.0, the module design has reverted: all module commands will be exported, and anything platform-specific should be handled on a per-command basis. The assumption stated is that you will be running the module in Windows PowerShell 5.1 or PowerShell 7. So the export behaviour changed twice, which is worth knowing if you have an existing profile that relies on selective exports.

Install-Module PSScriptTools

Get-Module PSScriptTools | Remove-Module
Uninstall-Module PSScriptTools -AllVersions

Documentation as a generated PDF, opened by a command

The documentation arrangement is unusual and worth noting before you go looking for a wiki. The contents of the README and other documentation can be viewed using the Open-PSScriptToolsHelp command, which will open a PDF of all module documentation, and you can also use Get-PSScriptTools to see a summary of module commands. The repository holds PSScriptToolsManual.pdf at the top level, a docs/ directory with a separate markdown file per command, and an en-us/ directory. The PDF is generated from those per-command files, which is why every command in the README is followed by a link to a docs page. One practical detail is flagged in the README, that code samples have been formatted to fit an 80-character width, and that some example code breaks lines without using line continuation characters, with the author trusting the reader to figure out how to run the example.

Get-ProcessTree: walking up the parent chain, with a graphical variant

Get-ProcessTree shows a hierarchy of processes, taking a process ID and iterating through its parents, and the oldest parent is listed first. The example output shows a WindowsTerminal process, a pwsh process and the powershell process that was queried. You can also get processes with the associated user name with -IncludeUserName, and the example shows sshd processes under SYSTEM and under a named user, and a cmd and a pwsh process below them. You can use any process property name, and the example pipes the result into Select-Object with a calculated Runtime property and a Path, then Format-Table, which shows the point of the command, that the output is a normal object pipeline rather than a fixed table. There is also Show-ProcessTree, an alternative that displays the tree graphically using ANSI styling, with a separate variant that requests user name information, and the command works cross-platform. The process tree commands require PowerShell 7.

PS C:\> Get-ProcessTree 10156

NPM(K)  PM(K)  WS(K)   CPU(s)    Id SI ProcessName                 StartTime
------  -----  -----   ------    -- -- -----------                 ---------
    41 190584 264452   249.17 18244  1 WindowsTerminal  7/21/2026 9:26:26 AM
   155 447784 591468 1,360.58 18320  1 pwsh             7/21/2026 9:26:27 AM
    30  61704  87424     0.31 10156  1 powershell      7/22/2026 12:54:09 PM

Get-MyCounter: the point is the pipeline, not the display

Get-MyCounter is an enhanced version of the legacy Get-Counter cmdlet, which is available on Windows platforms to retrieve performance counter data. The problem it addresses is formatting rather than collection. The information may be easy to read on the screen, but it is cumbersome to use in a pipelined expression, and Get-MyCounter takes the same information and writes a custom object to the pipeline that is easier to work with. You can pipe counters from Get-Counter into Get-MyCounter. The example pipes a counter path with a maximum of 60 samples at a 5 second interval against a named computer into Export-Csv, which is the kind of thing the legacy cmdlet's output shape makes awkward. The stated advantage over Get-Counter is that the performance data is easier to work with, and there is a remote example with the second screenshot.

Get-MyCounter '\IPv4\datagrams/sec' -MaxSamples 60 -SampleInterval 5 -computer SRV1 |
Export-CSV  c:\work\srv1_ipperf.csv -NoTypeInformation

Copy-HistoryCommand, and the shape of the console utilities

Copy-HistoryCommand copies the command line from a given PowerShell history item to the clipboard, with the default item being the last history item, so you can paste it into your following prompt to edit and re-run. It has an alias of ch, which is a good illustration of the module's approach to the console. A command that is used often enough gets a short alias, and the naming convention is the standard PowerShell one, a verb and a noun, so the module's commands sort predictably alongside the built-ins. The broader set of console utilities in the same category list covers the small things that make a prompt session less tedious, and the general tools are described as designed to either streamline common PowerShell tasks or add new functionality. The ANSI Tools category is the one to look at if your console work involves output that has to be legible rather than merely correct.

The samples folder, and the file layout of the module itself

The repository description notes that the Samples folder contains demonstration scripts, and the samples directory holds demonstration scripts, named for what they demonstrate: a counter markdown script, disk data, a file usage report, a status script, a top process script, a new password script and a process percent script. The top level layout of the module is more interesting than a typical script repository. Alongside PSScriptTools.psd1, the manifest, and PSScriptTools.psm1, the module file, there is a functions/ directory, a formats/ directory, a types/ directory, an optional-typeextensions/ directory, an icons/ directory, an images/ directory, a docs/ directory, a Tests/ directory, a samples/ directory, an archive/ directory and a changelog.md with a separate Archive-ChangeLog.md. The PSScriptToolData.json file and the psansifilemap.json are the data-driven parts, and the formats/ directory is what the abstract meant by format files.

Upkeep, releases and where a new user should start

The last push to the repository was on 2026-08-19, the repository is not archived, and the recent releases are v3.0.0 on 2025-03-26, v3.1.0 on 2026-07-14 and v3.2.0 on 2026-07-25. So the version line has moved past the v2.x restructuring entirely, and the two releases in July 2026 are close together, which suggests a period of active development after a long gap. The release tags carry a pSScriptTools prefix on the version name, so the PowerShell Gallery artefact and the GitHub tag are named slightly differently. The project asks for questions, problems and feedback in the GitHub Issues section and says feedback is greatly appreciated. For a new user the practical path is short: install from the Gallery, run Open-PSScriptToolsHelp to read the generated PDF, and run Get-PSScriptTools for a summary of the commands, since the module is a toolbox and the fastest way to judge it is to see the whole list in front of you.

Editorial conclusion

PSScriptTools suits a Windows administrator or developer who works in the PowerShell console daily and wants the small conveniences already written, from a process tree view to a clipboard copy of a history command, and who is willing to load a module for them. It is the wrong choice if you want a script with no dependencies, since a module import becomes part of your runtime requirement, and a poor fit for a mixed fleet if you assume every command works everywhere, because the module says most are designed to be cross-platform while platform specifics are handled per command and the process tree commands require PowerShell 7. Before adopting it, read the Compatibility section, install from the PowerShell Gallery rather than from GitHub as the documentation recommends, and run Open-PSScriptToolsHelp after installing to get the full generated manual.

Frequently asked questions

Official sources

1. Issues
2. jdhitsolutions/PSScriptTools on GitHub
3. License: MIT
4. README
5. Releases