Skip to content

SkyCMS Documentation Adoption Priority Plan

Summary

Adoption-first documentation execution plan prioritizing installation/configuration and first-website-build success.

Adoption principle

If users cannot install and configure SkyCMS quickly, they never reach product value.

If users cannot build a working site quickly after setup, they do not continue usage.

Priority order:

  1. Installation and configuration journey.
  2. Website-building journey.
  3. Operational maturity and optimization.

Success metrics

Track these metrics in priority order:

  1. First-try install success rate.
  2. Median time to successful setup completion.
  3. Median time from setup complete to first published page.
  4. Drop-off rate between setup completion and first publish.

Adoption journey map

Journey A: Install and configure (highest priority)

Primary outcome:

  • user reaches a healthy, configured SkyCMS instance.

Primary pages:

Journey B: Build and publish a website (second priority)

Primary outcome:

  • user creates a page, publishes it, and verifies output.

Primary pages:

Journey C: Operate and scale (third priority)

Primary outcome:

  • user can release safely and troubleshoot production issues.

Primary pages:

Re-ranked execution queue

Wave 0: Already improved in this cycle

Wave 1: Immediate adoption blockers

  1. getting-started/what-is-skycms.md
  2. deployment/docker.md
  3. installation/overview.md (adoption-focused rewrite and clearer decision paths)
  4. configuration/overview.md (decision-first guidance and setup checkpoints)

Wave 2: Time-to-first-website acceleration

  1. for-site-builders/overview.md (intent-first start paths)
  2. for-site-builders/layouts.md (first-usable layout path)
  3. for-site-builders/templates.md (first-template publish path)
  4. for-editors/visual-editor-quickstart.md (publish-first flow)
  5. for-editors/page-builder-quickstart.md (publish-first flow)
  6. for-editors/publishing-modes.md (simple mode decision tree)

Wave 3: Confidence and operational trust

  1. deployment/cicd-pipelines.md
  2. deployment/publishing-workflow.md
  3. reference/troubleshooting.md
  4. reference/faq.md

Deferred backlog (track, do later)

  1. Finish docs CI hardening by enforcing Docs Quality Gates as required status checks.
  2. Sweep documentation for plain-text reading paths or recommended doc lists and convert them to direct linkable list items where appropriate.
  3. Finish all remaining documentation standardization and structural cleanup work that is well-suited to GPT-led repo editing.
  4. Run a dedicated editorial voice and readability pass after structural and standards work is complete.
  5. Run a broad cross-doc review with Gemini after the editorial pass to identify remaining consistency, readability, and coverage gaps.

Page-level standards for adoption-critical docs

Every adoption-critical page must have:

  1. one clear outcome statement at top,
  2. prerequisites that are complete and testable,
  3. numbered procedural steps,
  4. explicit verification criteria,
  5. related links to the next step in the user journey.

Review cadence for adoption-critical pages

  • Review every 30 days while adoption is the primary strategic goal.
  • Update last_reviewed on every material revision.
  • Treat broken install/build paths as top-priority documentation incidents.

Operating decision

Until adoption goals are met, use this plan as the default sort order for documentation backlog and rewrite work.