Documentation Platform Selection
Use this skill to choose, compare, pilot, or migrate documentation platforms and authoring tools. It keeps the decision anchored in reader experience, author workflow, maintenance reality, and migration risk.
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 17, "Tools and Content Delivery," plus related maintenance and audience guidance from Chapters 3 and 10. 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.
- State current pain, target reader experience, author workflow, and constraints.
- Use
workflows/evaluate-doc-platform.md to compare options.
- Use
workflows/plan-doc-migration-pilot.md when migration or pilot planning is needed.
- Separate tool problems from process, ownership, and information architecture problems.
- Return requirements, comparison, recommendation, migration risk, pilot plan, and open questions.
Default Output
When evaluating a documentation platform, return:
- Decision context - current pain, audiences, content types, team workflow, and constraints.
- Requirements - reader, authoring, content model, integration, maintenance, migration, portability, support, and cost.
- Option comparison - weighted tradeoffs, fit, risks, and implementation burden.
- Process issues - ownership, IA, review, metadata, or maintenance problems that tooling will not fix alone.
- Recommendation - keep, improve process, pilot, migrate, or reject.
- Pilot or migration plan - scope, success criteria, rollback, owners, and timeline.
Contents
| Need |
Start Here |
| Understand platform selection concepts |
references/core/knowledge.md |
| Evaluate and compare tools |
workflows/evaluate-doc-platform.md |
| Plan migration or pilot |
workflows/plan-doc-migration-pilot.md |
| Route by task or symptom |
guidelines.md |
Core Posture
- Start from reader and author outcomes, not vendor features.
- Diagnose process problems before blaming tooling.
- Treat migration as content, URL, metadata, search, and workflow change.
- Favor portability unless lock-in is an intentional tradeoff.
- Choose the platform the team can actually maintain.
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/documentation-platform-selection/SKILL.md
1---2name: documentation-platform-selection3description: Evaluate documentation platforms and authoring tools by requirements, workflow fit, migration risk, content model, search, integrations, portability, support burden, and cost. Use when choosing docs-as-code, CMS, wiki, DITA, API reference, static-site, help-center, or custom docs tooling, planning a migration, or deciding whether tooling will fix documentation problems.4---5
6
7# Documentation Platform Selection
8
9Use this skill to choose, compare, pilot, or migrate documentation platforms and authoring tools. It keeps the decision anchored in reader experience, author workflow, maintenance reality, and migration risk.
10
11This 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 17, "Tools and Content Delivery," plus related maintenance and audience guidance from Chapters 3 and 10. Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6
12
13## Quick Start
14
151. Load `guidelines.md` to choose the smallest useful reference set.
162. State current pain, target reader experience, author workflow, and constraints.
173. Use `workflows/evaluate-doc-platform.md` to compare options.
184. Use `workflows/plan-doc-migration-pilot.md` when migration or pilot planning is needed.
195. Separate tool problems from process, ownership, and information architecture problems.
206. Return requirements, comparison, recommendation, migration risk, pilot plan, and open questions.
21
22## Default Output
23
24When evaluating a documentation platform, return:
25
261. **Decision context** - current pain, audiences, content types, team workflow, and constraints.
272. **Requirements** - reader, authoring, content model, integration, maintenance, migration, portability, support, and cost.
283. **Option comparison** - weighted tradeoffs, fit, risks, and implementation burden.
294. **Process issues** - ownership, IA, review, metadata, or maintenance problems that tooling will not fix alone.
305. **Recommendation** - keep, improve process, pilot, migrate, or reject.
316. **Pilot or migration plan** - scope, success criteria, rollback, owners, and timeline.
32
33## Contents
34
35| Need | Start Here |
36|------|------------|
37| Understand platform selection concepts | `references/core/knowledge.md` |
38| Evaluate and compare tools | `workflows/evaluate-doc-platform.md` |
39| Plan migration or pilot | `workflows/plan-doc-migration-pilot.md` |
40| Route by task or symptom | `guidelines.md` |
41
42## Core Posture
43
44- Start from reader and author outcomes, not vendor features.
45- Diagnose process problems before blaming tooling.
46- Treat migration as content, URL, metadata, search, and workflow change.
47- Favor portability unless lock-in is an intentional tradeoff.
48- Choose the platform the team can actually maintain.
49
50---
51
52**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/LVTD-LLC/skills/skills/documentation-platform-selection/SKILL.md`
hashgraph-online