Use this skill when designing help center architecture, writing support articles, or optimizing search and self-service. Triggers on knowledge base, help center, support articles, self-service, article templates, search optimization, content taxonomy, and any task requiring help documentation design or management.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use this skill when designing help center architecture, writing support articles, or optimizing search and self-service. Triggers on knowledge base, help center, support articles, self-service, article templates, search optimization, content taxonomy, and any task requiring help documentation design or management.
Write for scanning, not reading - Users arrive with a specific problem and scan
for the answer. Use short paragraphs, numbered steps, bold key terms, and clear
headings. A wall of prose is an article no one reads. Every section should be
findable with a 2-second scan.
Structure mirrors the user's mental model - Organize content around tasks users
are trying to complete and problems they experience, not around your product's
internal feature structure. "How do I invite a teammate?" beats "User Management >
Invitations > Creating Invitations." Users think in outcomes, not menus.
Search is the primary navigation - Most users will never browse your category
tree. They will type a query and click the first plausible result. Every article
title, summary, and keyword set must be optimized for the words users actually type,
not the words your product team uses internally.
Measure deflection, not pageviews - Pageviews tell you what people look at.
Deflection tells you whether it worked. Track ticket volume versus help center
traffic, article ratings, failed searches, and contact-us clicks post-article-view.
A high-traffic article with a high contact-us rate is a failing article.
Maintain ruthlessly - An outdated article is worse than no article. It creates
false confidence and support tickets filled with "I followed the article and it
didn't work." Every article needs an owner, a review date, and a clear process for
marking it outdated or archiving it when the feature changes.
Core concepts
Information architecture
Information architecture (IA) is how content is organized, labeled, and linked. A good
IA means users can find answers in two clicks or fewer from the help center home page.
Taxonomy design principles:
Top-level categories map to user goals, not product features
5-8 top-level categories is the practical maximum before navigation becomes overwhelming
Each article belongs to exactly one primary category (cross-links are fine; dual-homing creates maintenance debt)
Sub-categories add one level of specificity - avoid nesting beyond two levels
Taxonomy validation test: Show the category structure to five users who have never
seen it. Ask them where they would look for a specific common task. If fewer than four
out of five find the right category, redesign the labels.
Article types
Type
Purpose
Primary user intent
How-to
Step-by-step instructions for a task
"I want to do X"
Troubleshooting
Diagnose and fix a specific error or symptom
"X is broken or not working"
FAQ
Short answers to common questions
"I have a quick question about X"
Reference
Complete spec, options table, or glossary
"I need to know all the values/settings for X"
Concept
Explains a feature or workflow at a high level
"I want to understand how X works before I use it"
Most articles should be how-to or troubleshooting. If your knowledge base is mostly
concept articles, users are not finding actionable answers - they are being educated
when they want to be unblocked.
Search optimization
Search in a knowledge base is keyword-matching plus ranking, not semantic understanding
(even with AI-powered search, explicit optimization still wins).
The three-layer keyword strategy:
Layer 1 - Title keywords: Words users type when they know what they want
("reset password", "cancel subscription", "export CSV")
Layer 2 - Synonyms: Alternate terms for the same concept
("reset" = "forgot", "change", "recover")
("cancel" = "delete account", "close account", "unsubscribe")
Layer 3 - Error strings: Exact error messages users copy-paste into search
("Error 403: Forbidden", "SMTP authentication failed")
Store synonyms in your search tool's synonym dictionary so both terms resolve to the
same results. Never make users guess the "right" terminology.
Deflection metrics
Deflection is the percentage of users who find an answer in the knowledge base and
do not open a support ticket. It is the primary health metric for a knowledge base.
Deflection rate formula:
Deflection rate = 1 - (tickets opened after KB visit / total KB visits)
Supporting metrics to track:
Metric
What it measures
Healthy target
Deflection rate
Overall KB effectiveness
> 70%
Article rating (thumbs)
Per-article satisfaction
> 80% positive
Failed search rate
Queries returning zero results
< 10%
Contact-us click rate post-article
Articles that fail to resolve
< 5% per article
Article staleness (days since reviewed)
Content freshness
< 180 days
Search-to-click rate
How often search results get clicked
> 60%
Common tasks
Design help center architecture - taxonomy
Step 1: Mine your ticket data
Pull 90 days of support tickets and tag each with the user's underlying goal (not
the feature involved). The top 10 goals by volume become your category candidates.
Step 2: Card-sort validation
Give 8-10 representative users 20-30 article titles on cards. Ask them to group
articles into categories and name each group. Patterns appearing in 6+ of 8 users'
groupings are validated categories.
Step 3: Build the hierarchy
Level 0: Help Center home
Level 1: 5-8 goal-based categories (e.g., "Getting Started", "Billing", "Account Settings")
Level 2: Sub-categories per Level 1 (e.g., "Billing > Invoices", "Billing > Payment Methods")
Level 3: Individual articles
Step 4: Map existing content
Audit every existing article against the new taxonomy. For each article: keep, merge,
rewrite, or archive. Do not migrate stale articles - migration is a forcing function
to decide whether content is worth keeping.
Write effective support articles - template
See references/article-templates.md for full templates by article type.
Universal writing rules:
Title format: verb + object + optional context. "Reset your password" not "Password Reset"
First sentence: state exactly what the article covers and who it is for
Steps use numbered lists; sub-steps use indented numbered lists
Add screenshots and videos for steps where UI placement is ambiguous
Bold the first mention of a UI element: "Click Save changes"
End every article with a "Was this helpful?" rating and a link to contact support
Length targets:
Article type
Target word count
How-to
150-400 words
Troubleshooting
200-600 words
FAQ
50-150 words per answer
Reference
As long as needed; use anchor links for navigation
Optimize search - keywords and synonyms
Keyword audit workflow:
Export failed searches from the last 30 days (queries with zero results or zero clicks)
Cluster similar failed searches into synonym groups
For each cluster: does a relevant article exist? If yes, add synonyms. If no, add to content backlog.
Export low-click-rate searches (results shown but not clicked) - these indicate title mismatch
Rewrite article titles to match the language users use in low-click queries
See references/article-templates.md for ready-to-use templates for:
How-to articles
Troubleshooting articles
FAQ articles
Reference articles
Build a maintenance workflow
Content ownership model:
Every article must have a named owner (a person, not a team). The owner is responsible
for reviewing the article when the related feature changes and on a scheduled cadence.
Review cadence:
Article type
Review frequency
How-to (frequently changing features)
Every 60 days
How-to (stable features)
Every 180 days
Troubleshooting
Every 90 days
Reference (spec/settings tables)
Every 60 days
FAQ
Every 90 days
Maintenance workflow:
Trigger: Feature release, product change, or scheduled review date
Step 1: Owner verifies each step against the current product
Step 2: Update screenshots, step copy, and option names
Step 3: Bump "Last reviewed" date in article metadata
Step 4: If article covers removed functionality: archive, don't delete
(external links break; archived articles should redirect to a notice)
Step 5: Notify support team of significant changes for in-flight tickets
Staleness detection automation: Set up a script or integration that flags any
article whose "Last reviewed" date exceeds the review threshold. Pipe these to a
weekly "content health" report sent to article owners.
Implement in-product help - contextual guidance
Contextual help surfaces the right article at the moment of need, inside the product,
without requiring the user to navigate away.
Contextual help patterns:
Pattern
When to use
Implementation
Tooltip
Explain a single field or option
? icon next to field; 1-2 sentences max
Inline help text
Persistent hint below an input
Static text; use for non-obvious requirements
Help panel
Step-by-step guidance for a complex form or workflow
Slide-out panel linking to full KB article
Empty state link
Guide users on first use
"How to add your first X" in empty states
Error message link
Link to troubleshooting from inline errors
"Error 403. [Learn why this happens]"
Rules for contextual help copy:
Write in second person: "You can add up to 5 team members on this plan"
State what the user can do, not what the system does
Link to the full KB article for anything that needs more than 2 sentences
Never duplicate the full article in a tooltip - summarize and link
Anti-patterns
Anti-pattern
Why it fails
What to do instead
Organizing by feature/menu path
Users don't know your product structure - they know their problem
Organize by user goal; use feature names only in article body
Writing prose paragraphs for how-to steps
Users skip prose and miss steps; causes more tickets
Use numbered lists with one action per step
Copy-pasting UI labels verbatim into titles
UI labels are designed for space, not searchability
Write titles around the task users are trying to accomplish
No synonym dictionary
Users who use different words than your team get zero results
Build and maintain a synonym dictionary; review monthly
Measuring success by pageviews
High views on a bad article looks like success
Measure deflection rate and article rating; pageviews are vanity
Never archiving old articles
Users follow stale instructions and open tickets blaming the product
Archive any article for a removed or significantly changed feature within one sprint
Gotchas
Failed search data is the most valuable signal and most teams ignore it - Most help center analytics dashboards surface pageviews and article ratings. The highest-signal data is failed searches (queries that return zero results or zero clicks). These are users who came looking for help and left empty-handed. Pull this report weekly and treat it as a content gap backlog.
Organizing by product feature structure instead of user mental model causes high bounce rates - When users see categories like "Workspace Settings > Members > Invitation Flow" they have to translate their problem ("how do I add someone") into your product's internal taxonomy. Users who can't find the category in 3 seconds leave and open a ticket. Always validate category names with real users before launching.
Article titles written for SEO but not for scanning produce low click rates in search - A title like "Complete Guide to Password Management in Your Account Settings" is verbose and buries the action. Users scanning search results for "reset password" need to see those words in the title. Keep titles short, verb-first, and match the exact language users type when searching.
High article ratings on outdated content create a false health signal - Users who found a workaround or figured it out on their own often rate the article positively despite it being partially wrong. Article staleness tracking (days since last review) must run in parallel with ratings - a 4-star article that hasn't been reviewed in 18 months for a changing feature is still a liability.
Deflection rate drops are invisible without session-level tracking - If you measure deflection as "tickets opened / total KB pageviews" instead of at the session level, you can't tell whether users who opened tickets also visited the KB first. Session-level tracking (user visited KB then opened a ticket within the same session) is the only accurate failure signal.
References
For detailed templates and patterns, load the relevant file from references/:
references/article-templates.md - ready-to-use templates for how-to, troubleshooting, FAQ, and reference articles with annotated examples
Only load a references file when the current task requires it.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install: