llm-wiki-knowledge-base

name	llm-wiki-knowledge-base
description	Create, maintain, and audit source-linked LLM Wiki or Second Brain knowledge bases for any project. Use when building repo-backed wiki layers, source indexes, coverage matrices, fidelity audits, traceability audits, new-session handoffs, or raw-evidence-first workflows that must preserve source truth and avoid hallucinated project knowledge.
metadata	{"short-description":"Build and audit source-linked LLM Wikis"}

LLM Wiki Knowledge Base

Use this skill to create or audit a project wiki that helps future agents work from files instead of chat memory. The wiki is a navigation and synthesis layer, not the source of truth.

Core Rule

Source evidence comes first. The wiki helps find, connect, and audit evidence; it must not replace raw logs, source files, reports, test results, schemas, handoffs, or canonical inventories.

Startup Flow

1. Read project instructions first: AGENTS.md, AGENT.md, HANDOFF.md, or nearest local equivalents.
2. Identify the canonical source of truth: raw data, result logs, source files, reports, inventories, issue trackers, specs, or package handoffs.
3. Only then read the wiki entrypoints: wiki/index.md, WIKI-SCHEMA.md, source_index.md, current status, decisions, contradictions, and open questions.
4. If the task involves new test/result data, capture raw evidence before analysis and update the wiki last.
5. Preserve unrelated dirty files. Use selective staging; never use git add . in a dirty repo.

Creation Workflow

Create the smallest useful wiki under the relevant project workspace, usually wiki/ or a domain workspace such as eval/wiki/.

Recommended pages:

• index.md - entrypoint and navigation.
• WIKI-SCHEMA.md - source order, page template, non-negotiable rules.
• source_index.md - source families, exact paths, evidence status, use rules.
• current_status.md - current project state and next safe task.
• decisions.md - accepted decisions with source evidence and tradeoffs.
• contradictions.md - unresolved source conflicts.
• open_questions.md - missing evidence and follow-up checks.
• protocols/query_protocol.md - how to answer project questions.
• protocols/ingest_protocol.md - how to add new evidence.
• validation/coverage_matrix.md - processed, partial, reference-only, or missing coverage.
• validation/fidelity_audit.md - source-to-wiki accuracy checks.
• validation/traceability_audit.md - source links, static checks, staging risks.
• log.md and CODEX-HANDOFF-<topic>.md - continuation record.

Add domain pages only when they help navigation: versions, cases, concepts, packages, APIs, datasets, experiments, or workflows.

Multi-Lane And Comparator Wikis

When a repo has multiple related domains, create separate wiki lanes per domain instead of merging their evidence into one doctrine layer. Crosslinks between lanes must state their scope, usually comparator_only or reference_only.

Do not let one lane's active package, latest rules, or evaluation conclusions overwrite another lane's goals. A comparator page can suggest questions and test ideas, but importing a rule requires raw evidence from the destination domain.

Audit Workflow

Audit a wiki with these checks:

• Coverage: important raw/source files are listed and marked with explicit evidence status such as processed, partially processed, reference-only, active-package-text, processed-qualitative-matrix, needs-normalized-scoring, needs-review, or not ingested.
• Traceability: important claims cite source files, not just other wiki pages.
• Fidelity: summaries preserve the source meaning and do not upgrade hypotheses into facts.
• Matrix fidelity: qualitative matrices preserve source-level fields and do not invent numeric scores, percentages, or pass thresholds that were not in the raw evidence.
• Usability: a new session can start from the index and find current state, next task, risks, and required protocols.
• Maintainability: updates have logs/handoffs, validation pages, and selective commits that avoid unrelated dirty state.
• Protected paths: active/source package folders that are read-only for the workflow remain unmodified, and the staged set is inspected before commit.

Prefer spot-checking high-impact pages first: current status, latest results, promotion/rollback decisions, and pages that could change implementation.

Optional Sub-Agent Audit

For large wiki ingests, traceability reviews, multi-source refactors, or high-accuracy result consolidation, the lead agent may use temporary read-only sub-agents when the user or project instructions allow it.

