Mohit Aggarwal Help Center Article Skill
A help article's job is deflection: the user finds it, solves their problem, and never opens a ticket. That requires a findable title (what they'd search), the answer up front (not after three paragraphs of preamble), and skimmable steps. This skill writes that — task-based, scannable, and SEO/search-friendly so it surfaces both in your help center and in Google.
Required Inputs
Ask for these only if they aren't already provided:
- The task/problem — what the user is trying to do or fix (phrased as they'd search it).
- The solution — the steps or answer.
- Audience — end-user vs. admin/developer (changes depth and terminology).
- Edge cases / gotchas — common failure points and prerequisites.
Output Format
[Task-based title — what the user searches]
e.g. "How to reset your password" / "Why is my export failing?" — not "Password Management."
1. Short answer (TL;DR) — resolve it in 1–2 sentences right at the top for the people who just need the quick fix. Then the detail for those who need it.
2. Before you start — prerequisites/permissions, if any (so step 3 doesn't fail silently).
3. Steps — numbered, one action per step, in the user's language. Mark where a [screenshot] should go. Bold the buttons/menu names they'll click.
4. Troubleshooting — the 2–4 common "it didn't work" cases and the fix for each. This is what prevents the follow-up ticket.
5. Related articles — links to the adjacent tasks (the next thing they'll need).
SEO/findability note: use the words users actually type (synonyms in the body), keep the title a real question/task, and front-load the answer.
Quality Checks
- Title is a task/question the user would actually search (not an internal category name)
- The answer is at the top (TL;DR), not buried under preamble
- Steps are numbered, one action each, with bolded UI labels and screenshot markers
- Prerequisites are stated before the steps
- A troubleshooting section heads off the common follow-up tickets
- Uses the user's vocabulary (findable in search), not internal jargon
Anti-Patterns
- Do not bury the answer — front-load it; most readers want the quick fix, not your intro
- Do not title by internal feature name — title by the user's task/question, or they won't find it
- Do not skip troubleshooting — the "it didn't work" cases are exactly what generate the ticket you're trying to deflect
- Do not use internal jargon — write the words users type
- Do not cram multiple tasks into one article — one task per article = better search + clearer steps
Based On
Knowledge-base / technical-writing practice — task-based titles, answer-first, scannable steps, search-optimised, ticket-deflection focus.