Knowledge Operations

Knowledge bases do not fail by being incomplete. They fail by becoming untrustworthy: once a reader has been burned twice by a confidently wrong page, they stop reading and start asking in chat, and every subsequent doc you write is written into a void. This skill treats the KB as an operational system with owners, freshness SLAs, and a measurable health score, not as a writing backlog.

The core insight is that deletion is the highest-value action available. Most struggling knowledge bases need 30% fewer pages, not more pages.

When to use this skill

• The wiki is large and distrusted, people ask in chat rather than search, and are right to
• A doc audit is due before onboarding a cohort, an acquisition merge, or a compliance review
• Search returns the wrong page consistently, usually because three near-duplicates compete
• Nobody owns large parts of the KB and nobody can say what is current
• Planning a documentation-debt sprint and needing a ranked backlog rather than a wish list
• Migrating between wiki platforms and needing to decide what survives the move

Inputs the skill expects

• A doc inventory: path, title, owner, last-updated date, and outbound links
• Criticality tier per doc, or enough signal (traffic, area) to infer it
• Usage data if available, 90-day views separate the load-bearing pages from the archive
• The as-of date for the audit, so results are reproducible
• Your freshness SLA policy, or acceptance of the default tiering below
• Whether deletion is politically possible, which changes the entire remediation plan

Clarify First

Before generating, settle the inputs below. When one is missing or vague and would change the result, ask about it; when it wouldn't, use a sensible default and say which one you used.