Comment-Based Help

Note

Complete reference for PowerShell comment-based help - the documentation system built into functions and scripts.

Overview

Comment-based help is PowerShell's built-in documentation system. It allows you to add structured help to your functions and scripts that integrates seamlessly with the Get-Help cmdlet.

What you get with comment-based help:

Self-documenting code
Standard help format across all PowerShell code
Works with Get-Help just like built-in cmdlets
No external files needed
Available in functions AND scripts

Why use it:

Makes your code easier to use and maintain
Follows PowerShell best practices
Helps others (and future you) understand your code
Professional and standard across the PowerShell ecosystem

For practical usage in your code:

Function help basics → Functions
Script help basics → Script Structure
Keyword reference → (this page)

All Help Keywords Reference

Quick reference table of all available help keywords:

Keyword	Purpose	Required?	Used In
`.SYNOPSIS`	One-line description	Recommended	Functions, Scripts
`.DESCRIPTION`	Detailed description	Recommended	Functions, Scripts
`.PARAMETER`	Describe each parameter	Recommended	Functions, Scripts
`.EXAMPLE`	Usage examples	Recommended	Functions, Scripts
`.INPUTS`	Pipeline input types	Optional	Functions, Scripts
`.OUTPUTS`	Return value types	Optional	Functions, Scripts
`.NOTES`	Additional info (author, version)	Optional	Functions, Scripts
`.LINK`	Related resources/URLs	Optional	Functions, Scripts
`.COMPONENT`	Component/module name	Rare	Functions, Scripts
`.ROLE`	Target role/audience	Rare	Functions, Scripts
`.FUNCTIONALITY`	Functionality description	Rare	Functions, Scripts
`.FORWARDHELPTARGETNAME`	Forward to another cmdlet	Advanced	Functions only
`.FORWARDHELPCATEGORY`	Category for forwarding	Advanced	Functions only
`.REMOTEHELPRUNSPACE`	Remote help runspace	Advanced	Functions only
`.EXTERNALHELP`	External XML help file	Advanced	Functions, Scripts

Keyword Details

.SYNOPSIS

Purpose: One-line summary of what the function/script does

Syntax:

.SYNOPSIS
Brief one-line description here

Best Practices:

Keep it to one sentence
Start with a verb (Gets, Sets, Creates, Tests, etc.)
Don't end with a period
Be specific but concise
Describe what it does, not how

Examples:

# Good - Clear and specific
.SYNOPSIS
Gets disk space information for specified drives

# Good - Action-oriented
.SYNOPSIS
Tests network connectivity to remote hosts

# Too vague
.SYNOPSIS
Gets information

# Too detailed (save for .DESCRIPTION)
.SYNOPSIS
Gets the disk space information including free space, used space,
total space, and percentage used for all specified drive letters
and optionally sends email alerts

.DESCRIPTION

Purpose: Detailed explanation of what the function/script does and how it works

Syntax:

.DESCRIPTION
Detailed multi-line description here.
Can span multiple paragraphs.

Second paragraph if needed.

Best Practices:

Explain what it does and why you'd use it
Mention important behavior or side effects
Note any prerequisites or requirements
Explain non-obvious functionality
Can be multiple paragraphs
More detail is better than less

Examples:

# Good - Comprehensive and helpful
.DESCRIPTION
Retrieves disk space information for one or more drive letters.
Returns free space, used space, and total capacity in gigabytes.

Optionally warns if free space falls below a specified threshold.
Useful for monitoring disk usage in automated scripts or scheduled tasks.

Requires administrative privileges for network drives.

# Good - Explains behavior
.DESCRIPTION
Tests network connectivity by attempting to ping remote hosts.
Unlike Test-Connection, this function provides detailed diagnostics
including DNS resolution time, latency statistics, and packet loss.

Returns a custom object for each tested host with pass/fail status
and detailed metrics. Failed connections include error details.

# Too brief (not helpful)
.DESCRIPTION
Gets disk space.

