Stop begging the AI and start briefing it. This topic teaches a repeatable six-block prompt structure — Role, Context, Task, Constraints, Examples and Expected Output — and rebuilds one vague prompt into a professional one step by step. Practical, admin-flavoured prompts throughout; no theory without a paste-able example.
Prompt engineering is the craft of briefing an AI model so precisely that its output is usable with minimal editing. The model has no access to your intentions — only your words — so a good prompt supplies what a good work order would: who the AI should act as (Role), the situation it is operating in (Context), what you want done (Task), the rules it must obey (Constraints), samples of what good looks like (Examples), and the shape of the deliverable (Expected Output). Six blocks, one paragraph, dramatically better answers. It is a skill, not a talent: the structure is learnable in an afternoon.
The difference between an average and a strong AI user is almost entirely prompting. The same model that returns a generic 5-line answer to 'write a PowerShell script' will return a deployable, error-handled, commented script when briefed properly. For IT professionals this compounds: reusable prompt templates for tickets, scripts, documentation and incident summaries save hours every week, and they become your personal IP — the thing that makes you faster than colleagues who type one-liners and complain about the results.
Write the six blocks in order. Role primes the vocabulary: 'You are a senior Windows 11 engineer' shifts the model into admin-appropriate language. Context gives it the facts it cannot guess: OS builds, tooling, environment size, what already failed. Task states the single deliverable. Constraints hard-limit the solution: PowerShell 5.1 compatible, no third-party modules, log to a specific path. Examples show the model the standard you expect — even one sample output halves ambiguity. Expected Output pins the format: numbered steps, a code block, a table, 150 words max. Then iterate: paste the output back and ask what information is still missing.
Role "You are a Windows 11 admin"
Context env facts the AI cannot guess
Task the one deliverable you want
Constraints rules, versions, no-go areas
Examples 1-2 samples of good output
Output format, length, tone
Reliable, reusable AI answer
Real before/after from an endpoint team. Before: 'ChatGPT, write a script to check BitLocker.' Result: a generic Get-BitLockerVolume one-liner that ignores non-system drives and fails silently on devices without a TPM — technically an answer, useless in production. After applying the framework: 'Role: senior Windows engineer. Context: 500 Intune-managed Win11 23H2 devices, TPM 2.0, users are non-admins. Task: script that lists BitLocker status and escrow state for the OS drive. Constraints: PowerShell 5.1+, no modules, output CSV to C:\Temp, exit 1 on error. Output: one script with comments.' The second output needed one small edit before piloting — that is the practical delta prompting makes.
Send: "write a powershell script for intune devices" and observe the generic output — likely a graph call with no error handling, no pagination and no explanation. Save this answer; it is your baseline for measuring improvement.
Paste this and compare: "Role: You are a senior Intune engineer. Context: Microsoft Graph PowerShell SDK, Intune-managed Win11 devices. Task: Write a PowerShell script listing device name, OS version and compliance state. Constraints: Get-MgDeviceManagementManagedDevice, handle pagination, $ErrorActionPreference=Stop, try/catch with meaningful messages. Expected output: one commented script plus 3 bullet points on how it works."
Append to your prompt: "Example of the output row format I want: DeviceName,OSVersion,ComplianceState (CSV, no spaces)." One concrete sample pins formatting in a way ten sentences of description cannot. This is few-shot prompting — Topic 8 goes deep on it.
Follow up with: "Review your script as a hostile senior engineer. List every production risk: missing error handling, edge cases, security issues. Then output the improved script." Self-review prompts routinely catch silent failure paths the first draft ignored.
Copy the working prompt into a file or notes app and replace environment-specific values with placeholders: {OS_VERSION}, {LOG_PATH}, {OUTPUT_FORMAT}. You now own a reusable brief — repeat this for tickets, incident summaries and documentation, and your personal prompt library is born (Topic 7 fills it).
Two prompt-level rules protect you. First, context hygiene: only paste what you would email to an external consultant — device counts, generic log lines, redacted names — and never tenant IDs, secrets, keys or personal data into consumer tools; enterprise products with data boundaries exist for a reason. Second, assume answers are unsafe until reviewed: AI-generated commands can include deprecated parameters, over-broad permissions or destructive defaults. The prompt is your contract with the model — never put sensitive data into that contract, and never trust the model's side of it unverified.
A good prompt is a complete brief: it sets a role, supplies the context the model cannot guess, states one clear task, defines hard constraints, shows an example of the expected quality, and pins the output format. The test is reproducibility — if two people paste your prompt into a fresh chat, they should get functionally equivalent results. Vague prompts fail that test; structured ones pass it.
In three passes. First pass: fix what is missing — the model usually lists its own assumptions if you ask 'what information did you assume?'. Second pass: add constraints and an example to pin format and quality. Third pass: have the model self-review as a hostile senior engineer, then fold its findings back into the prompt itself, so the template improves permanently and not just this one answer.
Generation samples from probability distributions, so outputs vary run to run, especially at higher temperatures. Prompt structure reduces variance by narrowing what is acceptable: explicit constraints, examples and format requirements squeeze the model into a smaller, more reliable zone. For fully deterministic pipelines you combine a strict prompt with temperature 0 and structured output validation.
Take one real task you did this week — a ticket reply, a script, a summary. Write the one-line prompt you would normally send and save the answer. Then rebuild it with all six blocks, including one example and an explicit output format, and save that answer too. Compare editing time. Store the winning prompt in your template file with {PLACEHOLDERS}, and use it on the next real task before the week ends.
One-liner prompting will matter less; precise briefing will matter more. As models take on larger, multi-step work, the bottleneck shifts to specifying goals, constraints and acceptance criteria — exactly what a senior engineer does when delegating to juniors. Prompt engineering is converging with requirements engineering and review skills, which is why it is a durable career skill, not a hack.
Neither matters much — clarity does. 'Please' does not measurably improve accuracy, and rude imperatives do not hurt it. What improves results is specificity: role, context, constraints, examples, format. Spend your effort there instead of on tone experiments.
As long as the briefing needs, and no longer. A definitional question needs one sentence; a production script needs 10-15 lines of structured brief. The failure mode is not length but dilution — five unrelated tasks in one prompt. One task, complete brief, explicit format; if the brief exceeds about a page, split the job and chain prompts.