Move beyond good briefs into techniques that make AI output predictable enough to build on. Covers zero-shot vs few-shot, chain-of-thought reasoning, role prompting, structured JSON/XML output you can parse with ConvertFrom-Json, multi-prompt chaining, self-checking passes and output constraints — each with an IT-work example and a note on when the technique is overkill.
Advanced prompting is about constraining the model's enormous option space until its output is reliable enough to automate against. Zero-shot gives instructions only; few-shot adds 2-5 input/output examples that teach format and judgement by demonstration. Chain-of-thought asks the model to reason step by step before answering, trading tokens for accuracy on multi-step problems. Role prompting assigns expertise and perspective beyond a bare 'act as'. Structured output demands JSON or XML with a fixed schema so code can consume results. Prompt chaining splits a big job into small prompts whose outputs feed each other, and self-checking adds a final pass where the model verifies its own work against explicit criteria. Each technique controls a different failure mode.
These techniques are the line between chatting with AI and engineering with it. A one-off answer can be eyeballed; a weekly automation cannot — it needs few-shot examples for stable formatting, JSON for parseability, chaining for auditability and self-checking for quality gates. This is precisely where the job market is heading: postings increasingly ask for candidates who can build repeatable AI workflows, not just chat. Mastering these six techniques also prepares you for Level 4, where prompts become system components wrapped in code and error handling.
Pick techniques by failure mode. Wrong format → few-shot plus explicit schema ('return only JSON matching: {"code":"string","cause":"string"}'). Wrong reasoning → chain-of-thought ('think step by step, show each inference, then conclude'). Wrong tone or depth → role prompting with specifics ('you are an escalation engineer writing for a CTO — no vendor marketing'). Complex jobs → chaining: prompt 1 extracts facts, prompt 2 drafts, prompt 3 verifies and formats. Inconsistent quality → self-checking ('list every claim you are less than 90% sure of'). Unparseable output → structured output with temperature 0, and validate programmatically; if parsing fails, retry rather than regex-repair the text.
Prompt 1: extract facts from input
↓
Prompt 2: analyse / draft (CoT)
↓
Prompt 3: self-check + fix issues
↓
Prompt 4: format as strict JSON
↓
Code: parse → validate → actA real pipeline built with these techniques: nightly triage of Intune sync failures. Prompt 1 (structured output): 'Extract error codes, device IDs and timestamps from this log excerpt. Return JSON: [{"code":"","device":"","time":""}]' — parsed with ConvertFrom-Json. Prompt 2 (few-shot + role): two worked examples of code → diagnosis, then 'classify each new code'. Prompt 3 (chain-of-thought): 'For each error, reason step by step about whether it is policy, network or client-side, citing evidence.' Prompt 4 (self-check): 'Verify each diagnosis against the excerpt; drop any you cannot support.' Total: a triage report that used to take 45 minutes of eyeballing, produced in 4 minutes with an auditable trail.
Task: classify 5 Intune error codes as policy/network/app. First run zero-shot: "Classify these error codes: 0x87D1FDE8, 0x80072EE2, 0x87D1041C…" Note the inconsistent output shape. Then few-shot: prepend 2 worked examples ("0x87D1FDE8 → policy: exit code 1610 from detection script means reboot pending"). Compare consistency — the format stabilises immediately.
Take a messy scenario: "Device fails ESP with 0x800705b4 intermittently. Think step by step: list every component in the ESP path that can time out, mark which fit 'intermittent', then rank causes." Watching the reasoning exposes errors you can correct mid-flight — reasoning you can audit beats an answer you must trust.
Prompt: "Analyse this error list. Return ONLY a JSON array, no prose, schema: [{"code":"string","category":"policy|network|app","confidence":"high|medium|low"}]." Then validate in PowerShell: $json = $response | ConvertFrom-Json. If parsing fails, retry the request — never hand-repair output that code will consume.
Build the extraction → analysis → verification chain on a real incident: Prompt 1 extracts facts as JSON; Prompt 2 receives only that JSON and drafts the RCA; Prompt 3 receives the draft and the original log and verifies every claim. Save each output — the chain gives you an audit trail no single mega-prompt can offer.
End any important prompt with: "Before finalising: list every factual claim you are less than 90% confident in, flag assumptions, and state what evidence would change your answer." Then delete flagged items or verify them yourself. This single sentence catches a surprising share of hallucinations before they reach your documentation.
Structured pipelines change the threat surface. In chained prompts, earlier stages' output becomes later stages' input — if an early stage reads untrusted content (logs, emails, ticket text), a prompt injection embedded there can steer the whole chain. Defences: mark untrusted blocks explicitly (<untrusted>…</untrusted> with instructions never to follow directives inside), keep destructive actions out of the model's reach entirely, and require human approval before any stage that changes state. Also treat generated JSON like untrusted input in your code: validate schema, length and types before ConvertFrom-Json feeds anything downstream.
Whenever output format or judgement is hard to state but easy to show. Zero-shot works for definitions and well-known tasks; few-shot wins when I need a stable output schema across many runs, or when classification depends on subtle patterns — like telling policy errors from network errors. Two or three high-quality examples usually stabilise both format and quality, and they cost far less than fine-tuning.
Chaining splits a workflow into small prompts whose outputs feed the next stage — extract facts, then analyse, then verify, then format. I chain because each stage becomes testable and debuggable on its own, because context stays focused per stage, and because the intermediate outputs form an audit trail. A single mega-prompt mixes tasks, dilutes instructions and fails opaquely; a chain fails visibly, at a stage you can fix.
Four layers. Prompt: state the exact schema and forbid prose ('return only JSON matching this schema'). Decoding: temperature 0 for determinism. Parsing: never trust — validate with a schema check before ConvertFrom-Json, and treat failure as a retry, not an exception to regex away. Fallback: providers offer JSON modes or function calling that enforce structure server-side; use them when the workflow is unattended.
Build a three-stage chain for a real recurring task — for example triaging a folder of error reports. Stage 1: extract code, device, timestamp as JSON. Stage 2: classify each with chain-of-thought reasoning. Stage 3: self-check against the original text and output a final JSON report. Run it on yesterday's real data, measure the time saved versus manual triage, and write down the one place the chain broke — that is your next improvement.
On multi-step problems — triage, comparisons, cause analysis — it usually improves accuracy because errors surface in the visible reasoning, but it costs more tokens and latency. On simple recall tasks it adds nothing and can occasionally introduce over-elaboration. Rule of thumb: if you would debug the answer by asking 'how did you get there?', ask for the reasoning up front.
JSON for anything your code will parse — PowerShell's ConvertFrom-Json, Python's json, every API gateway speaks it natively. XML still shines inside prompts as tagging: wrapping <context>, <task> and <untrusted> sections helps models separate instruction from data, which is a security technique as much as a formatting one. Many production prompts use both: XML sections inside the prompt, JSON out of it.
For structured extraction and classification, yes — determinism beats creativity. For drafting, summarising and anything user-facing, a little temperature often reads better. The subtle point: temperature 0 reduces variance but is not a correctness guarantee — the model can be deterministically wrong. Combine it with validation and retries; never with blind trust.