Prompt Engineering for Technical Writers

Lecture 2 of the AI for Technical Writing Series

45-Minute Lecture Guide + Full Presenter Script

Pratik Jadhav | June 2026

Session Duration
Recap: Lecture 1 Concepts 10 minutes
Session 1: Foundations of Prompt Engineering 10 minutes
Session 2: Prompting as a Technical Writer 10 minutes
Session 3: Real-World Integration (Docs-as- 10 minutes
Code, API, Postman)
Q&A + FAQ Round 15 minutes
 WHAT YOU WILL ACHIEVE BY END OF THIS LECTURE

By the end of this 45-minute session, you will be able to:

• Write structured, reusable prompts for technical writing tasks

• Apply prompt engineering mental models to everyday doc work
• Use AI to accelerate API documentation, docs-as-code, and Postman workflows
• Build a personal library of prompt files mapped to specific TW tasks
• Evaluate AI output critically — know when to trust it, and when to rewrite it
 RECAP: LECTURE 1 — 10 Minutes

PRESENTER NOTE
Open with energy. Tell the audience: 'Before we go forward, let's make sure the foundation is
rock solid. Everything we do today rests on what you learned last time.'

1.1 Generative AI — What It Actually Is

SCRIPT
"Last time we talked about Generative AI. Let me give you the one-line definition you can use in
any interview or conversation."
"Generative AI is software that creates new content — text, images, code, audio — by learning
patterns from enormous amounts of existing data. It doesn't retrieve stored answers. It
generates new ones, every single time."

LAYMAN ANALOGY
Think of Generative AI as an extremely well-read intern. You give them a task. They have never
done YOUR exact task before — but they have read thousands of similar documents, reports,
and guides. So they can draft something plausible, fast. Your job is to review, correct, and
approve.

USE CASES RELEVANT TO TECHNICAL WRITERS

• First draft generation for user guides, release notes, API descriptions
• Content rewriting for tone, audience, or reading level
• Translation and localization of documentation
• Auto-generating FAQs from existing documentation
• Summarizing long product specifications into overview sections

1.2 AI Agents vs. Agentic AI — The Critical Difference

SCRIPT
"This is the one that trips people up in interviews. So let's nail it."
"An AI Agent is a self-contained AI program designed to do a specific job — like a chatbot that
answers customer questions, or an AI that categorizes support tickets."
"Agentic AI is different. It's AI that can plan, take multiple steps, use tools, and make decisions
autonomously to achieve a goal — without you holding its hand at every step."

LAYMAN ANALOGY
AI Agent = a vending machine. You press a button (give a prompt), it dispenses an answer. One
input, one output. Agentic AI = a personal assistant with a to-do list, a laptop, and calendar
access. You say 'plan my product launch documentation' and it creates the outline, researches
competitors, drafts sections, and emails you a summary — all on its own.
AI Agent Agentic AI
One task, one response Multi-step autonomous workflow
No memory between turns (usually) Maintains context across steps
Example: ChatGPT answering a question Example: Claude Code writing + committing
docs
Stateless Stateful — tracks progress

1.3 LLM (Large Language Model) — The Engine Inside

SCRIPT
"An LLM is the core engine powering most AI tools you will use. GPT-4, Claude, Gemini —
these are all LLMs."
"They are trained on billions of words from the internet, books, and code. They learn to predict:
given this sequence of words, what is the most likely next word? Do that billions of times at high
speed and you get something that sounds remarkably human."

LAYMAN ANALOGY
An LLM is like an incredibly sophisticated autocomplete. Your phone suggests the next word
when you type a message. An LLM does that — but for paragraphs, pages, and entire
documents — with context, tone, and domain knowledge baked in.

WHAT THIS MEANS FOR YOU AS A TW

• The quality of what the LLM produces is directly proportional to the quality of your instruction
• LLMs have a knowledge cutoff — they don't know what your product shipped last Tuesday
• LLMs can hallucinate — they generate plausible-sounding but incorrect information
• This is why prompt engineering exists: you are the quality gate

