A great knowledge base article gets a stuck user un-stuck in under a minute. That means answering the exact question they searched, structuring the content so they can skim to the relevant step, and writing in plain language without jargon. This builder turns your topic and article type into a prompt that makes an LLM produce a scannable, correctly structured draft you can edit and publish.
How it works
You enter the topic, your product name, and the precise user question the article should answer, then choose the article type. A how-to produces a goal-oriented intro plus numbered steps with expected results. A reference produces a definition, then a structured description of options or settings. A troubleshooting guide starts from the symptom and walks through likely causes and fixes in order of probability. The prompt instructs the model to use descriptive headings, short paragraphs, second-person active voice, and callouts for tips and warnings, and to end with related-articles suggestions. You can set a reading level to keep the language accessible. Everything is generated locally.
Matching article type to user intent
Choosing the wrong article type is one of the most common help-centre mistakes, and it makes articles harder to use even when the information is technically correct.
How-to articles suit task-oriented intent: the user wants to complete something and needs a sequence of steps. The structure is goal statement → prerequisite conditions → numbered steps with expected outcomes at each step → confirmation that the task is complete. Bullet points within a step are fine; do not use bullet points for the main steps themselves, because the order matters. For example, “How to export your invoices to CSV” is a how-to: the user has a specific thing they want to do.
Reference articles suit informational intent: the user wants to understand what something is or how it works, not to complete an immediate task. The structure is a clear definition → a description of each option, field, or parameter → when to use each one. For example, “What do the invoice status labels mean?” is reference: the user wants to understand terminology, not take an action.
Troubleshooting guides suit problem-solving intent: the user has a specific symptom and needs help diagnosing and fixing it. The structure is symptom statement → ordered list of likely causes (most common first) → the fix for each cause. For example, “Why is my export showing as empty?” is troubleshooting. The structure should let users skip to the cause that matches their situation.
Mixing these structures — putting steps inside a reference article, or listing causes in a how-to — forces the reader to work harder than they should.
What makes a help article findable
Help articles live or die by how well they match the words users actually type into search. Write the question as a user would express it, not as a product team would name the feature.
Compare: “Invoice export functionality overview” (internal naming, not searched) versus “How do I export invoices to a spreadsheet?” (natural language, searched daily). The second form also tells you exactly what structure the article should have — it is a task, so write a how-to.
A reliable approach is to look at your support ticket history or search query logs and write article titles directly from the language customers use. Those titles become your H1 heading, which carries the most weight for search and for the reader deciding whether they are in the right place.
Tips and examples
Write the user question using the words a real customer would type into search, not the way your team names the feature internally — that single choice drives findability. Match the type to the intent: do not write a reference article when the user has a task to complete. For consistent voice across your help centre, paste one or two of your best existing articles into the prompt as style examples; the model will mimic their tone far more reliably than any adjective you supply. Always edit the draft against the real product UI before publishing — an AI can describe a plausible but incorrect flow if it has not been trained on your specific product’s current interface.