# Just repeating .SYNOPSIS (not helpful)
.DESCRIPTION
This function gets disk space information for specified drives.

.PARAMETER

Purpose: Describe each parameter the function/script accepts

Syntax:

.PARAMETER ParameterName
Description of what this parameter does.

.PARAMETER AnotherParameter
Description of this parameter.

Best Practices:

One .PARAMETER entry for each parameter
Explain what it does, not just repeat the name
Note valid values, ranges, or formats
Mention defaults if applicable
Explain pipeline behavior if relevant
Order should match parameter order

Examples:

# Good - Clear with details
.PARAMETER ComputerName
The name or IP address of the remote computer to query.
Accepts pipeline input. Defaults to localhost if not specified.

# Good - Notes validation and defaults
.PARAMETER ThresholdGB
Minimum free space in gigabytes before warning.
Must be between 1 and 1000. Default is 10GB.

# Good - Explains format expectations
.PARAMETER Date
Date to process in any format recognized by Get-Date.
Examples: "2025-01-15", "January 15, 2025", "1/15/2025"

# Good - Notes common values
.PARAMETER Protocol
Network protocol to test. Valid values: TCP, UDP, ICMP.
Default is TCP.

# Bad - Just repeats the name
.PARAMETER ThresholdGB
The threshold in GB

# Bad - Too vague
.PARAMETER Path
A path

# Good - Comprehensive
.PARAMETER Credential
PSCredential object for authentication to remote systems.
If not provided, uses current user's credentials.
Use Get-Credential to create: -Credential (Get-Credential)

.EXAMPLE

Purpose: Show real-world usage examples

Syntax:

.EXAMPLE
Command-Here
Description of what this example does.

.EXAMPLE
Another-Command -Parameter Value
Description of this second example.

Best Practices:

Include at least one example (more is better)
Show actual commands that work
Explain what each example does
Start simple, then show advanced usage
Cover common use cases
Include output if it helps clarity
Show pipeline examples if applicable

Examples:

# Good - Basic usage
.EXAMPLE
Get-DiskSpace -DriveLetter C
Gets free space information for C: drive.

# Good - Shows output
.EXAMPLE
Get-DiskSpace -DriveLetter C

Drive FreeSpaceGB UsedSpaceGB TotalSpaceGB
----- ----------- ----------- ------------
C            45.23      410.77       456.00

# Good - Advanced usage
.EXAMPLE
Get-DiskSpace -DriveLetter C -ThresholdGB 50 -Verbose
Gets C: drive space, warns if below 50GB, and shows detailed output.

# Good - Pipeline example
.EXAMPLE
'C','D','E' | Get-DiskSpace
Gets disk space for multiple drives via pipeline.

# Good - Real-world scenario
.EXAMPLE
Get-DiskSpace -DriveLetter C | Where-Object {$_.FreeSpaceGB -lt 10}
Checks C: drive and returns only if less than 10GB free.
Useful in monitoring scripts to detect low disk space.

# Good - Multiple parameters
.EXAMPLE
Get-DiskSpace -DriveLetter D -ThresholdGB 100 -SendEmail -EmailTo "admin@contoso.com"
Checks D: drive and sends email alert if free space is below 100GB.

# Bad - No explanation
.EXAMPLE
Get-DiskSpace -DriveLetter C

# Bad - Not a complete command
.EXAMPLE
-DriveLetter C

.INPUTS

Purpose: Describe what types can be piped to the function/script

Syntax:

.INPUTS
TypeName
Description of input type.

.INPUTS
AnotherTypeName
Description of another input type.

Best Practices:

Specify .NET type names when possible
Explain what properties are used
Note if pipeline input is not supported
Be specific about what's accepted

Examples:

# Good - Specific type
.INPUTS
System.String
Accepts drive letters as strings via pipeline.

# Good - Explains properties used
.INPUTS
System.Management.Automation.PSCustomObject
Accepts objects with ComputerName and Credential properties.