1.4 RAG (Retrieval-Augmented Generation) — Your Knowledge Injection

SCRIPT
"RAG solves a real problem: LLMs don't know your product. They were trained on the internet,
not your internal wiki or API specification."
"RAG is a technique where, before the LLM answers your question, it first retrieves relevant
documents from a knowledge base — your docs, your Confluence, your YAML spec — and
then uses that retrieved information to generate a grounded, accurate response."

LAYMAN ANALOGY
Imagine you ask a new employee a product question. Without RAG: they guess based on
general knowledge — sometimes right, sometimes dangerously wrong. With RAG: before
answering, they quickly search the internal wiki, find the relevant page, and then answer based
on actual company documentation. That's RAG.

Without RAG With RAG

LLM uses only training data LLM uses your actual documents
May hallucinate product-specific details Grounded in your source of truth
Generic answers Context-aware, product-specific answers
Example: Claude guessing your API endpoints Example: Claude reading your OpenAPI YAML
first

FAQ — RECAP SECTION

Q: Can an LLM replace a technical writer? A: No. LLMs are tools. They lack product knowledge,
contextual judgment, user empathy, and accountability. A TW with strong prompt skills is
significantly more valuable than one who ignores AI. Q: Is RAG the same as giving Claude a
document to read? A: In practice, yes — when you paste your YAML or user guide into a
prompt, you are doing manual RAG. Formal RAG systems automate this retrieval at scale. Q:
What is the difference between an LLM and a chatbot? A: An LLM is the model (the brain). A
chatbot is an application built on top of an LLM (the product you interact with).
 SESSION 1: FOUNDATIONS OF PROMPT ENGINEERING — 10 Minutes

BRIDGE FROM RECAP

'Now you understand the engine. Prompt engineering is how you drive it. The LLM is a Formula
1 car. Without knowing how to steer it, you'll crash. Today you learn to steer.'

2.1 What Is Prompt Engineering?

SCRIPT
"Prompt engineering is the practice of designing, structuring, and iterating on instructions given
to an AI model to produce accurate, useful, and reliable outputs."
"It is not magic. It is not coding. It is communication design — with very specific, learnable
rules."

MENTAL MODEL
MENTAL MODEL: Think of prompting like writing a work order for a contractor. A vague order:
'Fix the bathroom.' You get random results. A good order: 'Replace the tap in the bathroom sink.
Use chrome fixtures. Match the existing style. Complete by Friday and leave no tools behind.'
Every element you add narrows the output space and improves the result. Prompt engineering
is exactly this — scoping the contractor's work with precision.

2.2 Prerequisites of Prompt Engineering

Before you write a single prompt, you must be able to answer these five questions:

Prerequisite Why It Matters

1. Know your task clearly Vague task = vague prompt = garbage output.
Define the deliverable before opening any AI
tool.
2. Know your audience A prompt for a developer API doc differs from
one for an end-user guide. The LLM needs this
context.
3. Know your style standard If you follow MSTP, say so. The LLM will adapt
its tone, formatting, and vocabulary.
4. Know what good output looks like You cannot evaluate AI output if you don't know
the standard. Your TW expertise is the quality
gate.
5. Know your source of truth Always have the product spec, YAML, or
release notes ready. Never ask AI to invent
product facts.
2.3 The Anatomy of a High-Quality Prompt
SCRIPT
"Every effective prompt has five components. You don't always need all five — but the more
complex the task, the more components you should include."

Component What to Write

ROLE You are a technical writer following Microsoft
Writing Style Guide (MSTP).
CONTEXT I am documenting the /current endpoint of the
OpenWeatherMap REST API.
TASK Write a 'Parameters' section describing the q,
appid, and units query parameters.
CONSTRAINTS Use a table format. Write in second person,
present tense. Do not use passive voice. Max
200 words.
OUTPUT FORMAT Return the section as Markdown, ready to
paste into a MkDocs documentation site.

