Files
chemenu/instructions/wiki-status/SKILL.md
T
torben 0fb8fd6122
CI / verify (push) Successful in 52s
Release / release (push) Successful in 36s
stack: SKILL.md-Links auf repo-root-relative Pfade umgestellt, docs verify/instructions verify pruefen Linkziele
Files changed:
- CHANGES.md
- VERSION
- instructions/CONTRACT.md
- instructions/dev/doc-pull-through.md
- instructions/dev/stack-close/SKILL.md
- instructions/dev/stack-dev/SKILL.md
- instructions/wiki-ingest/SKILL.md
- instructions/wiki-lint/SKILL.md
- instructions/wiki-manage/SKILL.md
- instructions/wiki-query/SKILL.md
- instructions/wiki-status/SKILL.md
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/instructions_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_instructions_cmd.py
2026-09-12 23:21:45 +02:00

2.9 KiB

name, description
name description
wiki-status Show a quick read-only snapshot of the LLM wiki - page counts, orphan pages, uncovered raw files, recent activity. Use when the user says "wiki status", "show wiki statistics", "what's new", or wants a quick health snapshot without running a full lint.

Wiki Status

Purpose: Report a quick, read-only snapshot of the wiki's current state, without the semantic review a lint pass does.

Trigger: User asks for wiki statistics, "what's new", or a quick health snapshot.

Before the first wikitool call: instructions/session-setup.md - step 2's lint is not on the budget's exemption allowlist and is counted like any other call, gitignored report or not (§ Scope there).

Hard rule: read-only with respect to wiki content. Never create, modify, or scaffold a page, never repair a finding, never publish. One file does get written: the report lint produces in step 2. That is not an exception being stretched - reports/ is gitignored and holds no wiki page (reports/CONTRACT.md), so the write leaves nothing behind that the wiki ships. If something looks wrong, point the user at wiki-lint or wiki-manage instead of fixing it here.

Steps

  1. Counts. Read kb/index.md - it is the catalog map: totals, one row per collection and per area. Small enough to read in full; the page tables live in the shards it links to.

  2. Structural snapshot.

    tools/wikitool lint
    

    No flags: prints the sections that found something - broken links, orphan pages, schema issues, uncovered raw files - and writes the full report to reports/Lint Report <date>.md, naming the path. One pass is enough; read that file for anything the summary left out rather than running lint a second time.

  3. Most-connected pages. The link-graph summary is a statistic, not a finding, so it is not in the printed summary: read the "Most-Linked Pages" section of the report file step 2 named. Useful for telling hub pages from candidates for a page of their own.

  4. Recent activity. Read the last few entries of kb/log.md.

  5. Summarize in chat. Counts by type, N orphan pages, N uncovered raw files, most-connected pages, and what changed recently. Leave the step-2 report as lint left it: its "Semantic Review" section stays empty and its findings are not carried into any page or into kb/log.md. That is wiki-lint's step 9, and it is what separates a snapshot from a pass.

Decision points

  • Findings worth acting on? Point at wiki-lint (repairs) or wiki-manage (content). Do not fix anything here.
  • Never publishes. Nothing under kb/ changed, and the step-2 report is gitignored, so there is nothing a commit could pick up.

wikitool commands used

lint (no flags).

Output

A short chat summary, plus a pointer to wiki-lint if deeper investigation is warranted.

Example trigger: "Give me a quick wiki status"