Use sub-agents only after the canonical source evidence has been identified, and after raw capture is complete when new results are involved. The lead agent remains responsible for final synthesis, source checking, validation, and staging.

Useful read-only audit scopes:

• coverage auditor: compare source inventory against wiki/source index and coverage matrix;
• traceability auditor: find claims that cite only wiki pages instead of raw or source files;
• fidelity auditor: check that summaries do not upgrade hypotheses into facts;
• staging/protected-path auditor: inspect intended changed files, protected paths, and selective staging boundaries.

Sub-agent findings are audit input, not source evidence. Record accepted findings in validation pages, decisions, contradictions, open questions, handoffs, or logs. Do not treat sub-agent summaries as raw evidence, package promotion evidence, or a replacement for source files.

Lead + Wiki + Sub-Agent Reconciliation

For dense evaluation work, a solo lead agent plus the wiki is usually enough for navigation, but read-only sub-agents improve coverage when the task has many independent failure surfaces. Use them to inspect disjoint questions such as wording/verbs/actions/camera/physics, cross-version pattern repetition, source-index coverage, and protected-path staging. The lead agent must still reconcile findings against raw sources and update the wiki last.

Do not encode "use sub-agents for everything" as doctrine. Use them when the added review surface is worth the coordination cost: major version packages, large result consolidations, cross-version audits, or high-accuracy wiki traceability work.

Evidence Labels

Use explicit status instead of inferred certainty:

• raw_evidence
• analysis_report
• strategy_plan
• handoff
• active_package_text
• filename_header_mismatch
• processed
• partially_processed
• processed_reference
• processed_observation_template
• processed_qualitative_matrix
• reference_only
• needs_normalized_scoring
• needs_review
• not_ingested
• MISSING_DATA
• UNKNOWN

Reference-only material can guide questions, test design, or prompt structure, but cannot prove an outcome or justify promotion.

Active package text proves package intent, not rendered behavior. Keep it separate from raw result evidence, and mark filename/header mismatches instead of silently choosing one version.

Use processed_qualitative_matrix when source files include reviewed observations, user checks, verdict notes, or qualitative fields but lack a consistent numeric rubric. Normalize the observations into comparable rows without inventing precision. If future testing needs numbers, add the scoring fields at capture time before analysis.

Rule Cards

When a project benefits from reusable lessons, create small rule-card pages in the project wiki instead of embedding project facts in the global skill. Each rule card should include:

• ## Source Evidence
• ## Evidence Status
• ## Do Not Infer
• ## Confidence

Separate statuses such as rendered behavior, observed limit, package/spec intent, hypothesis, and comparator-only transfer. A rule card can guide future work, but it cannot promote a package, replace raw evidence, or cross domains without destination-domain evidence.

Update Rules

• New evidence: raw capture -> canonical inventory/source index -> analysis -> decisions/contradictions/open questions -> wiki pages -> validation pages -> handoff/log.
• Qualitative results: raw/user-checked capture -> inventory/source index -> qualitative matrix -> rule cards or case/concept pages -> validation pages.
• Major audit with sub-agents: raw/source evidence -> lead scope definition -> read-only specialist audits -> lead reconciliation -> validation pages -> handoff/log -> selective staging check.
• Refactor: preserve source links, update redirects/navigation, and run traceability checks.
• Skill or workflow extraction: keep the reusable skill general; keep project-specific evidence in the project wiki.
• Commits: stage only related wiki/skill/prompt/handoff files and inspect git diff --cached --name-only before committing.
• Dirty repo audit: verify protected source folders stayed clean and that unrelated scratch, memory, generated assets, or planning files are not staged accidentally.

Do Not

• Do not treat wiki summaries as source evidence.
• Do not fill missing facts from memory.
• Do not promote packages, change production files, or update durable skills from one weak or first-round result.
• Do not copy rules across wiki lanes unless the destination lane has its own raw evidence.
• Do not treat sub-agent summaries as source truth.
• Do not let sub-agents edit shared wiki, source, or package files unless they have an explicit disjoint write scope.
• Do not bulk-import unrelated source folders just because they exist.
• Do not overwrite or clean unrelated dirty files while creating the wiki.