FULL EXAMPLE PROMPT

ROLE: You are a technical writer following MSTP (Microsoft Writing Style
Guide).

CONTEXT: I am documenting the OpenWeatherMap Current Weather API endpoint:

GET [Link]

TASK: Write a "Query Parameters" section for the API reference documentation.
Include these parameters: q (city name), appid (API key), units
(metric/imperial).

CONSTRAINTS:
- Format as a Markdown table with columns: Parameter | Type | Required |
Description
- Write in second person (you/your), present tense
- Do not use passive voice
- Keep descriptions under 20 words each
- Follow MSTP: bold UI elements, no Oxford comma required but consistent
punctuation

OUTPUT FORMAT: Return only the Markdown table, no preamble, no commentary.

2.4 Prompting Techniques Every TW Should Know

Technique What It Does + Example
Zero-shot prompting Give a task with no examples. Works for
simple, well-defined tasks. Example: 'Write a
one-sentence product description for a weather
API.'
 Few-shot prompting Provide 1–3 examples before the task.
Dramatically improves format consistency.
Example: 'Here are two approved release note
entries. [Examples]. Now write one for the new
export feature.'
Chain-of-thought Ask the LLM to reason step-by-step before
giving the answer. Reduces errors in complex
tasks. Example: 'Think step by step before
writing the troubleshooting procedure.'
Role prompting Assign a persona. LLM adopts that knowledge
domain and tone. Example: 'You are a senior
technical writer at a SaaS company with 10
years of API documentation experience.'
Constraint prompting Add specific limits. Controls length, format,
tone, vocabulary. Example: 'Write in plain
English. Reading level: Grade 8. Max 3
sentences per paragraph.'
Iterative refinement Treat the first output as a draft. Follow up with
targeted correction prompts. This is your most
powerful tool.

FAQ — SESSION 1
Q: Is longer always better for prompts? A: No. Precision beats length. A focused 50-word
prompt often outperforms a rambling 200-word one. Q: Can I save and reuse prompts? A: Yes
— and you should. We will build prompt files today for exactly this purpose. Q: What if the AI
ignores my constraints? A: Re-state the broken constraint at the top of your follow-up. Be direct:
'Your previous response used passive voice. Rewrite using active voice only.' Q: Which LLM
should I use? A: For documentation tasks, Claude (Anthropic) and GPT-4 (OpenAI) are both
strong. Claude tends to follow style guide constraints more reliably. Use what your organization
supports.
 SESSION 2: PROMPTING AS A TECHNICAL WRITER — 10 Minutes

3.1 The Technical Writer's Mental Model for Every AI Task

SCRIPT
"Here is the mental model I want you to internalize. Every single time you open an AI tool for a
documentation task, run through these four questions before you type anything."

Question What You Are Doing

1. What is the exact deliverable? Name the document type: API reference, quick
start, release note, error message, tooltip. Be
specific.
2. Who is the reader? Developer? End user? System administrator?
Non-technical manager? This shapes every
word.
3. What is my source of truth? Your YAML, the product spec, the Jira ticket,
the engineering doc. Paste it in. Never let AI
invent facts.
4. What is my style authority? MSTP? DITA? Chicago? Your company style
guide? State it explicitly in the role section of
your prompt.

3.2 Prompt Files — Your Personal TW Toolkit

SCRIPT
"A prompt file is a saved, version-controlled text file containing a reusable prompt template for a
specific documentation task. Think of it as a work order template you fill in for each new
project."
"Good technical writers build a library of these. They live in your GitHub repo, your Confluence
page, or even a simple folder on your desktop."

Prompt File 1: API Reference — Parameters Section

# PROMPT: API Parameters Section
# Task: Document query parameters for a REST API endpoint
# Style: MSTP | Format: Markdown table

You are a technical writer following the Microsoft Writing Style Guide (MSTP).

