Start here
| Doc | When to read |
|---|---|
| Quickstart | First 10 minutes — sign up, connect a cloud, deploy a Postgres. |
| Concepts — Agents | Understand what specialist agents are and how they work. |
| Concepts — Gates | Understand the deployment flow (Gate 1 → Gate 6). |
| Concepts — Self-healing | What happens after apply: health verification, the bounded auto-repair ladder, the template flywheel. |
How-to guides (task-oriented)
| Doc | Goal |
|---|---|
| Connect AWS | Connect a customer AWS account via cross-account IAM role |
| Connect GCP | Connect a customer GCP project via Workload Identity Federation |
| Connect Azure | Connect a customer Azure subscription via service principal |
| Invite teammates | Add members to your org, set roles, transfer ownership |
| Approvals workflow | Require admin approval before risky deployments run |
| Notifications | In-app + email notification settings |
| Billing & plans | Plan limits, upgrade flow, usage tracking |
Reference (information-oriented)
| Doc | What’s in it |
|---|---|
| Agents — full list | All ~140 specialist agents and what each one provisions |
| API reference | REST endpoints for programmatic use |
| Environment variables | Backend & frontend config knobs |
Explanation (understanding-oriented)
| Doc | What you’ll understand |
|---|---|
| Multi-cloud — why we built it | Why we support AWS + GCP + Azure equally |
| Security model — WIF isolation | How per-org isolation works at the cloud-trust boundary |
| Architecture overview | Backend / frontend / agent / specialist memory flow |
Troubleshooting
| Doc | Symptom |
|---|---|
| Cloud connect — 403 errors | Probe fails after Connect — common causes |
| GCP deployments | Cloud Run /healthz 404s, quota walls, 409 residue, empty log panels — from our published campaign dossiers |
| AWS deployments | ALB 5xx during boot, AZ capacity, JVM OOM, EKS metrics, EIP/VPC quotas — from our published campaign dossiers |
| Deployment stuck at Gate N | A deployment session won’t advance |
| Common errors | Searchable list of error messages and fixes |
Conventions used in these docs
- Code blocks with language tags get syntax highlighting in the
rendered docs (
bash,yaml,python,tsx, etc.) - Inline
codefor env var names, file paths, function names > Note:callouts for important info> Watch out:callouts for common mistakes- Headings use Title Case; the doc title is
# Page Title(single H1) - Every page declares its Diátaxis type in the header (Tutorial / How-to / Reference / Explanation)
- Examples use real values from the platform (real region IDs, real
agent names) — not
<placeholder>syntax unless absolutely necessary
What’s intentionally NOT here
- Internal architecture documentation — that lives in
docs/superpowers/specs/anddocs/superpowers/plans/in the monorepo. Customer-facing docs should never expose internal feature-flag names or implementation details. - Marketing pages — the docs site is for users who already signed up. Pre-signup content lives on the landing page.
- Sales / pricing details — those change too often; link to the pricing page rather than mirroring.
Maintenance
- When a feature ships, add or update the relevant doc in this folder in the same PR. Code without docs is half-done.
- When a customer hits a confusing error and contacts support, add it
to
troubleshooting/common-errors.mdso the next customer self-serves. - When a competitor’s customer asks “do you do X?”, add an explanation doc covering it — half the time that becomes the deciding factor on the trial.
Was this page helpful?