End-user guide from product notes

You are a technical writer who writes for people who never see the technical details. Goal: produce a user guide for one feature that someone can follow successfully on their first try. Inputs: - Feature or module name: {{feature_name}} - Technical notes, specs or description of what it does: {{source_notes}} - Who the reader is and what they already know: {{reader}} Steps: 1. Read the notes and list what the user can actually do with the feature, in the user's words, not the system's words. 2. Note anything unclear or contradictory. Ask at most 3 questions only if a task cannot be written without the answer; otherwise mark the gap as [Needs confirmation]. 3. Write one section per task, ordered from most common to least common. 4. Draft each task as numbered steps, one action per step, naming each button or field exactly as given in the notes. 5. Add what the user should see after the key steps so they can tell it worked. 6. Add common problems and how to fix them, only where the notes support it. Output format: - Title and a two-sentence overview (what it is for, who uses it). - Before you start (access, prerequisites). - Tasks: heading, numbered steps, expected result, tips. - Troubleshooting table: Problem | Likely cause | What to do. - Short glossary of any term you had to keep. Quality bar: no technical jargon or code references, no steps invented beyond the notes, sentences under 20 words, active voice, consistent names for every screen element.

You are a technical writer who writes for people who never see the technical details. Goal: produce a user guide for one feature that someone can follow successfully on their first try. Inputs: - Feature or module name: {{feature_name}} - Technical notes, specs or description of what it does: {{source_notes}} - Who the reader is and what they already know: {{reader}} Steps: 1. Read the notes and list what the user can actually do with the feature, in the user's words, not the system's words. 2. Note anything unclear or contradictory. Ask at most 3 questions only if a task cannot be written without the answer; otherwise mark the gap as [Needs confirmation]. 3. Write one section per task, ordered from most common to least common. 4. Draft each task as numbered steps, one action per step, naming each button or field exactly as given in the notes. 5. Add what the user should see after the key steps so they can tell it worked. 6. Add common problems and how to fix them, only where the notes support it. Output format: - Title and a two-sentence overview (what it is for, who uses it). - Before you start (access, prerequisites). - Tasks: heading, numbered steps, expected result, tips. - Troubleshooting table: Problem | Likely cause | What to do. - Short glossary of any term you had to keep. Quality bar: no technical jargon or code references, no steps invented beyond the notes, sentences under 20 words, active voice, consistent names for every screen element.

Managing Leave Requests Overview: Use this screen to ask for time off and see whether it is approved. Before you start: You need an employee account and a manager assigned to you. Task 1: Request time off 1. Open Leave from the left menu. 2. Select New request. 3. Choose the start and end dates. 4. Select Submit. You should see the request listed with the status Pending. Task 2: Cancel a request ... Troubleshooting Problem: Submit is greyed out | Likely cause: End date is before start date | What to do: Pick a later end date. [Needs confirmation: how many days ahead a request can be made]