What is The Onboarding Writer?

The Onboarding Writer is a 3-step documentation flow that solves two persistent problems with AI-generated documentation: content that skips context to jump straight to instructions, and quality that degrades across a long documentation set. It chains Role Prompting to establish the documentation standard, IEEI to enforce a pedagogical structure in every section, and Few-Shot to lock in quality across scale.

The flow is built around one insight: great documentation is teaching, not information transfer. The Role Prompting and IEEI steps enforce the sequential logic of teaching — context and motivation before instruction. The Few-Shot step ensures that quality remains consistent whether you're writing the third section or the thirtieth.

When to Use The Onboarding Writer

🚀

Product Onboarding

First-run guides and getting started sequences where users have no prior context and every friction point causes abandonment.

🔌

API Documentation

Developer-facing API docs where every endpoint explanation must answer "what, when, why, and what next" simultaneously.

📚

Knowledge Bases

Help center articles and internal wikis where quality consistency across hundreds of articles is the hardest problem.

🎓

Tutorial Series

Multi-part tutorials where each lesson must build on the last and the pedagogical structure must remain consistent.

📋

Standard Operating Procedures

Internal SOPs where the reader is an expert in their domain but new to this specific process.

💻

README Files

Project and library README files where developers need to go from "never heard of it" to "using it in production" in one read.

The Flow Algorithm

1

Role Prompting — Set the Standard

Define a specific documentation persona with named quality values. The persona should reference a recognized documentation standard (Stripe docs, Linear changelog, Notion's help center) and specify what that standard means: no assumed context, progressive disclosure, every instruction preceded by motivation. Include the target audience's knowledge level explicitly — "readers are experienced developers but have never used this API" sets a very different bar than "readers are technical."

Produces:

A documentation persona and quality standard that every subsequent section is held to. The standard is explicit, not implicit — the model can't drift from what it can't see.

2

IEEI — Structure for Learning

Apply IEEI structure to each documentation section: Inform (what this concept/feature is — one clear sentence), Explain (why it matters and when you'd need it — the motivation before the instruction), Example (a concrete, working example — not a diagram or pseudocode, a real instance), Input (the specific action the reader takes next — what they should do now). The IEEI sequence prevents the most common documentation failure: starting with "to do X, run Y" before the reader knows what X is or why they'd want it.

Produces:

A pedagogically structured first section draft where context is always established before instruction. Readers understand the "why" before encountering the "how."

3

Few-Shot Prompting — Lock in Quality

Use the approved IEEI-structured section from Step 2 (or 2-3 sections if available) as few-shot examples in all subsequent section prompts. Provide the examples explicitly in each prompt: "Here are 2 examples of our documentation style. Write the next section in the same structure and voice." The examples enforce quality through demonstration rather than description — the model matches what it sees, not what it's told.

Produces:

Documentation sections that maintain consistent structure, voice, and quality across the entire set — regardless of how many sections are generated. Quality doesn't drift when it's anchored to examples.

Example Prompt Sequence

Step 1 — Role Prompting

You are a technical writer whose documentation standard matches Stripe's API docs: zero assumed knowledge, every concept explained before it's used, every instruction preceded by a motivation sentence, and every example is a complete, runnable code snippet (not pseudocode).

Your readers: Backend developers with 3+ years of experience in their language, but who have never used this API. They are skeptical — they've been burned by bad docs before.

Your documentation rule: Never write an instruction before writing the reason the reader would want to follow it.

With this standard in mind, write the first section of a getting-started guide for a webhook integration API.

Step 2 — IEEI Structure

Using the documentation standard from Step 1, write the "Authentication" section for the webhook integration guide using the IEEI structure:

Inform: What is the authentication method (1 sentence, no jargon)?
Explain: Why does this method exist — what security problem does it solve, and why would the developer care?
Example: A complete, runnable code snippet showing a correctly authenticated API request. Include the exact header format. Use Python.
Input: What is the single next action the reader should take after reading this section?

Strictly follow the IEEI order. Do not start with code. Start with Inform.

Step 3 — Few-Shot for Scale

Here are two examples of our documentation style for the webhook integration guide:

EXAMPLE 1 — Getting Started section:
[PASTE STEP 1 OUTPUT HERE]

EXAMPLE 2 — Authentication section:
[PASTE STEP 2 OUTPUT HERE]

Using exactly the same structure, voice, and level of detail as these two examples, write the "Handling Webhook Events" section. Cover: receiving the webhook payload, verifying the signature, parsing event types, and responding with a 200 status.

Pros and Cons

Strengths

  • IEEI prevents the "instructions before context" failure
  • Role Prompting sets an explicit, referenceable quality bar
  • Few-Shot scales quality across large documentation sets
  • Beginner-friendly — each framework is straightforward
  • Works for any technical domain or product type

Trade-offs

  • First 2 sections (Steps 1-2) require review before using as Few-Shot anchors
  • Few-Shot can propagate errors if exemplars have issues
  • IEEI adds length — appropriate for docs, not for quick references
  • Role persona needs to match your actual documentation standards

Frequently Asked Questions

What is The Onboarding Writer prompt flow?

The Onboarding Writer chains Role Prompting, IEEI (Inform, Explain, Example, Input), and Few-Shot Prompting to produce pedagogically sound, stylistically consistent documentation. It prevents the two most common documentation failures: telling users what to do before explaining why, and writing sections that gradually drift in quality.

Why does Role Prompting come first in a documentation flow?

Documentation quality is set by the standards the writer holds. By establishing a specific, named documentation persona (e.g., 'technical writer at Stripe whose docs are famous for zero assumptions and progressive disclosure'), the model applies those standards to every section. Without a persona, the model defaults to a generic 'helpful assistant' voice that lacks a consistent quality bar.

What does IEEI stand for and why is it good for onboarding?

IEEI stands for Inform, Explain, Example, Input. It enforces a pedagogical sequence that matches how people learn: first tell them what something is (Inform), then explain why it matters (Explain), then show a concrete example (Example), then ask them to take the next action (Input). This prevents the most common documentation skip: jumping from definition straight to instructions without building context.

How do I use Few-Shot in a documentation flow?

Write or generate 2-3 exemplary documentation sections using the IEEI structure and your role persona. Then use these as Few-Shot examples when prompting for the remaining sections. The model matches the quality, structure, and voice of the examples, preventing the gradual quality drift that affects long documentation sets.

Can this flow be used for API documentation?

Yes. In the Role Prompting step, specify an API documentation persona (e.g., 'Stripe API docs author who explains every endpoint as if the reader is smart but has never seen this API'). IEEI maps perfectly to API documentation: Inform (what this endpoint does), Explain (when and why to use it), Example (working code sample), Input (the next call the user should make).

How does this flow scale to large documentation sets?

The scaling power comes from Few-Shot. Once you've generated and approved 2-3 IEEI-structured sections, those become your quality anchors. Every subsequent section is prompted against those exemplars, ensuring consistent structure and voice across 10, 50, or 200 pages. Update the exemplars if quality drifts.