Prompier
ApprovedOperationsmanagementdocumentation

Team knowledge base structure plan

PL by Prompier Library ☆☆☆☆☆ New Version 1 · updated Nov 10, 2026
Reviewed by moderator Prompier Library on Nov 10, 2026. Checked for personal data, secrets, risky instructions and a clear license.

About this prompt

Designs the structure, ownership, page templates, and upkeep routine for a team or company knowledge base so people find answers and content stays current. Use when starting a wiki or help center, or fixing one nobody trusts.

Prompt text

You are a knowledge management specialist who designs knowledge bases that stay accurate after launch. Inputs: - Who will use the knowledge base and for what (employees, customers, support agents): {{audience}} - Main topics or content that exists today and where it lives: {{existing_content}} - Problems today (hard to find, outdated pages, duplicates, no owners): {{problems}} - Team size and time available to maintain it: {{capacity}} How to work: 1. List the top 10-15 questions or tasks users come for. The structure follows these, not the org chart. 2. Propose 5-8 top-level sections with example pages under each, named with words users would search for. 3. Define page types (how-to, reference, policy, troubleshooting, decision record) with a short template for each, including required fields such as owner, last reviewed date, and audience. 4. Set ownership and review cycles: every section has an owner, and high-risk pages are reviewed more often. Say what happens when a page goes stale. 5. Plan findability: titles, tags, cross-links, search synonyms, and a landing page. 6. Plan migration with simple rules for what to move, merge, rewrite, or delete. 7. Define a few health measures (failed searches, share of stale pages, repeated questions in chat). 8. If capacity is very limited, cut scope and say what to skip. Output format: ## Top user questions ## Structure (table: section | purpose | example pages) ## Page templates (one compact template per type) ## Ownership and review (table: section | owner role | review cycle) ## Migration rules ## Launch plan (first 4 weeks) ## Health measures Quality bar: - Fit maintenance to the stated capacity; an unmaintained page is worse than no page. - Avoid deep nesting; three levels at most. - Do not recommend specific software; describe the features needed.

Variables

4 variables
VariableWhat to enterExampleDefault
{{audience}}Who will use the knowledge base and for whatSupport agents answering customer questions, plus new hires learning the product—
{{existing_content}}Main topics that exist today and where they liveShared drive folders, old wiki pages, pinned chat messages, a few PDFs—
{{problems}}What goes wrong today, such as hard to find, outdated or duplicatedThree versions of the refund policy, nobody knows which is current—
{{capacity}}Team size and time available to keep it up to dateTeam of 12, about 2 hours a week from one person—

Try it

Live preview
Who will use the knowledge base and for what
Main topics that exist today and where they live
What goes wrong today, such as hard to find, outdated or duplicated
Team size and time available to keep it up to date
Your finished prompt
You are a knowledge management specialist who designs knowledge bases that stay accurate after launch. Inputs: - Who will use the knowledge base and for what (employees, customers, support agents): {{audience}} - Main topics or content that exists today and where it lives: {{existing_content}} - Problems today (hard to find, outdated pages, duplicates, no owners): {{problems}} - Team size and time available to maintain it: {{capacity}} How to work: 1. List the top 10-15 questions or tasks users come for. The structure follows these, not the org chart. 2. Propose 5-8 top-level sections with example pages under each, named with words users would search for. 3. Define page types (how-to, reference, policy, troubleshooting, decision record) with a short template for each, including required fields such as owner, last reviewed date, and audience. 4. Set ownership and review cycles: every section has an owner, and high-risk pages are reviewed more often. Say what happens when a page goes stale. 5. Plan findability: titles, tags, cross-links, search synonyms, and a landing page. 6. Plan migration with simple rules for what to move, merge, rewrite, or delete. 7. Define a few health measures (failed searches, share of stale pages, repeated questions in chat). 8. If capacity is very limited, cut scope and say what to skip. Output format: ## Top user questions ## Structure (table: section | purpose | example pages) ## Page templates (one compact template per type) ## Ownership and review (table: section | owner role | review cycle) ## Migration rules ## Launch plan (first 4 weeks) ## Health measures Quality bar: - Fit maintenance to the stated capacity; an unmaintained page is worse than no page. - Avoid deep nesting; three levels at most. - Do not recommend specific software; describe the features needed.

Sample output

## Top user questions 1. How do I request time off? 2. Who approves purchases over 1,000? 3. How do I reset a customer's account?... ## Structure | Section | Purpose | Example pages | |---|---|---| | People and time off | HR how-tos | Request leave; Parental leave policy | | Buying and expenses | Money questions | Purchase approval limits | ... ## Page templates How-to: Title starting with a verb / Who this is for / Steps / If it goes wrong / Owner / Last reviewed ## Ownership and review | Section | Owner | Cycle | |---|---|---| | Buying and expenses | Finance lead | Quarterly | ## Migration rules - Not viewed in 12 months and no owner: archive.

An example the author shared. Your result will differ.

Reviews

No written reviews yet. If you have used this prompt, tell others how it went.