CONTEXT:
Endpoint: [PASTE ENDPOINT HERE, e.g., GET /data/2.5/weather]
Product: [PRODUCT NAME]
Parameters to document: [LIST PARAMETER NAMES]

TASK:
Write a "Query Parameters" reference section. For each parameter, include:
- Parameter name (code font)
 - Data type
- Required or optional
- Default value (if any)
- Description (present tense, active voice, second person, max 25 words)

FORMAT:
Return a Markdown table with columns: Parameter | Type | Required | Default |
Description
No preamble. No conclusion. Table only.

Prompt File 2: Release Notes Entry

# PROMPT: Release Notes Entry
# Task: Write a single release notes item
# Style: MSTP | Format: Markdown bullet

You are a technical writer following MSTP.

CONTEXT:
Product: [PRODUCT NAME]
Version: [VERSION NUMBER]
Change type: [Bug fix | New feature | Improvement | Deprecation]
Engineering description: [PASTE JIRA TICKET OR ENGINEERING NOTE HERE]

TASK:
Write one release notes entry. Structure:
- Verb-first sentence stating what changed (active voice, present tense)
- One optional sentence of impact or benefit to the user
- Do NOT include internal ticket numbers, engineering jargon, or passive
constructions

FORMAT: Return as a single Markdown bullet point.

Prompt File 3: Troubleshooting Procedure

# PROMPT: Troubleshooting Procedure
# Task: Write a single troubleshooting topic
# Style: MSTP | Format: Numbered steps

You are a technical writer following MSTP.

CONTEXT:
Product: [PRODUCT NAME]
Problem statement: [WHAT THE USER SEES — exact error message or symptom]
Root cause (if known): [CAUSE]
Resolution: [STEPS TO FIX — paste engineering notes]

TASK:
Write a troubleshooting topic with:
1. Heading: "Resolve [problem]" (task-oriented, verb-first, MSTP compliant)
2. One-sentence description of the symptom (second person, present tense)
3. Numbered resolution steps (complete sentences ending in period, MSTP Step
format)
4. One "See also" cross-reference if relevant

FORMAT: Markdown. Steps as numbered list. UI element names in bold.

Prompt File 4: Quick Start Guide — First Section
# PROMPT: Quick Start Guide Introduction
# Task: Write the opening section of a Quick Start Guide
# Style: MSTP | Format: Prose + numbered steps

You are a technical writer following MSTP writing a Quick Start Guide.

CONTEXT:
Product: [PRODUCT NAME]
What the user will achieve: [ONE-SENTENCE SUCCESS OUTCOME]
Prerequisites the user needs: [LIST PREREQUISITES]
Estimated time: [X minutes]

TASK:
Write the opening section of a Quick Start Guide including:
1. One-sentence purpose statement (what the user achieves, not what the
product does)
2. "Before you begin" prerequisites block (bullet list)
3. Estimated time callout

FORMAT: Markdown. No marketing language. No passive voice. Second person

throughout.

Prompt File 5: Error Message Copy

# PROMPT: Error Message
# Task: Write a user-facing error message
# Style: MSTP error message guidelines

You are a UX technical writer following MSTP error message guidelines.

CONTEXT:
Error code: [CODE]
What went wrong (technical): [ENGINEERING DESCRIPTION]
What the user should do next: [RECOVERY ACTION]
User type: [developer | end user | admin]

TASK:
Write the error message with:
1. State clearly what happened (not what the system did, but what the user
experiences)
2. Tell the user exactly what to do next (actionable, specific)
3. Do not use: "Error", "Failed", "Invalid" as the first word
4. Do not blame the user

FORMAT: Plain text. Max 2 sentences. No error codes visible to end user.

