Global saas doc writer

Global SaaS Doc Writer

Use this skill to produce practical documentation that helps a specific reader complete a task, understand a change, or recover from a problem. Prefer executable guidance over broad style commentary.

Trigger Conditions

Use this skill when the user asks to:

• Draft, rewrite, or review product documentation.
• Create a Help Center article, user guide, troubleshooting guide, FAQ, changelog, release note, onboarding doc, developer doc, or UI-related doc.
• Improve documentation for global readability, terminology consistency, procedural clarity, UI labels, error recovery, or AI/cloud/developer product language.
• Update docs in a docs-as-code workflow after a product, API, UI, release, or support-learning change.
• Run a quality gate against documentation content.

Required Inputs

Before drafting, identify or request:

• Document type and target audience.
• User goal or reader question.
• Product facts, feature behavior, limits, prerequisites, permissions, and availability.
• Known UI labels, navigation paths, commands, API fields, error messages, or metrics.
• Known friction, edge cases, risks, and troubleshooting needs.
• Source of truth for product behavior, such as UI, API contract, release plan, issue, support trend, or approved product note.
• Review needs for product, engineering, support, legal, security, or localization-sensitive content.
• Output destination or format, if the user wants a file update.

If key facts are missing, proceed with clearly marked placeholders only when safe. Do not invent behavior, error causes, UI labels, metrics, permissions, pricing, regions, legal terms, security claims, or compliance claims.

Workflow

1. Classify the task: draft, revise, review, or quality-gate check.
2. Choose the document type and the smallest useful format for the reader's goal: task, concept, reference, FAQ, troubleshooting, changelog, release note, or a focused combination.
3. Put the user goal, answer, required setup, or first action near the top.
4. Add prerequisites before steps.
5. Write ordered tasks as numbered steps with one primary action per step.
6. Mark optional or conditional steps explicitly.
7. Include expected results after important actions.
8. Add restrictions, warnings, troubleshooting, or escalation guidance when failure or risk is likely.
9. For repository updates, inspect nearby public docs, avoid duplicated guidance, update directly affected related docs, and keep the diff focused.
10. Apply terminology, UI label, global-readability, editorial-consistency, command/reference, maintainability, and source-safety rules.
11. Review against the quality gate before returning or saving the result.

For deeper guidance, load only the relevant public files:

• references/distilled-principles.md
• references/terminology-rules.md
• references/style-conflict-resolution.md
• assets/documentation-quality-gate.md
• examples/before-after-examples.md

Output Format

For new documentation, return or save a complete Markdown document with:

• A task- or answer-led title.
• A short opening that states the user goal.
• Prerequisites or required setup, when relevant.
• Steps, tables, or concise sections based on the document type.
• Expected result, verification step, troubleshooting, next steps, or related tasks when useful.

For reviews, return:

1. Pass/fail result.
2. Problems found, ordered by impact.
3. Revised version or targeted edits when needed.
4. Rules applied.

For changelogs and release notes, state what changed, who is affected, why it matters, and whether action is required.

Quality Gate Summary

Before finalizing, check that:

• No private source content, proprietary examples, or unsupported source-specific rules appear.
• The document does not invent product behavior, error causes, metrics, or guarantees.
• UI labels, paths, commands, API fields, and error messages are exact or clearly marked as placeholders.
• Required role, plan, region, version, setup, quota, or permission appears when relevant.
• Related docs, changelogs, release notes, or troubleshooting pages are updated when the product change affects them.
• Repeated setup, warning, or reference content links to a canonical source instead of being duplicated.
• Steps are ordered, action-led, and testable.
• Headings, lists, tables, numbers, units, abbreviations, punctuation, and cross-references are consistent.
• Optional and conditional steps, restrictions, and risk notices appear before the relevant action.
• The content uses plain global English, consistent terms, and sentence-style headings.
• Troubleshooting separates symptom, likely cause, fix, and escalation details.
• AI-generated outputs, classifications, suggestions, or automations include review expectations when accuracy matters.

Terminology and UI Rules

• Use one term for one concept.
• Define unfamiliar acronyms on first use. Do not introduce one-time acronyms unless search needs require it.
• Preserve required capitalization for product names, UI labels, API fields, code, commands, flags, and environment variables.
• Use sentence-style capitalization for headings and labels unless the product, brand, API, or language requires otherwise.
• Use input-neutral UI verbs by default: go to, select, open, enter, clear, choose, turn on, and turn off.
• Avoid click, tap, right-click, and visual-only directions unless the input method or visual position is essential.
• Write UI paths with exact labels and spaces around separators, such as Settings > Billing > Invoices.
• Mark unknown UI labels as placeholders, such as [Import CSV], instead of inventing labels or paths.
• Do not add UI element types like "button" or "checkbox" unless the label alone is ambiguous.
• In developer docs, identify code-like names by type when needed, such as command, option, parameter, method, class, field, or environment variable.
• For command examples, explain variables, parameters, and options immediately after the syntax.
• Use descriptive link text. Do not use "click here."
• Keep punctuation away from copyable values when users might mistake it for part of the command, placeholder, UI label, API field, or literal value.
• Use one style for percentages, units, ranges, dates, and abbreviations within a document unless product truth requires an exception.

Boundaries

• Do not read, copy, quote, summarize, transform, or expose private source files unless the user explicitly asks for a controlled distillation task and the repository policy allows it.
• Do not copy source wording into public skill files. Convert only portable ideas into original rules, patterns, quality gates, and fictional examples.
• Do not include proprietary examples unless the user provides approved public content.
• Do not claim security, privacy, compliance, uptime, availability, accuracy, or performance unless approved facts support the claim.
• Do not imply AI systems have intent, feelings, judgment, or guaranteed correctness.
• Do not make generated output, copied website pages, or exported PDFs the maintained source unless the repository explicitly requires it.
• Do not hide unresolved product facts in polished prose. Mark them as placeholders or list them as open questions.
• If a rule depends on a specific company's brand voice, product names, word list, font, UI system, or legal requirement, mark it as source-specific and do not generalize it.