# Good - Multiple types
.INPUTS
System.String
Accepts computer names as strings.

.INPUTS
Microsoft.ActiveDirectory.Management.ADComputer
Accepts AD computer objects from Get-ADComputer.

# When no pipeline input
.INPUTS
None
This function does not accept pipeline input.

# Good - Detailed explanation
.INPUTS
System.IO.FileInfo
Accepts file objects from Get-ChildItem or Get-Item.
Uses the FullName property to determine the file path.

.OUTPUTS

Purpose: Describe what the function/script returns

Syntax:

.OUTPUTS
TypeName
Description of output type.

Best Practices:

Specify .NET type or custom object type
Describe key properties returned
Note if multiple types are possible
Explain when different types are returned

Examples:

# Good - Custom object with properties
.OUTPUTS
System.Management.Automation.PSCustomObject
Returns object with Drive, FreeSpaceGB, UsedSpaceGB, and TotalSpaceGB properties.

# Good - Simple type
.OUTPUTS
System.Boolean
Returns $true if disk space is above threshold, $false otherwise.

# Good - Multiple types based on conditions
.OUTPUTS
System.Management.Automation.PSCustomObject
Returns detailed disk information object when -Detailed switch is used.

.OUTPUTS
System.String
Returns simple formatted string when -Detailed is not specified.

# Good - Array output
.OUTPUTS
System.Object[]
Returns array of user objects, one for each user found.

# When no output
.OUTPUTS
None
This function does not return any output (performs action only).

.NOTES

Purpose: Additional information like author, version, changelog, requirements, etc.

Syntax:

.NOTES
Author: Your Name
Version: 1.2.0
Last Modified: 2025-12-16
Other notes here.

Best Practices:

Include author name
Version number
Last modified date
Dependencies or requirements
Known issues or limitations
Changelog for significant versions
License information if applicable

Examples:

# Good - Standard format
.NOTES
Author: Raymond Smith
Version: 2.0.1
Last Modified: 2025-12-16

Requires: PowerShell 5.1 or later
Requires: Administrator privileges for remote queries

# Good - With changelog
.NOTES
Author: Raymond Smith
Email: raymond@contoso.com
Version: 2.0.1
Last Modified: 2025-12-16

Requires: ActiveDirectory module
Requires: Read permissions on AD

Changelog:

- 2.0.1: Fixed threshold validation bug
- 2.0.0: Added pipeline support
- 1.5.0: Added email alerting
- 1.0.0: Initial release

# Good - With limitations
.NOTES
Author: IT Department
Version: 1.0.0
Created: 2025-11-15

Known Limitations:

- Does not work with network drives
- Maximum 100 users per query
- Requires internet connectivity for email alerts

# Good - With dependencies
.NOTES
Author: Raymond Smith
Version: 3.1.0

Dependencies:

- ImportExcel module (Install-Module ImportExcel)
- Exchange Online PowerShell module
- .NET Framework 4.7.2 or later

Tested on:

- Windows 10/11
- Windows Server 2019/2022
- PowerShell 5.1 and 7.x

.LINK

Purpose: Related resources, documentation URLs, or related cmdlets

Syntax:

.LINK
URL or cmdlet name

.LINK
Another URL or cmdlet

Best Practices:

Include related cmdlets
Link to official documentation
Link to GitHub/source if applicable
Each link on separate .LINK line
Put most relevant links first

Examples:

# Good - Related cmdlets
.LINK
Get-PSDrive

.LINK
Get-Volume

.LINK
Get-WmiObject

# Good - Documentation URLs
.LINK
https://docs.microsoft.com/powershell/scripting/learn/ps101/09-functions

.LINK
https://github.com/yourname/yourrepo

# Good - Comprehensive
.LINK
Get-ADUser

.LINK
Get-ADGroupMember

.LINK
https://docs.microsoft.com/powershell/module/activedirectory/

