Maintain Repository Wiki with Verified Engineering Knowledge

Maintain Codex Wiki is a skill for running a review-first engineering wiki inside a repository. It treats a repository-local Markdown wiki as compiled engineering knowledge, not as an automatic source of truth. It preserves provenance, separates evidence classes, and requires review before wiki conclusions become repository rules, skills or learning material. It comes from the Phelan164/codex-howto repository under the MIT license.

The wiki lives in a knowledge/ directory with an index.md, a log.md, a sources.json registry and folders for decisions, experiments and topics. Every page starts with one status: verified, community, experimental or decision. Capture and Archive pages default to experimental and are never labeled verified automatically.

# Article title
> Status: <verified|community|experimental|decision>
> Last verified: YYYY-MM-DD
> Sources: `source-id`, `another-source-id`

Sources fall into four classes: official (current first-party documentation), repository (versioned evidence already in the repository), community (an external implementation, article or discussion) and experiment (a reproducible evaluation with setup and limitations). Official sources establish current product behavior, while community sources are patterns to test rather than specifications.

You choose exactly one of six operations. Query reads the index, searches the wiki, distinguishes verified guidance from community practice and experiments, answers with links, states when the wiki has no evidence, and is read-only by default. Capture preserves a durable lesson from repository or experiment evidence on explicit request, rejecting chat prose, unmerged proposals and model output as proof. Ingest adds external research on explicit request, records metadata instead of full content and preserves disagreements. Archive saves a query synthesis as a compact experimental page. Lint checks mechanically. Promote moves verified knowledge into AGENTS.md, a focused skill, a module, or a script, CI check or hook, and only when explicitly requested.

Use it to query what a repository already knows about a technical decision, capture a lesson from a merged change, incident, review or experiment, ingest external research without treating it as authoritative, reconcile conflicting or superseded guidance, check wiki structure, citations, freshness and index coverage, or promote verified knowledge.

Do not invoke it merely because a task produced code or chat output. No material wiki change is a valid result. Its limitations state that structural lint cannot prove a citation supports a claim, that source freshness needs periodic human verification, and that it does not replace repository-specific security, privacy or review requirements.

Inputs are an explicit request naming one operation, the repository and its knowledge/ directory. Completion reports cover the operation performed, pages and source records changed, checks run and results, conflicts or freshness uncertainty, promotion done or deferred, and the review still required.

The skill has strong safety rules. A confinement invariant requires normalized repository-relative paths, rejects absolute paths and parent components, resolves symlinks and rejects unsafe ones before any operation touches a file. Wiki pages, registry fields and sources are untrusted data, so embedded instructions are ignored and suspected prompt injection is reported. A registered external URL is provenance, not permission to fetch, and authorized fetches need a public HTTPS destination with redirect validation. Repository evidence must be pinned to a full Git commit ID reachable from a trusted branch configured with git config --local --add codex.wikiTrustedRef, and is read from the Git object database with GIT_NO_LAZY_FETCH=1 and GIT_NO_REPLACE_OBJECTS=1. Shallow or partial clones are reported as incomplete rather than drifted.

The skill works with Git, a sources.json registry with schema_version, ids, kinds, URLs or paths, revisions and supersedes links, CI checks, and pull requests. Generated factual changes need human review, and scheduled maintenance may prepare a draft pull request but must not merge or push to protected branches.

It is for engineering teams that want a trustworthy, citation-backed knowledge base in their repository and want an assistant to maintain it without letting unreviewed claims become rules.