saas-documentation

---
name: saas-documentation
description: Plan and write SaaS documentation for managed services, continuous releases, provider/customer responsibility boundaries, UI/browser constraints, runbooks, support enablement, and release readiness. Use when documenting cloud products, hosted services, admin consoles, fleet-wide changes, service operations, incident or runbook procedures, SaaS release notes, customer-controlled settings, or internal docs that support customer experience.
license: MIT
---

# SaaS Documentation

Use this skill to plan, draft, and review documentation for SaaS and managed-service products. It covers public customer docs and internal operational docs that affect the customer experience.

This skill is derived from paraphrased guidance in Christopher Gales and the Splunk Documentation Team's *The Product Is Docs: Writing Technical Documentation in a Product Development Group*, especially Chapter 25, "Writing SaaS Documentation," Chapter 10, "Maintaining Existing Content," Chapter 18, "Working with Customer Support," and Chapter 2, "Agile." Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6

## Quick Start

1. Load `guidelines.md` to choose the smallest useful reference set.
2. Identify whether the docs are public customer docs, internal service docs, release notes, runbooks, or support enablement.
3. Define what the provider manages and what the customer controls.
4. Use `workflows/plan-saas-docs.md` for customer-facing documentation plans.
5. Use `workflows/create-saas-runbook.md` for operational or support procedures.
6. Return customer impact, prerequisites, responsibilities, release timing, owners, and review needs.

## Default Output

When working on SaaS documentation, return:

1. **Audience and surface** - customer, admin, support, operations, field, or internal team.
2. **Responsibility boundary** - provider-managed, customer-controlled, shared, or unsupported.
3. **Customer impact** - action required, risk, timing, permissions, billing, security, or availability.
4. **Doc set recommendation** - public topic, release note, support article, runbook, enablement note, or escalation path.
5. **Operational readiness** - owners, review, incident path, support signals, and update triggers.
6. **Open questions** - unresolved behavior, launch timing, support process, or ownership.

## Contents

| Need | Start Here |
|------|------------|
| Understand SaaS documentation concepts | `references/core/knowledge.md` |
| Plan SaaS customer-facing docs | `workflows/plan-saas-docs.md` |
| Create support or operations runbooks | `workflows/create-saas-runbook.md` |
| Route by task or symptom | `guidelines.md` |

## Core Posture

- Treat documentation as part of the managed service.
- Make provider and customer responsibilities explicit.
- Document fleet-wide change with customer impact and action, not just feature description.
- Treat internal runbooks and support enablement as customer-experience infrastructure.
- Keep SaaS docs current with release, operations, and support signals.