Here's a real scenario. You need a script that monitors a specific Windows service, restarts it if it's stopped, and logs each restart with a timestamp to a file. You could Google that for 20 minutes, piecing together Stack Overflow answers that are half-broken on Server 2022. Or you describe it to Claude in one sentence and have working code in under a minute.

I've been doing the second thing for months. Here's the honest workflow.

The basic pattern

One rule I've learned: be specific about the environment. "Write me a PowerShell script" gets you generic code. "Write me a PowerShell script for Windows Server 2022 that..." gets you something you can actually run without three edits first.

My prompt template:

Write a PowerShell script for Windows Server 2022 that [what it does].
Requirements:
- [specific requirement 1]
- [specific requirement 2]
Output: [what success looks like]

The requirements section is the difference between useful output and something you spend 10 minutes fixing.

A real example

Last week I needed to rotate IIS log files older than 30 days into a zip archive and delete anything over 90 days. Boring task, annoying to write from scratch. My prompt:

Write a PowerShell script for Windows Server 2022 that:
- Finds all .log files in C:\inetpub\logs older than 30 days
- Compresses them into a zip named logs-YYYYMMDD.zip in D:\LogArchive\
- Deletes any zip files in D:\LogArchive\ older than 90 days
- Logs each action with timestamp to D:\LogArchive\rotation.log
Run as a scheduled task, no GUI dependencies

Output was clean, ran first try. The timestamp format was slightly off so I said "use ISO 8601 for the timestamps" and it fixed it in one shot.

Iterating instead of rewriting

This is where most people leave time on the table. They get the first script, it doesn't do exactly what they want, and they start a new prompt from scratch. Don't.

Just say what's wrong in the same chat:

The log file path is hardcoded. Make it a parameter with that path as default.
Add error handling — if the zip creation fails, log the error and continue to the next file instead of stopping.

Each round takes 10 seconds. Treat it like a junior dev who knows PowerShell well but doesn't know your environment — because that's exactly what it is.

What it's bad at

Environment-specific things trip it up. Custom modules, non-standard AD structures, legacy quirks — Claude doesn't know about those. You'll get code that's syntactically correct but wrong for your setup.

Also: always test in a dev environment first. Not because Claude writes dangerous code, but because any script you didn't write line by line deserves a dry run. That's just good practice regardless of where the code came from.

The three things that make it work

Be specific about OS version and context. Add a requirements list even for simple scripts. Iterate on the same chat instead of starting over.

That's the whole workflow. Took me longer to write this post than it takes to get a working script.

Related posts