Turn a shipped feature into user-facing documentation
Produces a clear help-doc page for a feature so customers stop emailing support to ask how it works.
When to use it: When a feature or internal system exists but the only documentation is in the builder's head, and customers or staff keep asking the same how-to questions.
You are a technical writer producing user-facing documentation for an Australian small business's product. Write for busy, non-technical readers.
<context>
PRODUCT + WHO USES IT: [e.g. "TradieBooks - job-quoting app used by solo electricians"]
FEATURE OR SYSTEM TO DOCUMENT: [e.g. "recurring invoice schedules"]
HOW IT ACTUALLY WORKS: [paste the steps, screens, settings and limits exactly as they behave - include what happens on errors]
COMMON QUESTIONS OR MISTAKES: [e.g. "people set the start date in the past and nothing sends"]
WHERE THIS DOC LIVES + FORMAT: [e.g. "help centre article, markdown"]
</context>
Before writing, list the 2-3 points where a first-time user is most likely to get stuck, based only on the material above, and design the doc around them.
Requirements:
1. Open with one sentence saying what the feature does and when to use it - outcome first, no marketing.
2. State prerequisites (plan level, permissions, setup) before any steps.
3. Number the steps; one action per step, each followed by what the user should now see.
4. Cover the provided error states and mistakes in an "If something's not right" section - symptom, cause, fix.
5. End with a short FAQ using the provided common questions, answered in two sentences each.
<output_format>
Title, one-line summary, Prerequisites, Steps, If something's not right (table), FAQ. Plain English, en-AU spelling; define any technical term you must keep.
</output_format>
Grounding: describe only behaviour stated above. If a step, limit or error state is missing, insert [NEEDED: ...] rather than guessing - wrong docs are worse than no docs.Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.
Want it tuned to your business? Bring it to the free weekly call and we'll adapt it live.
Join the free callMore coding & technical prompts
Keep a Two-Minute Daily Engineering Log That Pays Off Later
Turn end-of-day scraps into a structured log entry — decisions with their why, lessons, blockers — capped at 120 words and searchable months later.
Break a Stalled Decision With a Structured Tiebreak
Lay out the options, score them against your own criteria, price the delay, and get a verdict with a 48-hour commitment step — plus what would legitimately reopen it.
Engineer a Distraction-Proof Deep-Work Block
Set up a recurring focus block matched to your energy and team reality — device rules, a status script, an interruption protocol and a two-week bedding-in plan.