.LINK
https://github.com/contoso/ad-tools

# Can also use just cmdlet names
.LINK
Test-Connection

.LINK
Test-NetConnection

.COMPONENT

Purpose: Specifies the component or feature the function belongs to

Syntax:

.COMPONENT
Component name

When to use:

Large modules with many functions
Organizing related functions
Enterprise environments
Advanced help filtering

Examples:

.COMPONENT
DiskManagement

.COMPONENT
ActiveDirectory

.COMPONENT
NetworkDiagnostics

# Used with Get-Help filtering:
# Get-Help -Component DiskManagement

.ROLE

Purpose: Specifies the intended user role or audience

Syntax:

.ROLE
Target role

When to use:

Enterprise environments with role-based access
Documentation for different user levels
Filtering help by user type

Examples:

.ROLE
Administrator

.ROLE
HelpDesk

.ROLE
Developer

# Used with Get-Help filtering:
# Get-Help -Role Administrator

.FUNCTIONALITY

Purpose: Describes the intended use or functionality

Syntax:

.FUNCTIONALITY
Functionality description

When to use:

Categorizing functions by purpose
Advanced help organization
Large function libraries

Examples:

.FUNCTIONALITY
Monitors and reports disk space usage

.FUNCTIONALITY
User account provisioning and management

.FUNCTIONALITY
Network connectivity testing and diagnostics

# Used with Get-Help filtering:
# Get-Help -Functionality "disk space"

Advanced Keywords

The following keywords are for advanced scenarios and rarely used:

.FORWARDHELPTARGETNAME and .FORWARDHELPCATEGORY

Forwards help requests to another cmdlet (wrapper functions).

.FORWARDHELPTARGETNAME Get-Process
.FORWARDHELPCATEGORY Cmdlet

.REMOTEHELPRUNSPACE

Specifies remote help runspace (advanced remoting scenarios).

.EXTERNALHELP

Points to external XML help file (for compiled modules).

.EXTERNALHELP C:\MyModule\MyModule-help.xml

Note: Most users will never need these advanced keywords.

Complete Examples

Minimal Help (Quick Documentation)

For simple functions where you want basic documentation:

function Get-ServiceStatus {
    <#
    .SYNOPSIS
    Gets the status of a Windows service

    .PARAMETER ServiceName
    Name of the service to check

    .EXAMPLE
    Get-ServiceStatus -ServiceName "Spooler"
    Gets the status of the Print Spooler service.
    #>

    param(
        [Parameter(Mandatory=$true)]
        [string]$ServiceName
    )

    Get-Service -Name $ServiceName
}

Standard Help (Recommended)

This is the recommended level of documentation for most functions:

