/wiki-lint

Health-check the LLM Wiki for issues.

Usage: `/wiki-lint [<group>] [<subcmd|target>] [--fix]`

`$ARGUMENTS` is optional. With no arguments, the full suite (= the `all` group) runs; specifying a group or subcommand runs only that scope.

Usage: /wiki-lint [<group>] [<subcmd|target>] [--fix]

Examples:
  /wiki-lint                                        # full suite (all groups below + suggestions·promotion·demotion·staleness informational)
  /wiki-lint --fix                                  # full suite + each group's supported --fix in one pass
  /wiki-lint graph                                  # structure · orphans · clusters · raw-files · internal-refs in one pass
  /wiki-lint graph orphans --fix                    # single subcommand
  /wiki-lint graph gaps [--gap-type <slug>] [--top 5]   # gap diagnostic (informational in `all`)
  /wiki-lint hub schema                             # L2-2 hub frontmatter check
  /wiki-lint meta schema                            # meta-doc integrity · drift · language convention
  /wiki-lint overview open-source-ai-definition     # single cluster overview
  /wiki-lint overview aggregate                     # L2-4 overview.md
  /wiki-lint overview <target> --fix                # diagnosis + Claude rewrite instruction
  /wiki-lint contradiction <theme>                  # single theme MD diagnosis
  /wiki-lint contradiction theme                    # _contradictions_themes.json ↔ MD consistency
  /wiki-lint contradiction theme --fix              # JSON regeneration — emits Claude instruction block
  /wiki-lint source                                 # all-source new-schema diagnosis (Phase 2)
  /wiki-lint source <slug>                          # single-source new-schema Rubric diagnosis
  /wiki-lint overview --fix --yes                   # bypass confirmation prompt (use only after prior review)
  /wiki-lint contradiction --fix --yes              # bypass confirmation prompt

`--yes` (`-y`) bypasses the file create/delete confirmation prompt of `overview --fix`·`contradiction --fix`. In a non-TTY environment (Claude Code Bash·CI) the prompt cannot be answered, so the command aborts; add `--yes` only when you intend deliberate execution after review. `--yes` itself has no effect in other groups (`graph`·`hub`, etc.) — those perform only content edits and auto-enrichment, with no file creation or deletion.

Traversal Pattern

A verify-and-fix cycle. The Copy Editor is the lead; when `--fix` is set, the Columnist and Desk chain is entered.

| Mode | Cycle | Owner | |---|---|---| | **Check only** (no `--fix`) | VERIFY | Copy Editor (`tools/lint.py`) — exit code + lint-report.md | | **`overview/contradiction <target> --fix`** (L2-3·L2-4 rewrite) | VERIFY → ADAPT → APPLY → VERIFY | Copy Editor (VERIFY₁) → Columnist (ADAPT) → Copy Editor → Desk (VERIFY₂) → Editor-in-Chief gate | | **Other group `--fix`** (`graph`·`hub`, etc. — auto-enrich/correct) | (deterministic) | Copy Editor (formattable-area auto-fix only; no meaning-affecting changes) |

In this chain, `--yes` is **Claude's explicit opt-in to executing the chain** — deferring to `lint-report.md` violates the opt-in intent (`.claude/hooks/lint-chain-guard.sh` enforces this at the system level).

Sub-procedure (Owned by This Folder)

Two sub-procedures are the sole responsibility of this command:

• [`## Sub-procedure: Contradiction Theme Mapping Procedure`](#sub-procedure-contradiction-theme-mapping-procedure) — the raw DB → JSON mapping procedure for `contradiction theme --fix`
• [`## Sub-procedure: Conflict Axis Sync Rule`](#sub-procedure-conflict-axis-sync-rule) — the 4-tier bottom-up synchronization rule for `contradiction --fix`

The [A]–[G] code definitions and the diagnostic output format for the Cluster Health Diagnostic are not a separate sub-procedure; the per-code definitions · action guides are SoT in `tools/_lint/graph_clusters.py` (module docstring + report output), while the `graph clusters` row of the [`## Group Structure`](#group-structure) table and the `Cluster health` item under [`## Check Items`](#check-items-full-suite-layout) record only the codes' pass/fail posture.

Chain Execution Obligation

Chain Markers (Single SoT)

If any one of the following markers appears in lint stdout, a downstream chain obligation arises:

• `CHAIN-REQUIRED`
• `STALE --fix chain`
• `⚡ ACTION REQUIRED`
• `Claude rewrite instruction block`

These 4 markers are the single SoT for chain detection — both the emit sites in `tools/lint.py` and the grep patterns in [`.claude/hooks/lint-chain-guard.sh`](../hooks/lint-chain-guard.sh) reference this list.

Claude Behavior Protocol

`--yes` or `-y` is **Claude's explicit opt-in to executing the chain**. On marker detection, perform the downstream chain immediately — deferring it to "Remaining work" in `lint-report.md` violates the opt-in intent. Task size is not grounds for non-execution (even large-scale work like classifying 250 claims across Phase 1·2 is intended at the moment `--yes` is given).

**No requesting user approval (limited to the `--yes` context)**: Only in calls that include the `--yes` token, before entering the chain, do not produce wait-for-user-input utterances such as "I request the wiki operator's approval," "please instruct me to proceed to the next step," or "awaiting the chain-entry gate" — because the `--yes` token is itself the chain-entry approval. A `--fix`-only call without `--yes` is the exact opposite — it corresponds to the "only correct case for non-execution" above, where waiting for user confirmation is the SoT-correct answer. The human-reviewer gate is not a chain-**entry** gate but fires at chain-**mid** triggers — see [`CLAUDE.md` "Human Reviewer Gate"](../../CLAUDE.md#human-reviewer-gate) as the single SoT for which those are.

**The only correct case for non-execution**: the user ran lint without `--yes` = explicitly declining chain opt-in. Only then do you write the rewrite block into the report an