--- name: maintain-knowledge-wiki description: Initialize, operate, and improve a persistent agent-managed Markdown knowledge wiki using OKF v0.2. Use when Codex needs to create a project wiki, ingest or semantically prune sources, integrate or correct a project decision, answer from the wiki, store a durable synthesis, maintain indexes and provenance, lint wiki health, or update the project's agent/wiki operating rules. Trigger for German or English requests about Wissensdatenbank, Wiki-Pflege, Quellen-Ingest, Quellenbereinigung, Entscheidungsdokumentation, knowledge bases, source cleanup, or wiki maintenance. --- # Maintain Knowledge Wiki Maintain a persistent, compounding knowledge layer between detailed sources and the user. Keep ordinary sources immutable; manage project decisions under `sources/decisions/`. Integrate new information into existing concepts instead of treating the wiki as a collection of isolated summaries. Workflow version: read `VERSION`. ## Discover the project policy 1. Locate the project root and the applicable `AGENTS.md`. 2. Locate `wiki.md`, the source directory, and the wiki bundle. 3. Read the applicable `AGENTS.md` and `wiki.md` completely before any wiki operation. 4. Treat local project instructions as authoritative. Use this skill to supply missing workflow guidance, not to overwrite deliberate local variations. 5. Preserve user changes and immutable source files outside `sources/decisions/`. Delete an ordinary source only during an explicitly authorized source-cleanup task after proving it is semantically redundant. If no local wiki policy exists, initialize one with: ```bash python3 /scripts/init_wiki.py ``` The initializer copies the files from `assets/boilerplate/` and refuses to overwrite differing files unless the user explicitly requests replacement and `--force` is supplied. After successful initialization, show the initializer's concise quick-start guidance so the user knows where sources belong and which wiki tasks to request. Do not expand it unless the user asks for more detail. ## Route the task - **Initialize**: Copy the boilerplate, inspect existing project conventions, then adapt paths or domain-specific types only when necessary. - **Ingest**: Read the complete source, identify affected concepts, integrate claims and relationships, update provenance, indexes, log, and source manifest, then lint. - **Prune sources**: Prove complete semantic coverage by retained sources, update wiki provenance, delete only fully redundant sources, record replacement metadata, then lint. - **Query**: Discover via the index and search, inspect relevant concepts and their provenance, follow important claims to original sources, and synthesize an answer. Keep the wiki read-only unless the request or decision policy authorizes a write. - **Record a decision**: Persist every clearly made or corrected project decision without requiring a separate save request. - **Maintain or lint**: Check structure, metadata, links, index coverage, freshness, contradictions, duplicates, orphans, and verification state. - **Change operating rules**: Route general agent behavior to `AGENTS.md` and wiki-specific structure or workflow to `wiki.md`. ## Capture decisions Distinguish decisions from proposals, questions, hypotheticals, and open options. Persist only a clearly binding choice or correction. Route a decision as follows: - Put domain, product, architecture, technical, organizational, and other project decisions into the wiki. - Put general agent-working rules into `AGENTS.md`. - Put wiki structure, format, ingestion, query, maintenance, and lifecycle rules into `wiki.md`. For a project decision: 1. Find related files under `sources/decisions/`, the canonical wiki concepts, and any prior decision. 2. Create, update, or delete the smallest useful decision source structure under `sources/decisions/`. Preserve all known detail, but do not invent rationale or consequences. 3. Append every decision, change, or withdrawal to `sources/decisions/log.md` as a concise bullet in commit-message style, grouped under an ISO date heading. Use a one-line action summary in the imperative mood without a trailing period, for example `Replace SQLite with PostgreSQL`. Keep this log append-only except for factual corrections. 4. Scan the source manifest and integrate every affected decision source, including changed and missing entries, into the wiki. 5. Update the affected knowledge where it naturally belongs. Do not require a `decisions/` wiki directory or a dedicated decision page. Create a `type: Decision` page only when the decision is independently important. 6. Mark replaced knowledge as superseded or deprecated only when its history remains useful. 7. Update provenance, affected indexes, and the root log. Mark present sources as processed and acknowledged deleted decision sources as removed only after the wiki reflects the effective state. Complete source capture, manifest processing, and wiki synchronization in the same task. ## Ingest sources 1. Scan the source tree before choosing files: ```bash python3 /scripts/source_manifest.py scan ``` 2. Process only entries reported as `pending` during a normal batch ingest. Treat `missing` entries as a review requirement, never as authorization to delete wiki content. A deliberately deleted source may be marked `removed` only after its effects have been integrated and its removal is authorized under the decision or source-cleanup workflow. Do not reread `processed` or `removed` entries unless explicitly requested or the source reappears. 3. Confirm each selected source. Never modify an ordinary source; modify a decision source only through the decision-capture workflow. 4. Read the whole source, including relevant tables, images, and attachments when tools permit. 5. Extract claims, entities, concepts, relationships, dates, uncertainty, contradictions, and source scope. 6. Search the existing wiki before creating pages. 7. Create a source summary only when useful; do not stop at the summary. 8. Update every materially affected concept and cross-link. 9. Maintain `sources`, claim-level footnotes, `generated`, lifecycle metadata, and verification state. 10. Update local and root indexes plus the root log. 11. Run structural lint and inspect the diff. 12. Only after successful integration, mark each completed source: ```bash python3 /scripts/source_manifest.py \ mark-processed ``` Leave partially or unsuccessfully processed sources as `pending`. Use `--all-pending` only when every pending source was fully integrated. Use `scan --full` for an explicit integrity pass that recomputes every SHA-256 instead of trusting unchanged size and modification time. After integrating any deliberately deleted source, acknowledge it with: ```bash python3 /scripts/source_manifest.py \ mark-removed \ --reason "" ``` ## Prune redundant sources Delete ordinary sources only when the user explicitly requests source cleanup or local policy grants that authority. Newer does not mean complete. For each candidate: 1. Read the candidate and every proposed replacement completely, including relevant tables, images, and attachments. 2. Compare atomic claims, entities, scope, dates, uncertainty, contradictions, and provenance. Confirm every material contribution of the candidate is supported by one or more retained sources. 3. Retain the candidate if it contains any unique information, independent corroboration worth preserving, unresolved contradiction, historical context needed by the project, or legal/audit value. 4. Update affected wiki claims, footnotes, and `sources` entries to the retained sources. Never cite a replacement for a claim it does not support. 5. Delete only the proven-redundant source, scan the manifest, and inspect the resulting `missing` entry. 6. Append a concise `Source Cleanup` entry to the root log and acknowledge the deletion with its reason and replacement paths: ```bash python3 /scripts/source_manifest.py \ mark-removed \ --reason "" \ --replacement ``` 7. Lint and inspect the diff. The retained manifest tombstone must contain the deleted source's last hash, removal time, reason, and replacements. If coverage is uncertain, retain the source and report the unresolved gap. ## Answer from the wiki Start with `index.md`, then use links and text search. Verify important claims against concept provenance and, when needed, raw sources. Surface stale, unverified, contradictory, or missing information. Synthesize instead of concatenating excerpts. Do not persist every answer. Persist a durable comparison, analysis, or synthesis only when the user requested a wiki change or when the answer contains a clearly made project decision covered by the decision policy. ## Maintain quality Run: ```bash python3 /scripts/source_manifest.py status python3 /scripts/lint_wiki.py /wiki ``` Treat the script as a structural baseline, not a semantic proof. Also inspect: - conflicting or stale claims, - orphaned or duplicated concepts, - missing concepts and cross-links, - mismatched source IDs and footnotes, - invalidated verification events, - inconsistent tags, titles, types, and filenames, - pending or missing source-manifest entries, - processed entries whose current and processed hashes differ, - knowledge gaps worth investigating. Fix safe mechanical issues within an authorized maintenance task. Report ambiguous semantic changes rather than guessing. ## Apply OKF v0.2 Read `references/okf-v0.2.md` when initializing or changing the schema, validating conformance, handling trust/provenance/lifecycle edge cases, or working with Attested Computations. Do not load the full reference for a simple query when the local `wiki.md` already answers the question. At minimum, require parseable YAML frontmatter and a non-empty `type` on each concept page. Reserve `index.md` and `log.md`. Preserve unknown fields and types. Prefer bundle-relative Markdown links and keep provenance distinct from ordinary relationships. ## Verify every write After a wiki-changing task: 1. Validate changed frontmatter and internal links. 2. Confirm footnote labels match `sources[].id`. 3. Confirm affected index entries and the root log are current. 4. Confirm the source manifest marks only fully integrated content as `processed`. 5. Confirm no ordinary source content changed, every ordinary source deletion was explicitly authorized and proven redundant, and every change under `sources/decisions/` represents an intended decision update. 6. Inspect the diff for unintended edits. 7. Report the durable outcome and any unresolved conflict or gap.