{"id":"70be6e85-da1a-4d45-a407-a8a5a0d3a500","shortId":"KHP5rw","kind":"skill","title":"documentation-strategy","tagline":"Design and run a documentation system for a team or product. Use this skill when planning what to document, choosing a documentation tool, organizing existing docs, fixing stale documentation, designing a maintenance cadence, or scoping technical writing work. Triggers on documen","description":"# Documentation Strategy\n\nDecide what gets documented, where, by whom, and how it stays fresh. Stack-agnostic. Applies to internal team docs, product docs, runbooks, READMEs, and knowledge bases.\n\n---\n\n## When to use\n\n- Setting up documentation for a new team or product\n- Auditing existing documentation\n- Fixing stale or scattered docs\n- Choosing a documentation tool or platform\n- Defining what gets documented and what doesn't\n- Establishing maintenance cadence\n- Scoping technical writing work\n- Designing onboarding documentation (use alongside `team-onboarding-playbook`)\n\n## When NOT to use\n\n- Writing the actual content of a single document (use `content-and-copy`)\n- Customer-facing knowledge base copy (use `content-strategy`)\n- Code comments and inline documentation (covered by `code-review-web`)\n- One-off blog posts or articles (use `content-and-copy`)\n\n---\n\n## Required inputs\n\n- The audience (internal, external, customer, dev, exec)\n- Existing docs and their state (where, what shape, last updated)\n- Team size and growth trajectory\n- The kinds of work that produce documentation (engineering, product, ops, support)\n- Tools currently in use\n\n---\n\n## The framework: 4 categories of documentation\n\nDifferent categories of doc serve different purposes. Conflating them is how docs get bad.\n\n### Category 1: Reference\n\nWhat things are. Looked up when needed.\n\nExamples: API reference, configuration options, glossary, architecture diagrams, contact lists, decision log entries.\n\nProperties:\n- Comprehensive\n- Fact-checked, kept accurate\n- Searchable\n- Stable structure (links don't break)\n- Version-aware where relevant\n\n### Category 2: How-to\n\nHow to do specific tasks. Procedural.\n\nExamples: \"Deploy to staging,\" \"Reset a password,\" \"Onboard a new contractor,\" \"Run the backup restore drill.\"\n\nProperties:\n- Step-by-step\n- Tested by someone who didn't write it\n- Includes the prerequisites\n- Includes troubleshooting\n- Versioned to the system it documents\n\n### Category 3: Explanation\n\nWhy things are the way they are. Conceptual.\n\nExamples: architecture rationale, design decision records (ADRs), strategy docs, vision documents.\n\nProperties:\n- Narrative\n- Captures context (the why)\n- Often historical (why we built it this way)\n- Links to evidence\n\n### Category 4: Tutorial\n\nLearning-oriented. Walks someone from zero to capable.\n\nExamples: \"Getting started with our codebase,\" \"Your first deploy,\" onboarding pathways.\n\nProperties:\n- Sequenced from simple to complex\n- Hands-on\n- Doesn't assume prior knowledge in scope\n- Has clear completion criteria\n\n(This four-way split is the Diátaxis framework, well-known in tech writing. Memorize it.)\n\n---\n\n## The framework: 5 tiers of doc\n\nDifferent docs serve different audiences with different stakes.\n\n### Tier 1: Customer-facing\n\nPublic docs, customer KBs, API references. High visibility, slow change.\n\nStandards:\n- Editorial review\n- Version control\n- Clear ownership\n- High freshness bar\n- Tied to release\n\n### Tier 2: Cross-team / shared\n\nDocs used across teams: shared APIs, common services, company-wide processes.\n\nStandards:\n- Cross-team ownership clear\n- Update obligations on changes\n- Mid-to-high freshness bar\n\n### Tier 3: Team-internal\n\nDocs for the team that owns them: how the team works, runbooks, decisions.\n\nStandards:\n- Team-owned, team-maintained\n- Mid freshness bar\n- Useful for the next person joining\n\n### Tier 4: Personal scratchpad\n\nNotes, drafts, work-in-progress. Not for others.\n\nStandards:\n- Low maintenance\n- Don't link from official docs\n- Promote to higher tier when valuable\n\n### Tier 5: Auto-generated\n\nDocs derived from code: API references generated from comments, schemas, etc.\n\nStandards:\n- Generation is automated, runs in CI\n- Single source of truth (the code)\n- Reviewed for usability, not freshness (that's automatic)\n\nThe tiering matters because the maintenance bar differs. Asking team-internal docs to meet customer-facing standards is wasteful and unsustainable.\n\n---\n\n## Workflow\n\n### Step 1: Audit current state\n\n- What docs exist?\n- Where do they live? (often: scattered)\n- Who owns each?\n- How fresh are they?\n- Are they actually used? (check page views or referrals if measurable)\n\nThe audit is often eye-opening. Most teams have more docs than they realize, in more places than they realize.\n\n### Step 2: Categorize and tier\n\nFor each doc:\n- Category (reference / how-to / explanation / tutorial)\n- Tier (customer / shared / team / scratchpad / generated)\n\nSome docs are mixed. Note the dominant category.\n\n### Step 3: Identify gaps\n\nWhat documentation does the team need that doesn't exist?\n\nCommon gaps:\n- \"How does X actually work?\" no answer\n- Onboarding for the role no one's onboarded recently\n- Runbook for a system that's never broken (yet)\n- Decision rationale for \"why are we doing it this way\"\n\nAsk people what they wish were documented. They know.\n\n### Step 4: Identify dead weight\n\nDocs that are:\n- Out of date and not getting updated\n- Duplicated across places (one is canonical, others should redirect or be deleted)\n- About things that no longer exist\n- Drafts abandoned long ago\n\nDelete or archive. Stale docs are worse than missing docs (people might trust them).\n\n### Step 5: Pick the home(s)\n\nWhere docs live affects whether they're maintained.\n\nCommon locations:\n- **Code repo (markdown):** for docs tightly coupled to code (READMEs, ADRs, runbooks for the service)\n- **Wiki / Notion / Confluence:** for cross-team and team-internal\n- **Docs site (Docusaurus, Mintlify, custom):** for customer-facing\n- **Tickets / decision logs:** for ephemeral records\n\nDon't aim for one home. Aim for a clear answer to \"where does this kind of doc live?\"\n\n### Step 6: Establish ownership\n\nEvery doc has an owner. Without an owner, it goes stale.\n\nOwner can be:\n- A team\n- A role (the on-call rotation, the PM, the EM)\n- A person, with a backup\n\nIf an owner isn't obvious, the doc may not deserve to exist.\n\n### Step 7: Establish maintenance cadence\n\nPer tier:\n\n| Tier | Review cadence |\n|---|---|\n| Customer-facing | Per release, plus quarterly |\n| Cross-team | Quarterly |\n| Team-internal | Quarterly |\n| Personal scratchpad | None |\n| Auto-generated | On every change |\n\nMaintenance includes:\n- Verify accuracy\n- Update for changed systems\n- Archive what's no longer relevant\n- Address user feedback\n\n### Step 8: Make doc updates part of work\n\nDocumentation isn't a separate project. It's part of the work that produces it.\n\n- New feature: docs are part of the feature\n- New process: doc is part of the rollout\n- Decision made: ADR or decision-log entry filed\n- Bug postmortem: runbook updated\n- New hire: onboarding doc updated based on their experience\n\nThe team that ships features without docs has less than they think they have.\n\n### Step 9: Make docs discoverable\n\nEven great docs are useless if no one finds them.\n\n- Search that actually works (most platforms; some better than others)\n- Index pages for major topics\n- Cross-links between related docs\n- Search aliases for common alternative phrasings\n- Pinning the most-used docs\n\n### Step 10: Measure\n\nWhat's measurable depends on the platform:\n- Page views\n- Search queries (and zero-result queries)\n- \"Was this helpful?\" feedback\n- Time on page\n- Referral patterns\n\nFor internal docs, the qualitative measure is often more useful: are the same questions getting asked over and over? If yes, the docs aren't doing their job (either they don't exist, aren't found, or aren't clear).\n\n---\n\n## Specific patterns\n\n### README per project\n\nEvery code repo has a README that answers:\n- What is this?\n- How do I run it?\n- How do I contribute?\n- Where do I find more info?\n\nFive sentences each, often. Length isn't the goal. The READ-it-ME promise is.\n\n### ADR (Architecture Decision Record)\n\nPer significant decision:\n\n```\n# ADR-NNN: [Title]\n\nStatus: [Proposed / Accepted / Deprecated / Superseded]\nDate: [Date]\n\n## Context\n[What's the situation? What forces are at play?]\n\n## Decision\n[What was decided?]\n\n## Consequences\n[What happens because of this decision? Both good and bad.]\n```\n\nADRs accumulate. They become the explanation layer for \"why are we doing it this way.\"\n\n### Runbook\n\nPer system:\n- What it is\n- How to access it\n- Common operations (with commands)\n- Common failure modes\n- Restore from backup procedure\n- Escalation contacts\n\nSee `incident-response` and `backup-and-disaster-recovery` for runbook standards.\n\n### Onboarding pathway\n\nPer role:\n- Day 1\n- Week 1\n- Month 1\n- 90 days\n\nSee `team-onboarding-playbook`.\n\n### Decision log\n\nLightweight version of ADRs. Date, decision, decider, why. Keeps a record without ceremony.\n\n### Glossary\n\nTerms that have specific meaning in the team or product. Reduces confusion. Trains AI tools too (more on that later).\n\n---\n\n## Tooling\n\nThe tool is less important than the discipline. That said:\n\n| Tool category | Examples | Best for |\n|---|---|---|\n| Wiki | Notion, Confluence, GitBook | Cross-team, internal |\n| Markdown in code | GitHub, GitLab, Bitbucket | READMEs, ADRs, technical |\n| Docs sites | Docusaurus, Mintlify, ReadMe | Customer-facing, public docs |\n| Internal sites | MkDocs, custom | Team-specific patterns |\n\nConsiderations:\n- Search quality (a poor search makes everything worse)\n- Editor quality (people won't write in painful editors)\n- Version control (can you see history?)\n- Permissions (right people can read and write)\n- API and integration (for automation)\n- Cost at your scale\n\nFor small teams: a single wiki tool is plenty. For larger: tiered tools.\n\n---\n\n## AI-related notes\n\nLLMs and AI assistants increasingly read documentation. Some considerations:\n\n- Clear, consistent structure helps both humans and AI\n- A glossary of terms helps both\n- File-level metadata (front matter) helps tools\n- Public docs may be read by AI crawlers; consider an `llms.txt` if relevant\n- AI-generated drafts are a starting point, not a final answer; humans review\n\n---\n\n## Failure patterns\n\n**Documentation as a \"later\" task.** Always written later. Later means never. Make docs part of the work.\n\n**One mega-doc for everything.** Wiki page that's 8,000 words. No one reads it. Break by category and topic.\n\n**Stale docs that nobody trusts.** \"Probably out of date\" is the thought that kills documentation. Either keep current or archive.\n\n**Docs everyone agrees should exist but no one writes.** The team agrees onboarding docs would be valuable. Months pass. No one writes them. Make ownership specific.\n\n**Wikis that are graveyards.** Lots of pages, no one trusts any of them. Audit, archive, restart with a slimmer set.\n\n**Docs separated from code.** API docs in a wiki, code in a repo. They drift. Co-locate.\n\n**Docs without examples.** Reference without examples is hard to use. Examples make it concrete.\n\n**Examples that don't run.** Code examples that worked once, drifted. Test examples in CI where possible.\n\n**Long-form when reference would do.** A 2,000-word doc explaining what a 30-row table would. Use the right form.\n\n**Multiple sources of truth.** Same info in three places, all slightly different. Pick canonical, redirect others.\n\n**Doc tools no one uses.** Adopted because of a feature; team doesn't actually use it. Pick tools the team will use.\n\n**Doc style guide that's longer than the docs.** Process beats product. Guide should be short.\n\n**No way to mark docs as deprecated.** Old docs sit alongside current ones with no indication. Add a \"deprecated\" or \"archived\" status.\n\n**No analytics.** No idea what's being used or what's missing. Even basic page views inform priorities.\n\n**Docs that read like specifications.** Dense, formal, hard to scan. Write for the reader.\n\n---\n\n## Output format\n\nA documentation strategy document includes:\n\n- **Audit:** what exists, where, in what state\n- **Tiering and categorization:** the framework applied to existing docs\n- **Gap list:** what should exist but doesn't\n- **Tool decisions:** where each kind of doc lives\n- **Ownership map:** who owns what\n- **Maintenance cadence:** what's reviewed when\n- **Style guide (brief):** consistency standards\n- **Roadmap:** prioritized work to fill gaps and close out dead weight\n\n---\n\n## Reference files\n\n- [`references/doc-types-guide.md`](references/doc-types-guide.md): Detailed guide to the four doc types (reference, how-to, explanation, tutorial) with examples and templates for each.","tags":["documentation","strategy","claude","skills","rampstackco","agent-skills","anthropic","awesome-claude-code","awesome-claude-prompts","awesome-claude-skills","claude-code","claude-skills"],"capabilities":["skill","source-rampstackco","skill-documentation-strategy","topic-agent-skills","topic-anthropic","topic-awesome-claude-code","topic-awesome-claude-prompts","topic-awesome-claude-skills","topic-claude","topic-claude-code","topic-claude-skills","topic-good-first-issue","topic-mcp","topic-product-management","topic-seo"],"categories":["claude-skills"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/rampstackco/claude-skills/documentation-strategy","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add rampstackco/claude-skills","source_repo":"https://github.com/rampstackco/claude-skills","install_from":"skills.sh"}},"qualityScore":"0.540","qualityRationale":"deterministic score 0.54 from registry signals: · indexed on github topic:agent-skills · 181 github stars · SKILL.md body (12,351 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-05-18T18:55:15.391Z","embedding":null,"createdAt":"2026-04-30T01:01:28.213Z","updatedAt":"2026-05-18T18:55:15.391Z","lastSeenAt":"2026-05-18T18:55:15.391Z","tsv":"'000':1574,1709 '1':234,440,625,1330,1332,1334 '10':1117 '2':276,468,678,1708 '3':327,502,707 '30':1715 '4':215,366,536,767 '5':427,564,818 '6':894 '7':943 '8':994,1573 '9':1069 '90':1335 'abandon':800 'accept':1244 'access':1297 'accumul':1275 'accur':262 'accuraci':979 'across':475,782 'actual':130,647,725,1085,1752 'add':1793 'address':990 'adopt':1744 'adr':343,843,1034,1231,1239,1274,1347,1409 'adr-nnn':1238 'affect':826 'agnost':61 'ago':802 'agre':1607,1616 'ai':1371,1483,1488,1502,1523,1531 'ai-gener':1530 'ai-rel':1482 'aim':876,880 'alias':1105 'alongsid':119,1787 'altern':1108 'alway':1551 'analyt':1800 'answer':728,884,1196,1541 'api':244,448,478,572,1460,1655 'appli':62,1850 'architectur':249,338,1232 'archiv':805,984,1604,1645,1797 'aren':1167,1177,1181 'articl':168 'ask':608,757,1159 'assist':1489 'assum':399 'audienc':177,435 'audit':86,626,657,1644,1838 'auto':566,971 'auto-gener':565,970 'autom':582,1464 'automat':599 'awar':272 'backup':299,928,1308,1318 'backup-and-disaster-recoveri':1317 'bad':232,1273 'bar':463,500,528,606 'base':73,145,1050 'basic':1812 'beat':1771 'becom':1277 'best':1392 'better':1090 'bitbucket':1407 'blog':165 'break':269,1580 'brief':1883 'broken':745 'bug':1041 'built':358 'cadenc':36,110,946,951,1876 'call':918 'canon':786,1736 'capabl':376 'captur':350 'categor':679,1847 'categori':216,220,233,275,326,365,685,705,1390,1582 'ceremoni':1356 'chang':453,494,975,982 'check':260,649 'choos':23,94 'ci':585,1697 'clear':405,459,490,883,1183,1495 'close':1893 'co':1667 'co-loc':1666 'code':151,159,571,591,833,841,1190,1404,1654,1660,1688 'code-review-web':158 'codebas':382 'command':1302 'comment':152,576 'common':479,720,831,1107,1299,1303 'compani':482 'company-wid':481 'complet':406 'complex':393 'comprehens':257 'conceptu':336 'concret':1682 'configur':246 'conflat':226 'confluenc':850,1396 'confus':1369 'consequ':1263 'consid':1525 'consider':1429,1494 'consist':1496,1884 'contact':251,1311 'content':131,138,149,171 'content-and-copi':137,170 'content-strategi':148 'context':351,1249 'contractor':296 'contribut':1208 'control':458,1448 'copi':140,146,173 'cost':1465 'coupl':839 'cover':156 'crawler':1524 'criteria':407 'cross':470,487,853,960,1099,1399 'cross-link':1098 'cross-team':469,486,852,959,1398 'current':210,627,1602,1788 'custom':142,180,442,446,616,693,863,866,953,1417,1424 'customer-fac':141,441,615,865,952,1416 'date':776,1247,1248,1348,1593 'day':1329,1336 'dead':769,1895 'decid':47,1262,1350 'decis':253,341,518,747,869,1032,1037,1233,1237,1259,1269,1342,1349,1863 'decision-log':1036 'defin':100 'delet':792,803 'dens':1822 'depend':1122 'deploy':287,385 'deprec':1245,1783,1795 'deriv':569 'deserv':939 'design':4,33,115,340 'detail':1901 'dev':181 'diagram':250 'didn':311 'differ':219,224,431,434,437,607,1734 'disast':1320 'disciplin':1386 'discover':1072 'diátaxi':415 'doc':29,66,68,93,184,222,230,345,430,432,445,473,506,556,568,612,630,667,684,699,771,807,812,824,837,859,891,898,936,996,1018,1026,1048,1060,1071,1075,1103,1115,1146,1166,1411,1420,1518,1558,1566,1586,1605,1618,1651,1656,1669,1711,1739,1761,1769,1781,1785,1817,1853,1868,1906 'documen':44 'document':2,8,22,25,32,45,50,79,88,96,103,117,135,155,204,218,325,347,711,763,1001,1492,1546,1599,1834,1836 'documentation-strategi':1 'docusaurus':861,1413 'doesn':106,397,717,1750,1860 'domin':704 'draft':540,799,1533 'drift':1665,1693 'drill':301 'duplic':781 'editor':1438,1446 'editori':455 'either':1172,1600 'em':923 'engin':205 'entri':255,1039 'ephemer':872 'escal':1310 'establish':108,895,944 'etc':578 'even':1073,1811 'everi':897,974,1189 'everyon':1606 'everyth':1436,1568 'evid':364 'exampl':243,286,337,377,1391,1671,1674,1679,1683,1689,1695,1915 'exec':182 'exist':28,87,183,631,719,798,941,1176,1609,1840,1852,1858 'experi':1053 'explain':1712 'explan':328,690,1279,1912 'extern':179 'eye':661 'eye-open':660 'face':143,443,617,867,954,1418 'fact':259 'fact-check':258 'failur':1304,1544 'featur':1017,1023,1058,1748 'feedback':992,1138 'file':1040,1510,1898 'file-level':1509 'fill':1890 'final':1540 'find':1081,1212 'first':384 'five':1215 'fix':30,89 'forc':1255 'form':1702,1722 'formal':1823 'format':1832 'found':1179 'four':410,1905 'four-way':409 'framework':214,416,426,1849 'fresh':58,462,499,527,596,642 'front':1513 'gap':709,721,1854,1891 'generat':567,574,580,697,972,1532 'get':49,102,231,378,779,1158 'gitbook':1397 'github':1405 'gitlab':1406 'glossari':248,1357,1504 'goal':1223 'goe':906 'good':1271 'graveyard':1634 'great':1074 'growth':196 'guid':1763,1773,1882,1902 'hand':395 'hands-on':394 'happen':1265 'hard':1676,1824 'help':1137,1498,1507,1515 'high':450,461,498 'higher':559 'hire':1046 'histor':355 'histori':1452 'home':821,879 'how-to':277,687,1909 'human':1500,1542 'idea':1802 'identifi':708,768 'import':1383 'incid':1314 'incident-respons':1313 'includ':315,318,977,1837 'increas':1490 'index':1093 'indic':1792 'info':1214,1728 'inform':1815 'inlin':154 'input':175 'integr':1462 'intern':64,178,505,611,858,965,1145,1401,1421 'isn':932,1002,1220 'job':1171 'join':534 'kbs':447 'keep':1352,1601 'kept':261 'kill':1598 'kind':199,889,1866 'know':765 'knowledg':72,144,401 'known':419 'larger':1479 'last':191 'later':1377,1549,1553,1554 'layer':1280 'learn':369 'learning-ori':368 'length':1219 'less':1062,1382 'level':1511 'lightweight':1344 'like':1820 'link':266,362,553,1100 'list':252,1855 'live':635,825,892,1869 'llms':1486 'llms.txt':1527 'locat':832,1668 'log':254,870,1038,1343 'long':801,1701 'long-form':1700 'longer':797,988,1766 'look':239 'lot':1635 'low':549 'made':1033 'maintain':525,830 'mainten':35,109,550,605,945,976,1875 'major':1096 'make':995,1070,1435,1557,1628,1680 'map':1871 'mark':1780 'markdown':835,1402 'matter':602,1514 'may':937,1519 'mean':1362,1555 'measur':655,1118,1121,1149 'meet':614 'mega':1565 'mega-doc':1564 'memor':423 'metadata':1512 'mid':496,526 'mid-to-high':495 'might':814 'mintlifi':862,1414 'miss':811,1810 'mix':701 'mkdoc':1423 'mode':1305 'month':1333,1622 'most-us':1112 'multipl':1723 'narrat':349 'need':242,715 'never':744,1556 'new':82,295,1016,1024,1045 'next':532 'nnn':1240 'nobodi':1588 'none':969 'note':539,702,1485 'notion':849,1395 'oblig':492 'obvious':934 'offici':555 'often':354,636,659,1151,1218 'old':1784 'on-cal':916 'onboard':116,122,293,386,729,736,1047,1325,1340,1617 'one':163,734,784,878,1080,1563,1577,1612,1625,1639,1742,1789 'one-off':162 'op':207 'open':662 'oper':1300 'option':247 'organ':27 'orient':370 'other':547,787,1092,1738 'output':1831 'own':511,522,639,1873 'owner':901,904,908,931 'ownership':460,489,896,1629,1870 'page':650,1094,1126,1141,1570,1637,1813 'pain':1445 'part':998,1009,1020,1028,1559 'pass':1623 'password':292 'pathway':387,1326 'pattern':1143,1185,1428,1545 'peopl':758,813,1440,1455 'per':947,955,1187,1235,1290,1327 'permiss':1453 'person':533,537,925,967 'phrase':1109 'pick':819,1735,1755 'pin':1110 'place':673,783,1731 'plan':19 'platform':99,1088,1125 'play':1258 'playbook':123,1341 'plenti':1477 'plus':957 'pm':921 'point':1537 'poor':1433 'possibl':1699 'post':166 'postmortem':1042 'prerequisit':317 'prior':400 'priorit':1887 'prioriti':1816 'probabl':1590 'procedur':285,1309 'process':484,1025,1770 'produc':203,1014 'product':14,67,85,206,1367,1772 'progress':544 'project':1006,1188 'promis':1229 'promot':557 'properti':256,302,348,388 'propos':1243 'public':444,1419,1517 'purpos':225 'qualit':1148 'qualiti':1431,1439 'quarter':958,962,966 'queri':1129,1134 'question':1157 'rational':339,748 're':829 'read':1226,1457,1491,1521,1578,1819 'read-it-m':1225 'reader':1830 'readm':70,842,1186,1194,1408,1415 'realiz':670,676 'recent':737 'record':342,873,1234,1354 'recoveri':1321 'redirect':789,1737 'reduc':1368 'refer':235,245,449,573,686,1672,1704,1897,1908 'references/doc-types-guide.md':1899,1900 'referr':653,1142 'relat':1102,1484 'releas':466,956 'relev':274,989,1529 'repo':834,1191,1663 'requir':174 'reset':290 'respons':1315 'restart':1646 'restor':300,1306 'result':1133 'review':160,456,592,950,1543,1879 'right':1454,1721 'roadmap':1886 'role':732,914,1328 'rollout':1031 'rotat':919 'row':1716 'run':6,297,583,1203,1687 'runbook':69,517,738,844,1043,1289,1323 'said':1388 'scale':1468 'scan':1826 'scatter':92,637 'schema':577 'scope':38,111,403 'scratchpad':538,696,968 'search':1083,1104,1128,1430,1434 'searchabl':263 'see':1312,1337,1451 'sentenc':1216 'separ':1005,1652 'sequenc':389 'serv':223,433 'servic':480,847 'set':77,1650 'shape':190 'share':472,477,694 'ship':1057 'short':1776 'signific':1236 'simpl':391 'singl':134,586,1473 'sit':1786 'site':860,1412,1422 'situat':1253 'size':194 'skill':17 'skill-documentation-strategy' 'slight':1733 'slimmer':1649 'slow':452 'small':1470 'someon':309,372 'sourc':587,1724 'source-rampstackco' 'specif':283,1184,1361,1427,1630,1821 'split':412 'stabl':264 'stack':60 'stack-agnost':59 'stage':289 'stake':438 'stale':31,90,806,907,1585 'standard':454,485,519,548,579,618,1324,1885 'start':379,1536 'state':187,628,1844 'status':1242,1798 'stay':57 'step':304,306,624,677,706,766,817,893,942,993,1068,1116 'step-by-step':303 'strategi':3,46,150,344,1835 'structur':265,1497 'style':1762,1881 'supersed':1246 'support':208 'system':9,323,741,983,1291 'tabl':1717 'task':284,1550 'team':12,65,83,121,193,471,476,488,504,509,515,521,524,610,664,695,714,854,857,912,961,964,1055,1339,1365,1400,1426,1471,1615,1749,1758 'team-intern':503,609,856,963 'team-maintain':523 'team-onboarding-playbook':120,1338 'team-own':520 'team-specif':1425 'tech':421 'technic':39,112,1410 'templat':1917 'term':1358,1506 'test':307,1694 'thing':237,330,794 'think':1065 'thought':1596 'three':1730 'ticket':868 'tie':464 'tier':428,439,467,501,535,560,563,601,681,692,948,949,1480,1845 'tight':838 'time':1139 'titl':1241 'tool':26,97,209,1372,1378,1380,1389,1475,1481,1516,1740,1756,1862 'topic':1097,1584 'topic-agent-skills' 'topic-anthropic' 'topic-awesome-claude-code' 'topic-awesome-claude-prompts' 'topic-awesome-claude-skills' 'topic-claude' 'topic-claude-code' 'topic-claude-skills' 'topic-good-first-issue' 'topic-mcp' 'topic-product-management' 'topic-seo' 'train':1370 'trajectori':197 'trigger':42 'troubleshoot':319 'trust':815,1589,1640 'truth':589,1726 'tutori':367,691,1913 'type':1907 'unsustain':622 'updat':192,491,780,980,997,1044,1049 'usabl':594 'use':15,76,118,127,136,147,169,212,474,529,648,1114,1153,1678,1719,1743,1753,1760,1806 'useless':1077 'user':991 'valuabl':562,1621 'verifi':978 'version':271,320,457,1345,1447 'version-awar':270 'view':651,1127,1814 'visibl':451 'vision':346 'walk':371 'wast':620 'way':333,361,411,756,1288,1778 'web':161 'week':1331 'weight':770,1896 'well':418 'well-known':417 'whether':827 'wide':483 'wiki':848,1394,1474,1569,1631,1659 'wish':761 'without':902,1059,1355,1670,1673 'won':1441 'word':1575,1710 'work':41,114,201,516,542,726,1000,1012,1086,1562,1691,1888 'work-in-progress':541 'workflow':623 'wors':809,1437 'would':1619,1705,1718 'write':40,113,128,313,422,1443,1459,1613,1626,1827 'written':1552 'x':724 'yes':1164 'yet':746 'zero':374,1132 'zero-result':1131","prices":[{"id":"722a3725-8e1a-4100-86c6-584b022dee13","listingId":"70be6e85-da1a-4d45-a407-a8a5a0d3a500","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"rampstackco","category":"claude-skills","install_from":"skills.sh"},"createdAt":"2026-04-30T01:01:28.213Z"}],"sources":[{"listingId":"70be6e85-da1a-4d45-a407-a8a5a0d3a500","source":"github","sourceId":"rampstackco/claude-skills/documentation-strategy","sourceUrl":"https://github.com/rampstackco/claude-skills/tree/main/skills/documentation-strategy","isPrimary":false,"firstSeenAt":"2026-04-30T01:01:28.213Z","lastSeenAt":"2026-05-18T18:55:15.391Z"}],"details":{"listingId":"70be6e85-da1a-4d45-a407-a8a5a0d3a500","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"rampstackco","slug":"documentation-strategy","github":{"repo":"rampstackco/claude-skills","stars":181,"topics":["agent-skills","anthropic","awesome-claude-code","awesome-claude-prompts","awesome-claude-skills","claude","claude-code","claude-skills","good-first-issue","mcp","product-management","seo","show-hn","showcase","showdev","web-design","web-development"],"license":"mit","html_url":"https://github.com/rampstackco/claude-skills","pushed_at":"2026-05-10T22:40:22Z","description":"Stack-agnostic Claude Skills covering the full website lifecycle: brand, design, content, SEO, dev, ops, growth, and research. Build, ship, audit, optimize.","skill_md_sha":"1b65361719ded70a74ae2114511f89629890d745","skill_md_path":"skills/documentation-strategy/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/rampstackco/claude-skills/tree/main/skills/documentation-strategy"},"layout":"multi","source":"github","category":"claude-skills","frontmatter":{"name":"documentation-strategy","description":"Design and run a documentation system for a team or product. Use this skill when planning what to document, choosing a documentation tool, organizing existing docs, fixing stale documentation, designing a maintenance cadence, or scoping technical writing work. Triggers on documentation, docs, tech writing, knowledge base, wiki, runbook, README, internal docs, doc audit, doc maintenance, stale docs, where do we document. Also triggers when the team is repeatedly answering the same questions or when onboarding takes too long."},"skills_sh_url":"https://skills.sh/rampstackco/claude-skills/documentation-strategy"},"updatedAt":"2026-05-18T18:55:15.391Z"}}