Knowledge Base Writer

A help article succeeds when the reader finishes the task and never contacts support; everything else is decoration. This skill writes knowledge-base articles to that standard: one task per article, titled in the user's own words, prerequisites declared before step one, steps that say what the reader should now see, and troubleshooting for the places they will actually get stuck.

When to use this skill

• A how-to, setup guide, or troubleshooting article needs writing for a help center
• Support keeps answering the same question and the answer belongs in an article
• Articles exist but users still file tickets — they need rebuilding, not polishing
• A feature is shipping and its documentation must exist before the tickets do
• One article covers three tasks at once and needs splitting

Workflow

1. Fix the single task the article serves, phrased the way the user would say it. If the draft covers connecting an account and configuring it, that is two articles with a link between them.
2. Title the article with the user's words for the task — the phrase they would type into the search box, frustrated. "Reset a teammate's password" beats "Credential management".
3. Open with a one-sentence promise: what the reader will have accomplished at the end, roughly how long it takes, and who is able to do it.
4. Declare prerequisites before step one: required role or permission, plan level if relevant, and anything to have ready. Discovering a missing permission at step six is how tickets happen anyway, article and all.
5. Write numbered steps, one action each. Name interface elements in bold exactly as the product spells them, and after any step that changes the screen, say what the reader should now see — that sentence is what tells them they are still on the path.
6. Mark where a screenshot earns its place: state-changing moments and hard-to-find controls, not decoration on every step. Each marker notes what the image must show.
7. Add troubleshooting as "If X, then Y" pairs for the two to four likeliest failure points — sourced from real tickets where they exist, not from imagination.
8. Close with related articles: the next task a finisher would want, two or three links, never a link farm.
9. Stamp the metadata: audience, product area, version or date last verified, owning team.

Output format

# <Task, in the user's words>

<What you'll accomplish, how long it takes, who can do this.>

Before you start: <role or permission> · <plan, if relevant> · <have this ready>

## Steps
1. Open **<location>**.
2. Select **<element>**. You should see <what appears>.
...
N. <Final action>. You're done when <observable end state>.

## If something goes wrong
- If <symptom>, then <fix or check>.
- If <symptom>, then <fix or check>.

Related: <next-task link> · <adjacent-task link>
Last verified: <date> · Applies to: <version or plan>

Quality bar

• Steps are verified against the current product flow, not memory — and the last-verified date proves someone did.
• No step contains "simply", "just", or "easily"; if it were easy, the article would not exist.
• A reader who hits either of the two most common errors recovers without leaving the page.
• The title matches what a frustrated user would search, not what the feature is called internally.
• One task, start to finish; anything adjacent is a link, not a detour.