Prompt Engineering for IT Infrastructure Consultants

Last reviewed: June 2026
Part 2 of 8 · Using AI in infrastructure work — the full series is listed at the end.

Part 1 ended on a principle: I want a model to expose uncertainty rather than hide it behind clean prose. The prompt is where that principle is enforced or lost. In infrastructure work a prompt isn't a clever sentence and it isn't a magic incantation — it's a work instruction. It sets the role, the source material, the constraints, the output format, and the review gate for a task whose output might feed a migration plan, a CAB request, or a PowerShell review.

So I don't ask the model to be creative first. I ask it to be bounded, explicit, and honest about what it doesn't know. Across Citrix, Active Directory, and Azure delivery the input is always the same kind of mess: incomplete notes, mixed terminology, undocumented dependencies, hidden risk. A good prompt forces that mess into a reviewable artifact without pretending it was ever complete. This part covers the anatomy of those prompts and the three patterns I reach for most.

The anatomy of a work-instruction prompt

Before the specific patterns, the shape underneath all of them. Almost every prompt I trust for real work has five parts, and when a result is bad it's usually because one of them was missing:

• Role — who the model is acting as ("an infrastructure migration lead," "a PowerShell reviewer"). This sets the lens.
• Source — exactly what it may use, and the instruction to use only that. "Use only the notes below" is the single most important line in most of my prompts. It is what stops the model from quietly substituting general knowledge for your specific environment.
• Constraints — what it must not do: don't invent owners, don't rewrite the script, don't assume a date. The constraints are where uncertainty gets preserved instead of smoothed away.
• Output format — a table, a checklist, a structured request. Format isn't cosmetic; it forces the model to fill specific fields, and an empty field is a visible gap.
• Review gate — who validates the output before it becomes project material. Sometimes this is in the prompt; always it's in my head.

The three patterns below are just this skeleton, specialised.

Pattern 1: discovery notes → RAID log

After an AD, Citrix, or Azure discovery workshop, I convert raw notes into a RAID log the team can review.

You are assisting an infrastructure migration lead.
Use only the notes below.
Extract risks, assumptions, issues, dependencies, owners, and open questions.
Do not invent missing owners or dates.
If information is missing, write "Unknown" and add a follow-up question.
Return a RAID table with columns:
Type, Description, Owner, Impact, Due date, Evidence from notes, Follow-up question.

Workshop notes:
[paste notes here]

The value isn't the table — it's the instruction to preserve gaps. Feed it a messy line like "app team thinks the old finance app still binds to the retiring domain, nobody's sure which service account" and a good response returns something like:

That row is honest about everything it doesn't know, which is exactly what makes it a usable management artifact instead of a false reassurance. The failure mode to watch for: a weaker prompt (or a model told to "tidy this up") will confidently fill Owner with "Finance Team" and invent a due date. The moment that happens, the log is worse than no log, because it looks complete. (The example input here is illustrative — swap in your own notes.)

Pattern 2: PowerShell production review

Before a script is even considered for production, I have the model review it — in a reviewer role, not a rewrite role.

Review this PowerShell script for production use in Active Directory.
Focus on:
- SupportsShouldProcess, -WhatIf, and -Confirm
- input validation
- least privilege
- logging
- rollback
- idempotency
- error handling
- secrets or password exposure
- auditability
- blast radius

Return:
1. Blocking risks
2. Non-blocking improvements
3. Missing tests
4. Questions for the script owner
5. A production readiness checklist

Do not rewrite the script unless asked.
Script:
[paste script here]

Asking for risks and questions before any code generation keeps the model where I want it. The ordered output matters too: blocking risks first means the most important finding is at the top, not buried under style nits. The failure mode here is the helpful rewrite. Let the model jump straight to "here's a better version" and two things go wrong — it stops reviewing the code in front of it, and it hands you a confident rewrite that is harder to review than the original, because now you're checking new code instead of finding flaws in known code. For anything that touches identity, I want the flaws named, not silently replaced.

Pattern 3: technical notes → CAB change request

Converting engineering notes into something a Change Advisory Board can actually evaluate is tedious, repetitive, and a perfect fit for a bounded prompt.

Convert the technical notes below into a CAB-ready change request.
Use clear language for non-specialists.
Include:
- business reason
- technical scope
- systems affected
- implementation steps
- validation steps
- rollback plan
- user impact
- communication plan
- risk rating
- go/no-go criteria
- required approvals

Flag missing information instead of inventing it.
Technical notes:
[paste notes here]

This pattern earns its keep by exposing what's missing. Engineers write change notes in engineering language — what they'll do, not the business reason, the user impact, or the rollback plan. Forcing the model to fill all those fields turns absences into visible "Not specified" entries, which is precisely the conversation you want to have before the CAB meeting rather than in it. It moves a technical lead from "I know what I'm doing" to "I can explain what I'm doing to the people who have to approve it" — and on a large change, that translation is most of the job.

The decisions behind every prompt

Choosing the pattern is the easy part. These are the judgements I make before I paste anything:

That fifth row is the bridge back to Part 1: the most elegant prompt in the world is a problem if you fed it a real sign-in log or a service-account password to get there.

What I'll let AI draft, and what stays human

I'll let AI draft checklists, summarise workshops, review scripts, compare options, prepare CAB drafts, and point out missing information. I won't let it approve production changes, replace vendor documentation, make final architecture decisions, or run privileged operations. AI-generated PowerShell, firewall changes, identity changes, and migration plans all get human review. The owner stays the engineer or technical lead — never the model. The prompt makes the draft faster; it does not move the accountability.

Build the patterns once, reuse them everywhere

These three aren't one-off prompts — they're templates I keep and refine. On a migration program I'll reuse the RAID prompt after every workshop and the CAB prompt before every change, which means small improvements compound: a constraint I add once ("flag any application with a hardcoded LDAP path as a separate risk") improves every future run. That's the real shift from "asking ChatGPT things" to prompt engineering — you're building a small, versioned toolkit, not typing from scratch each time. For a team, that toolkit should be shared rather than reinvented per engineer, which is where Part 3 picks up.

Practical checklist

• Define the role and the task before pasting context.
• State which sources the model may use — and mean "only these."
• Force assumptions and unknowns into their own fields.
• Ask for risks before recommendations.
• Use tables for RAID logs, decision matrices, and checklists.
• Require evidence or citations for any external fact.
• Sanitise sensitive data before it goes into the prompt.
• Never treat AI output as production approval.

The point

Prompt engineering, in this work, is a disciplined interface — not clever wording. The value is turning messy infrastructure input into reviewable artifacts while preserving uncertainty, ownership, and approval boundaries. These three patterns, built on the same five-part skeleton, cover most of my day-to-day. Part 3 covers the cases where one prompt isn't enough: chaining, option comparison, self-review, and the multimodal work I learned the hard way building a vision-capable retrieval system.

The full series

1. How I Use AI Safely in Infrastructure Workflows
2. Prompt Engineering for IT Infrastructure Consultants — (you're reading this)
3. Advanced Prompting Patterns for Infrastructure Planning
4. RAG for Enterprise Infrastructure Knowledge
5. Context Engineering for Enterprise AI Systems
6. Workflow Engineering for Agentic AI in Infrastructure Operations
7. AI Coding Agents in Infrastructure Automation
8. TDD + SDD for AI-Assisted Infrastructure Automation