FAQ — SESSION 2
Q: Where should I store prompt files? A: GitHub is ideal — versioned, shareable, and
demonstrates docs-as-code awareness. A prompts/ folder in your portfolio repo is excellent for
job applications. Q: Should prompts be in Markdown or plain text? A: Markdown is preferred —
it renders in GitHub, Confluence, and MkDocs. Use .md extension and add a YAML frontmatter
block for metadata. Q: How specific should my source of truth paste be? A: As specific as
possible. Paste the exact YAML block, the exact error message, the exact Jira description.
Vague source = vague output. Q: Can I use the same prompt file across different AI tools? A:
Yes. Prompt files are tool-agnostic. The same file works in Claude, ChatGPT, Gemini, or any
LLM with a chat interface.
 SESSION 3: REAL-WORLD INTEGRATION — Docs-as-Code, API,
Postman — 10 Minutes

4.1 Docs-as-Code + AI — The Modern TW Stack

SCRIPT
"Docs-as-code means treating your documentation exactly like software: written in plain text,
stored in Git, reviewed via pull requests, and published automatically."
"When you add AI to this workflow, you unlock a force multiplier. You're not replacing the
workflow — you're accelerating every step of it."

THE DOCS-AS-CODE + AI WORKFLOW

Stage AI-Accelerated Action
1. Content planning Prompt: 'Given this API YAML, list all topics
needed for a complete reference doc.' AI
generates the doc outline.
2. First draft Prompt: 'Write the authentication section based
on this security schema block.' [Paste YAML]
3. Review Prompt: 'Review this Markdown section against
MSTP. Flag passive voice, heading format
issues, and missing step punctuation.'
4. Linting + style check Use Vale + AI together: Vale catches rule
violations; AI suggests rewrites for flagged
sentences.
5. Commit message writing Prompt: 'Write a Git commit message for
adding the authentication section. Follow
Conventional Commits format.'
6. Changelog generation Prompt: 'Based on these commit messages,
write a changelog entry for version 2.1.0.'
[Paste git log]

PROMPT: GENERATE DOCS OUTLINE FROM OPENAPI YAML

You are a technical writer following MSTP.
Below is an OpenAPI 3.0 YAML specification for a weather API.

[PASTE YOUR FULL YAML HERE]

TASK:
Generate a complete documentation outline for this API including:
1. Overview topic
2. Authentication topic
3. One reference topic per endpoint
4. Error codes reference
5. Quick start guide topic

FORMAT: Markdown nested list. Topic names must be task-oriented (verb-first).

Do not generate the actual content — outline only.
4.2 API Documentation + AI — The Right Workflow
SCRIPT
"Here is the critical rule for AI and API docs: AI reads YAML. You write prose. Never the other
way around."
"Your OpenAPI YAML is the single source of truth. Feed it to the AI. Ask it to explain it,
document it, or find gaps. But never ask AI to create a YAML from scratch for a real product —
you will get hallucinated endpoints."

Use AI For Do NOT Use AI For

Translating YAML schema into prose Inventing API endpoints or parameters
descriptions
Generating parameter description tables from Creating YAML specs without a real source
spec
Writing request/response examples from Validating whether your API actually works
schema
Identifying undocumented endpoints in your Replacing live API testing in Postman
YAML
Drafting error code descriptions from HTTP Generating accurate rate limit or pricing
status meanings information

PROMPT: DOCUMENT A SINGLE API ENDPOINT

You are a technical writer following MSTP documenting a REST API.

ENDPOINT SPEC (from OpenAPI YAML):

[PASTE THE SPECIFIC PATH BLOCK FROM YOUR YAML]

TASK:
Write a complete API reference topic for this endpoint including:
1. Endpoint heading: HTTP method + path (e.g., "GET /weather")
2. One-sentence description (what it returns, not what it does internally)
3. Base URL
4. Query parameters table (Parameter | Type | Required | Description)
5. Sample request (curl format)
6. Sample response (JSON, real values, not placeholder strings)
7. HTTP response codes table (Code | Meaning | When it occurs)

FORMAT: Markdown. Bold all parameter names. Code blocks for curl and JSON.
Do not invent values. Use only what is in the YAML provided.

