Study Guide: Alex for Technical Writers
Your reference for using Alex in documentation, content strategy, and technical communication. Ready-to-run prompts for docs, API references, user guides, and content systems.
What This Guide Is Not
This is not a habit formation guide (see Self-Study Guide for that). This is a technical writing toolkit — the specific ways Alex can accelerate your documentation work and elevate every piece you ship.
Core Principle for Technical Writers
Technical writing is about making the complex accessible without sacrificing accuracy. Alex can help you draft faster, structure more clearly, and edit more ruthlessly — but the technical accuracy and the audience empathy are yours. You must understand what you’re documenting. Alex can help you say it better.
The key pattern: bring the technical content. Paste the code, the spec, the engineering notes. Alex can turn technical input into clear documentation; it can’t invent accurate technical content.
The Seven Use Cases
1. API and Reference Documentation
When to use: Documenting endpoints, parameters, SDKs, command-line tools.
Prompt pattern:
Help me document this API:
Type: [REST / GraphQL / CLI / SDK]
Resource/command: [what it does]
Technical spec:
[paste the actual spec, schema, or code comments]
Audience: [developer experience level]
Existing pattern: [how similar things are documented in this product]
Create documentation that:
1. Opens with what this does and when to use it
2. Covers all parameters with type, required/optional, description
3. Shows a realistic example request and response
4. Lists error codes and what they mean
5. Notes edge cases and known limitations
Follow-up prompts:
Add a code example in [Python / Node / curl].
The response schema is complex. Create a visual table.
What important edge case am I not documenting?
2. User Guides and How-To Documentation
When to use: End-user documentation, getting started guides, task-based instructions.
Prompt pattern:
Help me write a user guide:
Product/feature: [what you're documenting]
Audience: [who reads this, assumed knowledge]
Task: [what the user is trying to accomplish]
Steps: [the actual procedure, in rough form]
Create a guide that:
1. States the goal and prerequisites upfront
2. Numbers steps clearly
3. Explains why, not just how, for non-obvious steps
4. Includes tips for common mistakes
5. Ends with a success state so users know they're done
Follow-up prompts:
Add a troubleshooting section for the most common failure.
This assumes too much knowledge. Simplify for beginners.
Convert this to a quick reference card.
3. Conceptual Documentation
When to use: Architecture docs, concept explanations, mental model building.
Prompt pattern:
Help me explain this concept:
Concept: [what you're explaining]
Audience: [background level]
Why they need to understand this: [what it enables]
Technical details:
[paste engineering documentation, notes, or descriptions]
Create an explanation that:
1. Starts with the mental model, not the implementation
2. Uses analogy where helpful
3. Explains relationships between components
4. Distinguishes what users need to know from implementation detail
5. Sets up the more detailed reference docs
Follow-up prompts:
This is too abstract. Add a concrete example.
The analogy breaks down here. Fix it.
What would a new engineer on this team still not understand after reading this?
4. Release Notes and Changelogs
When to use: Documenting changes, new features, deprecations, migrations.
Prompt pattern:
Help me write release notes:
Version: [number]
Changes:
[list the changes, in raw form from engineering notes]
Audience: [developers / admins / end users]
Tone: [technical / conversational / formal]
Create release notes that:
1. Lead with what matters most to users
2. Clearly distinguish new features, improvements, and bug fixes
3. Flags breaking changes prominently
4. Explains migration steps where needed
5. Uses the same terminology as the product
Follow-up prompts:
This breaking change needs a stronger warning.
Rewrite for a non-technical audience.
Write the migration guide for [deprecated feature].
5. Content Audits and Information Architecture
When to use: Reorganizing documentation, auditing for gaps, restructuring content.
Prompt pattern:
Help me audit/restructure this content:
Current state: [describe or paste content inventory]
User goals: [what readers are trying to accomplish]
Pain points: [where users get lost or confused]
Constraints: [platform, tooling, team size]
Help me:
1. Identify gaps in current coverage
2. Find duplicate or contradictory content
3. Propose a clearer information architecture
4. Define content types and their purpose
5. Prioritize what to fix first
Follow-up prompts:
Design the navigation structure for [product area].
Map user journeys to documentation entry points.
Identify the 5 most important docs to have great, vs. 50 mediocre ones.
6. Style and Standards
When to use: Building style guides, reviewing for consistency, defining voice.
Prompt pattern:
Help me develop documentation standards:
Current state: [describe existing standards or lack thereof]
Product type: [developer tool / enterprise software / consumer]
Voice: [how the product communicates]
Audience: [who reads the docs]
Create standards that cover:
1. Voice and tone guidelines with examples
2. Terminology — preferred terms and ones to avoid
3. Formatting rules (headings, code, lists, links)
4. Common patterns (warnings, notes, tips)
5. Review criteria for editors
Follow-up prompts:
Review this document for style consistency.
[paste document]
Write the entry for [term] in the terminology glossary.
Create the pull request template for doc contributions.
7. Cross-Functional Collaboration
When to use: Working with engineers, PMs, and designers to get content from them.
Prompt pattern:
Help me get what I need from [stakeholder]:
Stakeholder: [engineer / PM / designer / support]
What I need: [information, review, approval]
What's blocking me: [why I'm not getting it]
Deadline: [timeline]
Help me:
1. Draft the ask in their language
2. Make it easy to give me a useful answer
3. Reduce the lift on their end
4. Follow up without being annoying
5. Document what I learn so I don't have to ask again
Follow-up prompts:
Write an interview guide for extracting docs content from an SME.
The engineer's explanation is accurate but unusable. How do I translate it?
Create a docs review checklist for engineers.
Practice Progression
Week 1: Document an API endpoint using the reference docs prompts.
Week 2: Rewrite an existing user guide using the how-to framework.
Week 3: Audit a content area and propose a new structure.
Week 4: Draft a style guide section for your team.
What Great Looks Like
After consistent use, you should notice:
- Faster first drafts with less blank page anxiety
- Cleaner structure from the start
- More consistent application of style
- Less back-and-forth with engineers
The goal isn’t for Alex to write your docs — it’s for Alex to help you write better docs, faster.