function Test-PortConnection {
    <#
    .SYNOPSIS
    Tests TCP port connectivity to a remote host

    .DESCRIPTION
    Attempts to establish a TCP connection to the specified port
    on a remote computer. Returns true if connection succeeds,
    false otherwise.

    Useful for checking if services are accessible before attempting
    to connect. Faster than Test-Connection for specific port testing.

    .PARAMETER ComputerName
    The hostname or IP address to test. Defaults to localhost.

    .PARAMETER Port
    The TCP port number to test. Common ports: 80 (HTTP),
    443 (HTTPS), 3389 (RDP), 445 (SMB), 22 (SSH).

    .PARAMETER TimeoutSeconds
    How long to wait for connection before timing out.
    Default is 2 seconds. Increase for slow networks.

    .EXAMPLE
    Test-PortConnection -ComputerName "server01" -Port 3389
    Tests if RDP (port 3389) is accessible on server01.

    .EXAMPLE
    Test-PortConnection -ComputerName "10.0.0.5" -Port 443 -TimeoutSeconds 5
    Tests HTTPS connectivity with 5-second timeout.

    .EXAMPLE
    "web01","web02","web03" | ForEach-Object { Test-PortConnection $_ -Port 80 }
    Tests HTTP port on multiple web servers.

    .INPUTS
    None. Does not accept pipeline input.

    .OUTPUTS
    System.Boolean
    Returns $true if port is open, $false if closed or unreachable.

    .NOTES
    Author: Raymond Smith
    Version: 1.0.0
    Requires: PowerShell 3.0 or later

    .LINK
    Test-Connection

    .LINK
    Test-NetConnection
    #>

    [CmdletBinding()]
    param(
        [string]$ComputerName = "localhost",

        [Parameter(Mandatory=$true)]
        [ValidateRange(1, 65535)]
        [int]$Port,

        [ValidateRange(1, 300)]
        [int]$TimeoutSeconds = 2
    )

    # Function implementation...
    try {
        $tcpClient = New-Object System.Net.Sockets.TcpClient
        $connect = $tcpClient.BeginConnect($ComputerName, $Port, $null, $null)
        $wait = $connect.AsyncWaitHandle.WaitOne($TimeoutSeconds * 1000, $false)

        if ($wait) {
            $tcpClient.EndConnect($connect)
            $tcpClient.Close()
            return $true
        }
        else {
            return $false
        }
    }
    catch {
        return $false
    }
    finally {
        if ($tcpClient) {
            $tcpClient.Dispose()
        }
    }
}

Comprehensive Help (All Keywords)

For important functions that will be widely used or shared:

