GitHub Copilot for PowerShell: Write and Check Scripts

Use GitHub Copilot for PowerShell by stating the exact task, allowed paths, PowerShell version, and actions the script may perform, then reviewing every generated command before execution. Start with a read-only result you can inspect and test any changes on disposable examples first.

A script can be syntactically correct and still target the wrong files. fenbs can retain the operational restrictions people approved and the review prompts that helped last time. That record gives the next assistant a starting point without giving it permission to run an unchecked script.

What is a useful first PowerShell task?

1. Choose a narrow job, such as listing files that match a rule inside one test directory.
2. State the PowerShell version, operating system, required modules, and expected output.
3. Ask Copilot for a proposal and explanation without running commands or changing files.
4. Review the paths, filters, error handling, and every command with side effects.
5. Test representative examples, compare expected and actual results, and approve any later write operation separately.

GitHub’s Copilot Chat application card↗ (opens in a new tab) explains coding assistance and warns that generated code can be inaccurate or destructive. Begin with code you understand well enough to review. A request for a shorter script should never remove the checks that make its behavior clear.

What information should the prompt include?

Specify inputs and outputs as well as the operation. A report may need a root directory, an age cutoff, and columns for full path and size. Say whether recursion is allowed, how errors should be reported, and what to do with an empty result. Include a few fictional examples with their expected output.

Write a PowerShell script that lists .log files in C:\ScriptLab\Input.
Do not recurse or modify any file. Return FullName and Length.
Use the PowerShell version I specify and explain required modules.
Use explicit paths and explain what happens if the folder is missing.
Show the script and test cases only; do not run anything.

State restrictions positively enough to inspect: only this directory, only this extension, no recursion, no network requests. If the real task needs deletion or remote administration, separate selection from execution. First produce the exact target list and have a person confirm it before adding the write behavior.

Keep the continuing boundaries in fenbs Decisions and rules, so the next connected assistant can read the same approved scope before drafting a script.

How do you inspect paths and command behavior?

Read the script as a chain of effects. Identify where input enters, which files or systems it selects, what it changes, and what it reports. Expand aliases and inspect nested expressions. A familiar command name does not tell you what a computed argument or pipeline will actually target.

Microsoft’s Get-ChildItem reference↗ (opens in a new tab) documents path selection and recursion. Use literal path handling where filenames should not be treated as wildcard patterns. Keep selection logic explicit, and review how spaces, brackets, missing directories, and nested folders affect the result.

Get-ChildItem -LiteralPath 'C:\ScriptLab\Input' -Filter '*.log' -File |
  Select-Object FullName, Length

This example lists files without modifying them, and it does not search subdirectories. If your task requires a CSV report, ask for that as a separate proposed change and choose its destination explicitly. Confirm that exporting the report will not replace a file someone needs.

Does WhatIf make a generated script safe?

Only supported operations honor WhatIf, and a function must implement its checks correctly. Microsoft’s ShouldProcess guide↗ (opens in a new tab) explains how a function provides WhatIf and Confirm behavior. Adding an option named WhatIf is not proof that every side effect is guarded.

If Copilot proposes a function that changes files, inspect which statements sit behind its ShouldProcess check. Look for writes performed earlier, including directory creation, external programs, and network calls. Test the preview on disposable data and compare the directory before and after; the preview itself should not make the changes it describes.

For a simple reporting script, avoid introducing change operations at all. For an operational script, require a reviewed target list and a recovery plan appropriate to the task. A preview helps you inspect intent, while a test checks behavior. Keep both results separate in the work record.

Which tests reveal problems before real execution?

Create a small disposable directory with known contents. Include a matching file, a nonmatching file, an empty directory, a filename with spaces or brackets, and a nested directory. Write down which entries should appear. Then compare the actual output with that list rather than asking the assistant whether its own result looks right.

Microsoft documents PSScriptAnalyzer↗ (opens in a new tab) for analyzing script source and reporting diagnostics. Use it where it is already part of your tooling, but do not treat a clean report as proof that the script targets the right directory. That requires a behavioral check against your requirements.

What should stay available for the next script review?

Save the reason for the script, the approved scope, the relevant version assumptions, and the tests actually run. Put reusable restrictions in rules and task-specific results with the task. If a bracketed filename exposed a selection bug, record that cause and the example that should be included in future checks.

The GitHub Copilot app guide introduces the assistant, and the Copilot CLI guide covers terminal use. Nearby questions have their own guides: student use, business use, licensing, memory, and Copilot versus ChatGPT.

How to do this with fenbs

1. Create a free account and add a project for the operational work.
2. Record the paths, environments, and actions people approved in Decisions and rules, without including secrets.
3. Save the bounded drafting request and review questions in Skills and prompts.
4. Create review tasks, record actual test results, and save Where we left off with the next unresolved check.

fenbs does not execute or validate PowerShell scripts. It is not the right fit as a replacement for your editor, test environment, or endpoint administration tools. It helps when the approved restrictions and review work need to survive a session or a change of assistant.

Use the AI at work hub to find related workflows. Before closing a script task, leave enough evidence for another person to distinguish a reviewed draft from a script that was actually tested in its intended environment.