4.3 Postman + AI — Prompting Your API Testing Workflow

SCRIPT
"Postman is where you test. AI is where you document. But now, Postman has its own AI
features — and you can prompt your way through test creation, collection documentation, and
even mock servers."
Postman Task How to Use AI / Prompting
Write test scripts Prompt: 'Write a Postman test script that
checks: status is 200, response contains a
temp field, city name matches the query
parameter q.'
Document a Collection Prompt: 'Here is my Postman collection JSON.
Write a README for this collection explaining
what each request does.'
Create environment setup notes Prompt: 'Write setup instructions for a Postman
environment with variables: base_url, api_key,
city. Intended audience: junior developer.'
Generate mock server responses Prompt: 'Create a realistic mock JSON
response for a weather API /current endpoint
for the city of Pune, India.'
Write pre-request scripts Prompt: 'Write a Postman pre-request script
that dynamically sets a timestamp variable in
ISO 8601 format.'

PROMPT: WRITE POSTMAN TEST SCRIPT

You are a QA technical writer. Write a Postman test script in JavaScript for
the following API call:

Endpoint: GET [Link]

Query params: q=Pune, appid={{api_key}}, units=metric

Tests to include:
1. Status code is 200
2. Response time is under 2000ms
3. Response body contains field: [Link]
4. Response body contains field: weather[0].description
5. city name in response (name) matches the query parameter city

FORMAT: Valid Postman JavaScript test script using [Link]() and [Link]()
syntax.
Include comments above each test explaining what it validates.

4.4 Claude, ChatGPT, and the Everything Integration

SCRIPT
"Here is where we are in 2026: almost every professional tool you use has an AI integration.
The question is no longer 'should I use AI?' — it's 'how do I use it well?'"

Tool AI Integration + TW Use Case

Confluence Summarize long pages, generate page
templates, rewrite for plain English, auto-draft
meeting notes into action items
MadCap Flare Use AI to pre-draft topics in Word, then import.
Generate condition tag logic explanations. Draft
 snippet content.
VS Code (docs-as-code) GitHub Copilot suggests next Markdown
headings, table rows, YAML schema
descriptions in real time
Swagger Editor / Redoc Feed your YAML to Claude: 'Find
undocumented fields in this spec.' or 'Improve
all summary strings to be verb-first.'
GitHub AI-generated PR descriptions, commit
messages, README updates. Copilot writes
documentation comments in code.
Slack / Teams Summarize long threads into action items. Draft
polished messages from rough notes.
Jira / Linear Turn ticket descriptions into documentation
stubs. Generate acceptance criteria into user-
facing help text.

2025–2026 TRENDS IN AI + TECHNICAL WRITING

Trend 1 — Prompt Libraries as Deliverables: Organizations are now storing prompt files in Git
alongside documentation source files. Prompts are versioned, reviewed, and maintained like
code. Trend 2 — AI-First Review Cycles: First-pass review (grammar, style, MSTP compliance)
is increasingly AI-automated via tools like Vale + LLM commentary. TWs focus on structural and
accuracy review. Trend 3 — Spec-Driven Documentation: OpenAPI/AsyncAPI YAML is
becoming the single source of truth. AI reads the spec; TWs write the narrative layer around it.
Trend 4 — Conversational Documentation: AI-powered doc search (RAG chatbots) is replacing
static Help Centers at scale. TWs are now designing for AI retrieval, not just human reading.
Trend 5 — Portfolio Expectations Are Rising: Job postings increasingly list 'experience with AI
documentation tools' as a requirement, not a nice-to-have.