function Get-ADUserReport {
    <#
    .SYNOPSIS
    Generates detailed Active Directory user report

    .DESCRIPTION
    Retrieves Active Directory user information and generates
    a comprehensive report including account status, group
    memberships, last logon time, and password age.

    Can filter by OU, group membership, or account status.
    Exports results to CSV, JSON, HTML, or displays in grid view.

    Queries multiple domain controllers to get most recent logon
    information. Handles large user sets efficiently with batching.

    .PARAMETER SearchBase
    Distinguished name of OU to search. Searches entire domain
    if not specified.

    Example: "OU=Sales,DC=contoso,DC=com"

    .PARAMETER IncludeDisabled
    Include disabled accounts in the report. By default, only
    enabled accounts are included.

    .PARAMETER GroupFilter
    Only include users who are members of this group.
    Can be group name or distinguished name.

    .PARAMETER ExportFormat
    Output format: CSV, JSON, HTML, or GridView.
    Default is GridView for interactive use.

    .PARAMETER OutputPath
    Path for exported file (CSV, JSON, or HTML).
    Required when using CSV, JSON, or HTML export format.
    Directory must exist.

    .PARAMETER IncludeGroups
    Include full group membership list for each user.
    This can significantly increase processing time for large result sets.

    .EXAMPLE
    Get-ADUserReport
    Displays report for all enabled users in a grid view.

    .EXAMPLE
    Get-ADUserReport -SearchBase "OU=Sales,DC=contoso,DC=com"
    Reports on all enabled users in Sales OU only.

    .EXAMPLE
    Get-ADUserReport -IncludeDisabled
    Reports on all users (enabled and disabled) in entire domain.

    .EXAMPLE
    Get-ADUserReport -GroupFilter "Domain Admins" -ExportFormat CSV -OutputPath "C:\Reports\admins.csv"
    Exports Domain Admins to CSV file.

    .EXAMPLE
    Get-ADUserReport -SearchBase "OU=IT,DC=contoso,DC=com" -IncludeGroups -ExportFormat HTML -OutputPath "C:\Reports\it-users.html"
    Creates HTML report of IT department users with full group membership.

    .INPUTS
    System.String
    Accepts SearchBase Distinguished Names via pipeline.

    .OUTPUTS
    System.Management.Automation.PSCustomObject
    Returns objects with properties: Username, DisplayName, Email,
    Enabled, LastLogon, PasswordAge, Department, Manager, Groups (if -IncludeGroups).

    .NOTES
    Author: Raymond Smith
    Email: raymond@contoso.com
    Version: 2.1.0
    Last Modified: 2025-12-16

    Requires: ActiveDirectory PowerShell module
    Requires: Appropriate AD read permissions
    Requires: PowerShell 5.1 or later

    Performance: Large queries (>1000 users) may take several minutes
    when -IncludeGroups is specified.

    Changelog:

    - 2.1.0: Added HTML export support
    - 2.0.0: Added group filtering and membership
    - 1.5.0: Improved performance with batching
    - 1.0.0: Initial release

    .LINK
    Get-ADUser

    .LINK
    Get-ADGroupMember

    .LINK
    https://docs.microsoft.com/powershell/module/activedirectory/

    .LINK
    https://github.com/contoso/ad-tools

    .COMPONENT
    ActiveDirectory

    .ROLE
    Administrator

    .FUNCTIONALITY
    Active Directory user reporting and auditing
    #>

    [CmdletBinding()]
    param(
        [Parameter(ValueFromPipeline=$true)]
        [string]$SearchBase,

        [switch]$IncludeDisabled,

        [string]$GroupFilter,

        [ValidateSet('CSV', 'JSON', 'HTML', 'GridView')]
        [string]$ExportFormat = 'GridView',

        [ValidateScript({
            if ($_ -and -not (Test-Path (Split-Path $_))) {
                throw "Directory does not exist: $(Split-Path $_)"
            }
            $true
        })]
        [string]$OutputPath,

        [switch]$IncludeGroups
    )

    begin {
        # Validate OutputPath is provided for file exports
        if ($ExportFormat -in 'CSV','JSON','HTML' -and -not $OutputPath) {
            throw "OutputPath is required when using $ExportFormat format"
        }

        # Import AD module
        if (-not (Get-Module -Name ActiveDirectory)) {
            Import-Module ActiveDirectory -ErrorAction Stop
        }

        Write-Verbose "Starting AD user report generation..."
        $results = @()
    }

    process {
        # Function implementation...
        # (Implementation code would go here)
    }

    end {
        Write-Verbose "Report generation complete. Found $($results.Count) users."

        # Export based on format
        switch ($ExportFormat) {
            'CSV' {
                $results | Export-Csv -Path $OutputPath -NoTypeInformation
                Write-Verbose "Report exported to: $OutputPath"
            }
            'JSON' {
                $results | ConvertTo-Json -Depth 3 | Out-File -FilePath $OutputPath
                Write-Verbose "Report exported to: $OutputPath"
            }
            'HTML' {
                $results | ConvertTo-Html | Out-File -FilePath $OutputPath
                Write-Verbose "Report exported to: $OutputPath"
            }
            'GridView' {
                $results | Out-GridView -Title "AD User Report"
            }
        }
    }
}

Placement Options

Functions: Three Placement Styles

Style 1: Inside Function, at Top (Most Common)

This is the recommended and most common style:

function Get-Data {
    <#
    .SYNOPSIS
    Gets data from source

    .PARAMETER Name
    Name of data to retrieve
    #>

    param(
        [string]$Name
    )

    # Function code here...
}

Pros:

Most readable
Help is close to parameters
Standard convention
Works in all scenarios

Style 2: Before Function Keyword

Acceptable but less common:

<#
.SYNOPSIS
Gets data from source

.PARAMETER Name
Name of data to retrieve
#>
function Get-Data {
    param(
        [string]$Name
    )

    # Function code here...
}

Pros:

Separates help from code
Good for very long help blocks

Cons:

Less common
Help is separated from parameters
Can be missed when reading code

Style 3: At End of Function (Rare)

Rarely used:

function Get-Data {
    param(
        [string]$Name
    )

    # Function code here...

    <#
    .SYNOPSIS
    Gets data from source

    .PARAMETER Name
    Name of data to retrieve
    #>
}

Cons:

Unusual and unexpected
Help is far from parameters
Not recommended

When to use: Almost never. Only if you have a specific reason.

Scripts: Must Be at Top

