lw-lint

name	lw-lint
description	Run structural and content-health checks on wiki/, audit outputs/ for promotion candidates, save a durable lint report to outputs/, update wiki/log.md, and surface prioritized follow-up actions. Usage: /lw-lint

LLM Wiki Lint

Run structural and content-risk health checks on wiki/, audit outputs/ for promotable knowledge, and save a durable report to outputs/.

Required reads

1. .llm-wiki/profile.json
2. Active profile markdown
3. wiki/index.md
4. wiki/log.md
5. wiki/SCHEMA.md when present

If wiki/index.md is missing, stop and ask the user to initialize or repair the workspace first.

Step-by-step procedure

1. Resolve workspace and active profile

Read .llm-wiki/profile.json and the active profile markdown. Keep in memory:

• wiki taxonomy
• authority rules
• profile-specific drift checks
• content-risk priorities

2. Read the index first

Read wiki/index.md and parse the listed slugs/paths. Use the index as the canonical navigation map for the lint pass.

Initialize result buckets:

• broken_wikilinks
• missing_anchors
• orphans
• index_omissions
• thin_pages
• duplicate_or_overlapping_pages
• content_risk_warnings
• profile_specific_warnings
• promotion_candidates
• stale_outputs

3. Run structural checks across wiki/

At minimum, check:

• broken wikilinks
• missing anchors
• orphan pages
• index omissions

Rules:

• treat these as hard structural findings
• report exact file paths and targets
• use wiki/ as the compiled root, not the workspace root

4. Run content-health checks

Check for:

• thin pages
• duplicate or overlapping pages
• stale contradiction notes
• unsupported claims that appear stronger than their sources justify
• pages relying too heavily on weak sources when the profile expects stronger ones

Rules:

• treat these as content-risk findings, not structural breakages
• preserve distinction between "broken" and "risky"

5. Run profile-specific checks

Use the active profile to decide what special drift audits matter. Examples may include:

• README vs config/reference drift
• flow vs edition drift
• legacy terminology drift
• customer-facing over-claim risk
• missing high-level comparison/query pages for repeated questions

If the profile defines no special checks, skip this section cleanly.

6. Audit outputs/ for promotion candidates

If outputs/ exists, inspect it for files that may contain durable knowledge not yet represented in wiki/.

Classify findings into:

• keep in outputs/ as non-canonical artifact
• promote into wiki/ during maintenance
• stale/redundant artifact

Rules:

• do not treat outputs/ as part of the normal query base
• do not auto-promote content during lint unless the user explicitly asked for fixes or a maintenance run that includes promotion
• prefer recommending promotion in the report; actual promotion should normally happen during reflection or an explicit maintenance pass

7. Write a durable lint report

Write outputs/YYYY-MM-DD-lw-lint-report.md. Include:

• summary counts
• hard structural findings
• content-risk warnings
• profile-specific warnings
• outputs audit findings:
  • artifacts that are clearly non-canonical and should remain in outputs/
  • markdown artifacts that contain durable knowledge and should be promoted into wiki/
  • stale or redundant artifacts that may be archived or deleted
• prioritized next actions

8. Update wiki navigation and log

• Add the lint report to wiki/index.md only if the workspace indexes outputs/reports there
• Append a log entry to wiki/log.md
• Use the workspace's normal log style when it has one

9. Print terminal summary

Return:

• hard structural counts
• content-risk counts
• promotion-candidate counts
• top-priority follow-up actions
• lint report path

Hard rules

• Separate structural failures from content-risk warnings.
• Use the active profile to decide which drift checks matter.
• Do not silently repair content during lint unless the user explicitly asked for fixes.
• Use exact file paths in findings whenever possible.
• Treat wiki/ as canonical and outputs/ as non-canonical.