---
name: documentation-knowledge-platform
description: Build and maintain a source-backed documentation and knowledge platform across repositories, OpenAPI documents, ADRs, issues, pull requests, releases, runbooks, wikis, architecture diagrams, and generated references. Use for lnxr-docs, Greg wikis, API documentation, docs MCPs, stale-page detection, code-doc drift, onboarding, troubleshooting, and answer generation with precise sources.
compatibility: Requires repository and documentation read access. Publishing, deleting, moving, or changing public documentation requires explicit authorization and link validation.
license: Apache-2.0
---

# Documentation and knowledge platform

Documentation must identify its source of truth, intended audience, version and maintenance owner. Do not merge historical, planned and currently implemented behavior into one unqualified answer.

## Source hierarchy

Prefer, in order appropriate to the question:

1. current executable code and schemas;
2. generated API or configuration references;
3. tested runbooks and deployment configuration;
4. ADRs and accepted specifications;
5. current repository documentation;
6. issues, pull requests and roadmap material;
7. archived or third-party references.

Mark conflicts rather than silently choosing the most convenient source.

## Documentation workflow

1. Define product, repository, version, audience and task.
2. Search code, docs, issues, releases and operational evidence.
3. Collect exact source locations and last-updated metadata.
4. Separate facts, planned changes, assumptions and recommendations.
5. Draft the smallest durable document in the correct location.
6. Add links to deeper references instead of duplicating large bodies of text.
7. Validate commands, paths, examples, anchors and API schemas.
8. Run the documentation build and link checks where available.
9. Record ownership and an update trigger.

## Drift detection

Flag:

- API operations absent from docs or documented operations absent from code;
- renamed environment variables, commands, ports, paths and domains;
- screenshots or UI descriptions no longer matching the product;
- runbooks that reference deleted workflows or services;
- examples using unsupported framework or dependency versions;
- roadmap items presented as implemented;
- duplicated pages with contradictory instructions.

## MCP knowledge behavior

A documentation MCP should be read-only, source-aware, allowlisted and capable of returning precise file, section, version and URL metadata. Limit retrieved bodies and support search before fetch. Never expose private repository content through a public endpoint.

## Writing rules

Use task-oriented titles, prerequisites, exact commands, expected results, verification, rollback and troubleshooting. Avoid unsupported claims such as “production-ready” unless evidence is defined. Preserve security boundaries and omit secrets from examples.

## Output

Return scope, sources consulted, confidence, conflicts, pages created or changed, validation performed, stale content found, ownership, update triggers and remaining documentation gaps.