For scripts, help MUST come at the very beginning, before the param() block:

<#
.SYNOPSIS
Backs up files to archive location

.PARAMETER SourcePath
Path to files to backup

.EXAMPLE
.\Backup-Files.ps1 -SourcePath "C:\Data"
#>

param(
    [Parameter(Mandatory=$true)]
    [string]$SourcePath
)

# Script code here...

Important: Help must be before param() block or it won't work!

Best Practices

Writing Effective Help

1. Always Include Minimum Set:

.SYNOPSIS - Always
.DESCRIPTION - Always
.PARAMETER - For each parameter
.EXAMPLE - At least one

2. Examples Are Critical:

Show real, working commands
Cover common use cases
Progress from simple to complex
Explain what each example does
Include expected output when helpful

3. Be Specific:

Don't just repeat parameter names
Explain WHY someone would use it
Note important behavior or gotchas
Document defaults clearly

4. Keep Updated:

Update help when function changes
Version your functions in .NOTES
Document breaking changes
Note deprecations

5. Think About Users:

What would YOU want to know?
What questions will people ask?
What mistakes might they make?
What are the common use cases?

Testing Your Help

Always test your help after writing it:

# View help for your function
Get-Help Get-MyFunction

# View detailed help
Get-Help Get-MyFunction -Full

# View just examples
Get-Help Get-MyFunction -Examples

# View just parameters
Get-Help Get-MyFunction -Parameter *

# View specific parameter
Get-Help Get-MyFunction -Parameter ComputerName

# View online (if .LINK provided)
Get-Help Get-MyFunction -Online

Help Writing Checklist

Before considering your help complete, verify:

Common Mistakes to Avoid

❌ Don't:

Skip documentation ("I'll add it later")
Copy-paste without updating
Use vague descriptions
Forget to document parameters
Write help for yourself instead of users
Include only one example
Forget to update help when code changes
Use unclear or wrong type names

✅ Do:

Write help as you write the function
Include realistic examples
Explain non-obvious behavior
Document defaults and validation
Test your help with Get-Help
Think about your audience
Include multiple examples
Keep help up to date

Functions - Practical function help usage
Script Structure - Script help and organization
Help System - Using Get-Help to find and read help

Comment-Based Help

Overview

Quick Navigation

All Help Keywords Reference

Keyword Details

.SYNOPSIS

.DESCRIPTION

.PARAMETER

.EXAMPLE

.INPUTS

.OUTPUTS

.NOTES

.LINK

.COMPONENT

.ROLE

.FUNCTIONALITY

Advanced Keywords

.FORWARDHELPTARGETNAME and .FORWARDHELPCATEGORY

.REMOTEHELPRUNSPACE

.EXTERNALHELP

Complete Examples

Minimal Help (Quick Documentation)

Standard Help (Recommended)

Comprehensive Help (All Keywords)

Placement Options

Functions: Three Placement Styles

Scripts: Must Be at Top

Best Practices

Writing Effective Help

Testing Your Help

Help Writing Checklist

Common Mistakes to Avoid

Additional Resources

Comment-Based Help

Overview

Quick Navigation

All Help Keywords Reference

Keyword Details

.SYNOPSIS

.DESCRIPTION

.PARAMETER

.EXAMPLE

.INPUTS

.OUTPUTS

.NOTES

.LINK

.COMPONENT

.ROLE

.FUNCTIONALITY

Advanced Keywords

.FORWARDHELPTARGETNAME and .FORWARDHELPCATEGORY

.REMOTEHELPRUNSPACE

.EXTERNALHELP

Complete Examples

Minimal Help (Quick Documentation)

Standard Help (Recommended)

Comprehensive Help (All Keywords)

Placement Options

Functions: Three Placement Styles

Scripts: Must Be at Top

Best Practices

Writing Effective Help

Testing Your Help

Help Writing Checklist

Common Mistakes to Avoid

Related Topics

Additional Resources