Help Center Articles skill for Claude Code
Customers find the answer and never open a ticket. Claude writes knowledge base articles from real demand. It mines tickets and search logs for the phrases customers use, picks the right article type, does the task in the product to capture exact labels, writes one-action steps with expected results and role prerequisites, adds symptom-cause-fix troubleshooting, and runs a bundled linter for titles, alt text, link text, and step problems.
- name
help-center-articles - size177 lines · ≈1,900 tokens
- files2
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Writes end-user help center and knowledge base articles - choosing the article type (how-to, troubleshooting, FAQ, concept), titles in the words customers search with, a summary line, prerequisites with plan and permission requirements, numbered steps with exact UI labels and expected results, purposeful annotated screenshots with alt text, symptom-cause-fix troubleshooting sections, related links, and maintenance tied to releases - checked with a bundled article linter. Use when writing or rewriting support docs, knowledge base or FAQ pages, reducing repeat support tickets, or when help articles are outdated, hard to find, or do not match the product UI. Try asking
- Write help articles for the top 10 ticket topics from this support export
- Rewrite our 'Billing overview' article so customers can actually export invoices
- Audit the help center folder for vague titles, missing alt text, and long step lists
Use it when
- Writing or rewriting end-user help or knowledge base articles
- Repeat support tickets point to missing or unclear docs
- Help articles are outdated or do not match the current UI
- Building troubleshooting pages for common errors
Skip it when
- The readers are developers integrating an API — use api-documentation
- You are writing the in-product error text itself — use ux-microcopy
How to check the result
Run scripts/check_article.py on the articles, have someone unfamiliar with the feature follow the steps in the live product, and track ticket volume on the topic afterward.
The common mistake it prevents
Writing steps from the spec or memory instead of the shipped UI, so labels and menus are wrong the day the article goes live.
A help article works when a customer who searched in their own words lands on it, follows it without contacting support, and ends with the task done. The measures are search success, helpfulness votes, and fewer tickets on that topic, not word count or polish.
Ground rules
- One task or one problem per article. Split anything that needs “and” in its title.
- Use the customer’s words, from tickets and search logs, in titles and first lines; use the product’s exact UI labels in steps.
- Every article is verified against the current UI before publishing, by doing the steps.
- Screenshots only where they remove doubt; each one is a maintenance cost.
- Say who can do it: plan, role, platform. Half of “it doesn’t work” tickets are permissions.
Pick the article type
| Customer intent | Type | Title pattern |
|---|---|---|
| “How do I …?” | How-to | Verb-first task: “Export invoices as CSV” |
| “X isn’t working” | Troubleshooting | Symptom in their words: “Invoice export is empty or fails” |
| Quick factual questions | FAQ / reference | The question itself or the noun: “Supported file types for import” |
| “What is X / should I use it?” | Concept | “How workspaces and projects relate” |
Workflow
- [ ] 1. Find the demand: tickets, search queries with no results, chat logs
- [ ] 2. Pick the type and write the title in customer words
- [ ] 3. Do the task in the product; record exact labels and results
- [ ] 4. Write: summary, prerequisites, steps, result, troubleshooting, related
- [ ] 5. Add screenshots only where needed; annotate; alt text
- [ ] 6. Lint and review
- [ ] 7. Publish with search keywords; link from the product where users get stuck
- [ ] 8. Measure helpfulness and ticket deflection; update on releases
1. Demand
Pull the last 90 days of support tickets and help-center search terms. Group by intent, count, and note the exact phrases customers use (“download my bills” when the UI says “Export invoices”). Write articles for the top intents first; update existing articles whose topics still generate tickets.
2-3. Title and research
- Titles: 4-10 words, task or symptom first, no product-internal jargon, no “How to use the X feature”. Add synonyms customers use to the summary line or search keywords.
- Do the task yourself in the product, on the plan and role a typical customer has. Write down each label exactly as shown (capitalization included), where it is, and what appears after each action.
4. Structure (how-to)
# Export invoices as CSV
Download your invoices as a spreadsheet for accounting or expense reports.
**Who can do this:** Workspace owners and billing admins on any paid plan.
**Before you start:** Invoices appear after your first payment.
1. In the left sidebar, select **Settings** > **Billing**.
2. Under **Invoices**, select **Export**.
3. Choose a date range.
4. Select **Download CSV**.
The file downloads to your browser's download folder as `invoices-YYYY-MM.csv`.
## If the export is empty or fails
- **The file has no rows:** The date range has no invoices. Widen the range.
- **You don't see Export:** Your role doesn't include billing access. Ask a workspace
owner to change your role. [Change member roles](link)
## Related
- [Update billing details](link)
- [Understand invoice line items](link)
Step rules:
| Rule | Example |
|---|---|
| One action per step, imperative | “Select Save.” not “Then you will want to save” |
| Location before action | “In the top-right corner, select Share.” |
| Exact UI labels in bold | Billing, matching case |
| Device-neutral verbs | select, enter, choose (not click, hit) |
| Show results that confirm progress | “A green banner confirms the export started.” |
| 3-10 steps; split longer tasks | Link sub-tasks instead of 25 steps |
| Platform differences in labeled sections or tabs | “On iOS” / “On Android” |
| Never hide a required condition in a step | Put it in prerequisites |
Troubleshooting article structure: symptom (as the customer sees it, including exact error text), then causes ordered from most to least common, each with a fix and a way to confirm it worked, then “Still stuck?” with what to include when contacting support (account ID, screenshot, time of error).
5. Screenshots and media
| Use a screenshot when | Skip it when |
|---|---|
| The control is hard to find | The step names a clearly labeled button |
| The screen has many similar options | The UI changes often (high upkeep) |
| The result needs visual confirmation | Text already describes it fully |
- Crop to the relevant area; annotate with one box or arrow; use sample data, never real customer data.
- Alt text describes the purpose: “Billing page with the Export button highlighted”.
- Name files by article and step (
export-invoices-step2.png) so they are easy to find when the UI changes. - Short GIFs or videos for multi-step drags or gestures; always with text steps too.
6. Lint and review
python3 scripts/check_article.py articles/export-invoices.md
python3 scripts/check_article.py articles/ # whole folder
The script flags: titles that are not task or question shaped (generic starts like “Overview”, “Using the”, “Introduction to”), missing summary line, how-to articles without numbered steps, more than 12 steps, steps with multiple actions joined by “and then”, images without alt text, “click here” and bare-URL links, device-specific verbs (click, tap) outside platform sections, words that blame the reader (“simply”, “just”, “easy”), and sentences over 30 words. It exits 1 if any article has errors.
Then a human review: a support agent checks it answers the real tickets; someone unfamiliar with the feature follows the steps.
7. Publish and connect
- Add search keywords and synonyms from step 1 (most help-center platforms support them).
- Link the article from the product where users get stuck (empty states, error messages, settings pages) and from support macros so agents send the same answer.
- Cross-link related articles; avoid orphan pages.
8. Measure and maintain
- Track per article: views, helpfulness votes, searches that end on it, tickets on the topic before and after.
- Low helpfulness plus high views = rewrite first.
- Tie articles to features: when a release changes UI labels or flows, the release checklist includes updating affected articles and screenshots. Keep a “last verified” date in metadata.
- Localize after the source article is stable; screenshots need localized versions or must be text-light.
Gotchas
- Writing from the spec instead of the shipped product produces wrong labels on day one.
- Combining admin and member instructions in one flow confuses both; split by role or use clearly labeled sections.
- “Contact support” as the only troubleshooting step guarantees tickets.
- Marketing tone (“our powerful new export feature”) slows readers down; state the task.
- Deleting or renaming articles breaks links from the product and from old tickets; set redirects.
Output contract
# <Task or symptom in customer words>
<One-sentence summary with customer synonyms>
**Who can do this:** <plan, role, platform> **Before you start:** <conditions>
1-10 numbered steps (exact bold UI labels, location then action, results)
<Expected end result>
## If <common failure> - symptom, cause, fix
## Related - 2-4 links
Metadata: keywords <list>, last verified <date>, owner <team> Bundled files
Loaded only when a step in the skill needs them. Review them here before installing.
scripts/check_article.py
#!/usr/bin/env python3
"""Lint end-user help center articles written in Markdown.
Usage:
python3 check_article.py <file.md | directory> [--max-steps 12] [--max-words 30]
Checks per article:
errors - no H1 title; generic title start (Overview, Introduction to, Using the, About the,
All about); missing summary paragraph right after the title; how-to article (title
starts with a verb) without a numbered list; images without alt text;
"click here" / "here" link text
warnings - more than --max-steps numbered steps in one list; a step with several actions
("and then", "then"); bare URLs; device-specific verbs (click, tap, right-click)
outside a platform-labeled section; reader-blaming words (simply, just, easy,
obviously); sentences longer than --max-words words; title longer than 70 chars
Exits 1 if any article has errors, 2 if no Markdown files are found.
"""
import argparse
import os
import re
import sys
GENERIC = re.compile(r"^(overview|introduction to|intro to|using the|about the|all about|the .* feature)\b", re.I)
VERB_START = re.compile(r"^(add|change|connect|create|delete|disable|download|edit|enable|export|find|"
r"import|install|invite|manage|move|remove|rename|reset|restore|set up|"
r"share|sign|turn|update|upgrade|use|view|cancel|configure|transfer|merge|"
r"schedule|send|archive|recover|verify|switch|print|pay)\b", re.I)
BLAME = re.compile(r"\b(simply|just|easy|easily|obviously|of course)\b", re.I)
DEVICE = re.compile(r"\b(click|clicking|right-click|double-click|tap|tapping)\b", re.I)
PLATFORM_HEAD = re.compile(r"^#+\s.*\b(ios|android|mac|macos|windows|desktop|mobile|web|linux)\b", re.I)
IMG = re.compile(r"!\[([^\]]*)\]\([^)]+\)")
LINK = re.compile(r"(?<!!)\[([^\]]+)\]\([^)]+\)")
BARE_URL = re.compile(r"(?<![(<\[])\bhttps?://\S+")
STEP = re.compile(r"^\s*\d+[.)]\s+(.*)")
MULTI = re.compile(r"\b(and then|, then|then select|then choose|then enter)\b", re.I)
def check(path, max_steps, max_words):
errors, warnings = [], []
lines = open(path, encoding="utf-8").read().splitlines()
in_code = False
body = []
for i, line in enumerate(lines, 1):
if line.strip().startswith("```"):
in_code = not in_code
continue
if not in_code:
body.append((i, line))
title_i = next(((i, l) for i, l in body if l.startswith("# ")), None)
if not title_i:
errors.append("no H1 title")
title = ""
else:
title = title_i[1][2:].strip()
if GENERIC.match(title):
errors.append(f"generic title start: {title!r}; name the task or symptom")
if len(title) > 70:
warnings.append(f"title is {len(title)} chars; keep under 70")
after = [l for i, l in body if i > title_i[0] and l.strip()]
if not after or after[0].lstrip().startswith(("#", "1.", "-", "*", "!", "|")) and not after[0].startswith("**"):
errors.append("missing one-sentence summary paragraph after the title")
steps_runs, run = [], []
platform_section = False
for i, line in body:
if line.startswith("#"):
platform_section = bool(PLATFORM_HEAD.match(line))
m = STEP.match(line)
if m:
run.append((i, m.group(1)))
if MULTI.search(m.group(1)):
warnings.append(f"line {i}: step may contain several actions; split it")
elif line.strip() and run:
steps_runs.append(run)
run = []
for alt in IMG.findall(line):
if not alt.strip():
errors.append(f"line {i}: image without alt text")
for text in LINK.findall(line):
if text.strip().lower() in ("here", "click here", "this link", "link"):
errors.append(f"line {i}: non-descriptive link text {text!r}")
if BARE_URL.search(line):
warnings.append(f"line {i}: bare URL; use descriptive link text")
if not platform_section and DEVICE.search(line):
warnings.append(f"line {i}: device-specific verb {DEVICE.search(line).group(0)!r}; prefer 'select'")
b = BLAME.search(line)
if b:
warnings.append(f"line {i}: reader-blaming word {b.group(0)!r}")
if not line.lstrip().startswith(("|", "#")):
for sent in re.split(r"(?<=[.!?])\s+", re.sub(r"[*`_]", "", line)):
n = len(sent.split())
if n > max_words:
warnings.append(f"line {i}: sentence of {n} words")
if run:
steps_runs.append(run)
if title and VERB_START.match(title) and not steps_runs:
errors.append("how-to title but no numbered steps")
for r in steps_runs:
if len(r) > max_steps:
warnings.append(f"line {r[0][0]}: {len(r)} steps in one list; split into sub-tasks")
return errors, warnings
def main():
ap = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
ap.add_argument("target")
ap.add_argument("--max-steps", type=int, default=12)
ap.add_argument("--max-words", type=int, default=30)
args = ap.parse_args()
if os.path.isdir(args.target):
files = sorted(os.path.join(dp, f) for dp, _, fs in os.walk(args.target) for f in fs if f.endswith((".md", ".mdx")))
else:
files = [args.target] if args.target.endswith((".md", ".mdx")) else []
if not files:
print("error: no Markdown files found", file=sys.stderr)
sys.exit(2)
failed = 0
for f in files:
errs, warns = check(f, args.max_steps, args.max_words)
status = "FAIL" if errs else ("WARN" if warns else "OK")
print(f"{status:4} {f} ({len(errs)} errors, {len(warns)} warnings)")
for e in errs:
print(f" error: {e}")
for w in warns:
print(f" warn: {w}")
failed += bool(errs)
print(f"\n{len(files)} article(s), {failed} with errors")
sys.exit(1 if failed else 0)
if __name__ == "__main__":
main()
About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.