FAQ — SESSION 3
Q: Can AI write an entire API documentation site for me? A: It can generate strong first drafts —
but every factual claim must be verified against the actual API. The TW is still responsible for
accuracy. Q: Should I disclose that I used AI in my documentation work? A: Follow your
organization's policy. As a general rule: AI is a tool, like Grammarly or autocorrect. You are
responsible for the output quality regardless of the tool. Q: Does Postman have built-in AI
features now? A: Yes — Postman has added AI-powered test generation and documentation
features. The principles of good prompting apply equally inside Postman's AI interface. Q: Is it
safe to paste my company's YAML or internal docs into public AI tools? A: Check your
company's data policy first. For sensitive data, use enterprise versions of Claude or ChatGPT
that offer data privacy guarantees, or use locally-hosted models. Q: How do I explain AI-
assisted documentation on my resume? A: Frame it around outcomes: 'Reduced first-draft time
by 60% using structured AI prompting workflows.' Focus on your judgment, not the tool.
 Q&A SESSION — 15 Minutes

PRESENTER NOTE
Open the Q&A with: 'I want to hear what surprised you most today — and what you're most
likely to try first.' This surfaces real engagement and anchors the discussion.

Master FAQ — Frequently Asked Questions Across All Sessions

On Foundations
• Q: What is the difference between prompting and fine-tuning? A: Prompting gives instructions at
run time. Fine-tuning retrains the model on new data. As a TW, you will almost always be
prompting, not fine-tuning.
• Q: Can I use the same prompt for Claude and ChatGPT? A: Yes. Well-structured prompts are
largely portable across models. Minor adjustments may be needed for tone or output format
differences.
• Q: What happens if the AI makes a factual error? A: You catch it — because you know your
product. This is why subject matter knowledge + AI skills together are the winning combination.

On Technical Writing Workflows

• Q: Where does prompt engineering fit in the SDLC? A: At every stage where documentation is
produced: requirements analysis, API spec review, draft generation, review, localization
preparation, and changelog authoring.
• Q: Can AI help with DITA or structured authoring? A: Yes. You can prompt AI to generate
content in DITA XML structure, but always validate the XML against your DTD before importing
into your tool.
• Q: How do I prevent AI from making up API parameters that don't exist? A: Always provide the
YAML or spec as context. Explicitly state in your prompt: 'Use only the parameters defined in
the spec below. Do not invent additional parameters.'

On Career and Portfolio

• Q: Will prompt engineering become a job title? A: It already has in some organizations. More
commonly, it is a core skill within the role of Technical Writer, Documentation Engineer, or AI
Content Strategist.
• Q: Should my GitHub portfolio include prompt files? A: Absolutely. A prompts/ folder with well-
structured, MSTP-aligned prompt templates is a strong differentiator in junior-to-mid TW job
applications right now.
• Q: How do I demonstrate prompt engineering skill in an interview? A: Walk through a real
prompt you wrote. Explain why you included each component. Show the before/after of AI
output with and without that prompt. Demonstrate critical evaluation of AI output.

Quick-Reference Card — Take This With You

When You Need To... Use This Prompt Starter
Document an API endpoint 'You are a TW following MSTP. Here is my OpenAPI
YAML block: [paste]. Write a reference topic for this
endpoint.'
Write a release note 'Write a release note entry. Change type: [type].
Engineering note: [paste]. MSTP style. Active voice.
Verb-first.'
Draft a troubleshooting step 'Write a troubleshooting procedure. Problem:
[symptom]. Resolution: [steps]. Format: MSTP
numbered steps.'
Review your own writing 'Review this paragraph against MSTP. Flag: passive
voice, second-person violations, heading format
issues.'
Generate a doc outline from YAML 'Based on this OpenAPI spec [paste], generate a
complete documentation outline. Task-oriented topic
names only.'
Write a Postman test script 'Write a Postman JS test script for [endpoint]. Test:
status 200, field [x] present, response time < 2s.'
Improve existing AI output 'Your previous output used passive voice. Rewrite
using active voice throughout. Keep all technical
content identical.'

Key Takeaway
Prompt engineering does not make technical writers obsolete. It makes skilled technical
writers exponentially more productive.
The quality gate is still you.