Knowledge Operations

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, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Which docs are load-bearing vs archival — a stale onboarding runbook is an incident; a stale 2019 retro is fine, and treating them identically produces a backlog nobody works
• Whether pages can be deleted or only archived — deletion authority roughly halves the remediation effort, so the plan differs structurally
• Who can be assigned as an owner — ownership assigned to a team alias rather than a person is the same as no owner, and the audit will keep reporting it
• The as-of date for the audit — staleness is relative, and an undated audit cannot be compared against the next one

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.