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
- Load
guidelines.md to choose the smallest useful reference set.
- Identify whether the docs are public customer docs, internal service docs, release notes, runbooks, or support enablement.
- Define what the provider manages and what the customer controls.
- Use
workflows/plan-saas-docs.md for customer-facing documentation plans.
- Use
workflows/create-saas-runbook.md for operational or support procedures.
- Return customer impact, prerequisites, responsibilities, release timing, owners, and review needs.
Default Output
When working on SaaS documentation, return:
- Audience and surface - customer, admin, support, operations, field, or internal team.
- Responsibility boundary - provider-managed, customer-controlled, shared, or unsupported.
- Customer impact - action required, risk, timing, permissions, billing, security, or availability.
- Doc set recommendation - public topic, release note, support article, runbook, enablement note, or escalation path.
- Operational readiness - owners, review, incident path, support signals, and update triggers.
- 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.
1---2name: saas-documentation3description: 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.4license: MIT5---67# SaaS Documentation89Use 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.1011This 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-61213## Quick Start14151. Load `guidelines.md` to choose the smallest useful reference set.162. Identify whether the docs are public customer docs, internal service docs, release notes, runbooks, or support enablement.173. Define what the provider manages and what the customer controls.184. Use `workflows/plan-saas-docs.md` for customer-facing documentation plans.195. Use `workflows/create-saas-runbook.md` for operational or support procedures.206. Return customer impact, prerequisites, responsibilities, release timing, owners, and review needs.2122## Default Output2324When working on SaaS documentation, return:25261. **Audience and surface** - customer, admin, support, operations, field, or internal team.272. **Responsibility boundary** - provider-managed, customer-controlled, shared, or unsupported.283. **Customer impact** - action required, risk, timing, permissions, billing, security, or availability.294. **Doc set recommendation** - public topic, release note, support article, runbook, enablement note, or escalation path.305. **Operational readiness** - owners, review, incident path, support signals, and update triggers.316. **Open questions** - unresolved behavior, launch timing, support process, or ownership.3233## Contents3435| Need | Start Here |36|------|------------|37| Understand SaaS documentation concepts | `references/core/knowledge.md` |38| Plan SaaS customer-facing docs | `workflows/plan-saas-docs.md` |39| Create support or operations runbooks | `workflows/create-saas-runbook.md` |40| Route by task or symptom | `guidelines.md` |4142## Core Posture4344- Treat documentation as part of the managed service.45- Make provider and customer responsibilities explicit.46- Document fleet-wide change with customer impact and action, not just feature description.47- Treat internal runbooks and support enablement as customer-experience infrastructure.48- Keep SaaS docs current with release, operations, and support signals.
LVTD-LLC