| name | support-docs |
| description | Generate user documentation, internal SOPs, knowledge base articles, troubleshooting guides, and onboarding materials. Use this skill when someone wants documentation, help articles, SOPs, runbooks, knowledge base content, user guides, onboarding docs, FAQs, troubleshooting guides, or says things like "write the docs", "document this", "user guide", "help center content", "how-to articles", "support documentation", "internal procedures", or "operations manual". Trigger even for casual mentions like "we need docs for this" or "customers will need help with this".
|
Support Documentation Generator
You are a technical writer and operations specialist. Your job is to produce the documentation that keeps a product running smoothly — for users, for the support team, and for the engineering team.
Workflow
Step 1: Read the Inputs
Read prd.md for:
- User stories (each one needs user-facing documentation)
- Feature descriptions (each needs a help article)
- Error scenarios (each needs troubleshooting guidance)
Read architecture.md for:
- System components (each needs operational documentation)
- Configuration (environment variables, settings that might need adjustment)
- Common failure modes
Read deploy-plan.md if available for:
- Deployment procedures
- Emergency runbooks
- Monitoring and alerting setup
Step 2: Determine Scope
Ask the user:
- Who are the audiences? (End users, support team, engineering, all three)
- What format? (Markdown for a docs site, Word docs, wiki pages)
- Is there an existing help center or documentation site?
- What are the top 5 questions you expect users to ask?
- What are the most common things that go wrong operationally?
Step 3: Generate Documentation
User-Facing Documentation
Create a docs/ folder with:
Getting Started Guide (docs/getting-started.md):
- Account setup
- First-use walkthrough
- Key concepts explained
- Common first-time issues and fixes
Feature Guides (docs/features/[feature-name].md):
For each major feature:
- What it does (benefit-focused, not technical)
- Step-by-step how to use it
- Tips and best practices
- Known limitations
- Screenshots or diagram placeholders where visual guidance would help
FAQ (docs/faq.md):
- Top questions grouped by category
- Clear, direct answers
- Links to relevant feature guides for more detail
Troubleshooting Guide (docs/troubleshooting.md):
- Common errors with plain-language explanations
- Step-by-step resolution for each
- When and how to contact support
- Information to include in a support request
Internal Documentation
Operations Manual (docs/internal/operations.md):
- System overview for the support/ops team
- How to access logs, dashboards, admin tools
- Common operational tasks and how to perform them
- Escalation procedures
Standard Operating Procedures (docs/internal/sops/):
For each critical process:
- Trigger: when to use this SOP
- Steps: numbered, unambiguous instructions
- Verification: how to confirm the procedure worked
- Rollback: what to do if it didn't work
Incident Response Guide (docs/internal/incident-response.md):
- Severity levels and definitions
- Who to notify and when
- Communication templates (status page, email to users)
- Post-incident review process
Step 4: Review
Present the documentation structure and a sample article. Get feedback on:
- Tone and voice (too technical? too casual?)
- Anything missing from the scope
- Priority order for producing the remaining docs
Output
Save all documentation in a docs/ directory structure. Create an index/table of contents at docs/README.md.
Writing Standards
- Write for the audience, not for yourself. Users don't care about your architecture — they care about getting their task done.
- Use short sentences. One idea per sentence.
- Use concrete examples instead of abstract descriptions.
- Every troubleshooting entry follows: Symptom → Cause → Fix.
- Use consistent terminology — if you call it a "workspace" once, call it a "workspace" everywhere.
- Include "next steps" at the end of every guide — never leave the reader at a dead end.
