wiki-lint

Wiki Lint

Wiki のヘルスチェックを実行し、レポートを作成します。Wiki のコンテンツは変更しません。

---

Config Discovery

すべての呼び出しはここから始まります。 Wiki のルートは、wiki-config.md があるディレクトリです。スキルは実行時にルートを特定します。このスキルが検査するページは、wiki-schema.md の構造に照らしてチェックされます。両方のファイルが必要です。

1. スコープを特定する：ファイルシステムのスコープルート、つまりファイルシステムツールがアクセスできる最上位ディレクトリを特定します。

2. スコープを確認する — 必ず停止すること：スコープがドライブのルート（C:\、D:\、/）、OS のルート、またはユーザーのホームディレクトリ（C:\Users\X、/home/X、/Users/X）の場合は、ただちに停止します。検索しないでください。wiki-config.md の場所を特定しようとしないでください。 手順 6 に進みます。

3. <available_skills> で wiki-config を確認する：利用可能かどうかを確認してください。これは以下の推奨事項に影響します。バンドルされた references/setup-help.md も利用できます。ユーザーが案内を必要としている場合や、行き詰まった場合は読み込んでください。

4. wiki-config.md を見つけて読み込む：再帰的に検索します（最初に見つかったものを使用、最大 5 階層）。見つかった場合は読み込みます（blacklist、index_excludes、ingested_folder、ingested_subdirs、log_format）。見つからない場合は、手順 6 に進みます。

5. wiki-schema.md を見つけて読み込む — 必須チェック：wiki-config.md と同じディレクトリに wiki-schema.md が存在し、YAML として解析できることを確認します。確実な判定（存在する／ない／形式が不正）が得られるまで、以下のワークフローに進まないでください。 その後：

   • 存在し、問題なく解析できる場合 → スキーマ（mandatory_fields、conditional_fields、enums）を読み込み、ワークフローに進みます。

   • 存在しない場合 → 停止します。先に進まないでください。デプロイしないでください。応答は手順 3 の <available_skills> に wiki-config が含まれているかどうかによって異なります。

     • wiki-config が利用可能な場合： 次のパターンどおりに出力します — "Wiki に wiki-schema.md がありません。/wiki-config を実行してデプロイし、セットアップを完了してください。完了するまで待機します。" そのターンを終了します。バンドル版のデプロイを提案しないでください。代替案を提示しないでください。wiki-config のガイド付きフローが、利用可能な場合の正しい手順です。

     • wiki-config が利用できない場合： バンドル版へのフォールバックを提案します — "Wiki に wiki-schema.md がなく、wiki-config スキルもインストールされていません。バンドルされたリファレンスからデフォルトをデプロイできますが、ガイド付きセットアップのために wiki-config をインストールすることをおすすめします。バンドル版のデフォルトをデプロイしますか？" 明示的な確認を待ちます。「OK」の場合は、references/wiki-schema.md からデプロイします。

   • 形式が不正な場合 → 停止します。同じ分岐に従います。

     • wiki-config が利用可能な場合： "wiki-schema.md の形式が不正です。/wiki-config を実行してください。カスタマイズを保持するガイド付きの修復フローが用意されています。ここで待機します。" そのターンを終了します。修復やバンドル版による上書きを試みないでください。

     • wiki-config が利用できない場合： 手動で修復する方法について、references/setup-help.md を参照するよう案内します。ユーザーがリセットを明示的に指示した場合（自動的なフォールバックとしてではなく）は、カスタマイズが上書きされることを警告し、明示的な確認を得てからデフォルトをデプロイします。

   同じ 2 分岐の手順は、手順 4 で wiki-config.md 自体の形式が不正だと判明した場合にも適用されます。wiki-config が利用可能な場合 → 停止し、/wiki-config を推奨してターンを終了します。利用できない場合 → setup-help.md に沿って手動で修復するよう案内します。

6. Config が見つからない場合：Wiki のルートパスをユーザーに尋ね、その場所を検索します（上限は 5 階層）。それでも何も見つからない場合、Wiki はまだありません。上記の「存在しない場合」の分岐に従います（/wiki-config を推奨し、利用できない場合はバンドル版のデプロイを提案します）。

---

Capability Requirements

このスキルには、ファイルシステムの読み取りアクセス（すべてのページをスキャンするため）と、archive/ への書き込みアクセス（lint レポートを保存するため）が必要です。読み取りアクセスが利用できない場合、このスキルは続行できません。---

Workflow

Config Discovery で、wiki-config.md と wiki-schema.md はすでにコンテキストに読み込まれています。再読み込みしないでください。両方が利用可能であることを前提に、ここから進めます。

ステップ 1 - ページ一覧を作成する

vault 内のすべての .md ファイルを再帰的に一覧表示します。blacklist 内のパスは完全に除外し、その中のコンテンツはスキャンしません。index_excludes（raw\、archive\、ingested\）内のパスは wiki ページとして扱う対象から除外しますが、リンク先の検証では読み取り可能なままにします。ライブ wiki ページが archive/ または ingested/ 内のファイルにリンクしている場合、そのリンクは実在するファイルに解決される必要があります。blacklist と index_excludes の両方の外にあるファイルから、対象ページセットを作成します。また、ブラックリスト対象のパス、raw\、archive\、ingested\ の外にある Markdown 以外のファイルも、孤立している可能性のあるバイナリアセットとして一覧表示します。

ステップ 2 - index.md を読む

index.md を読みます。すべての wikilink 参照とファイルパスを解析します。index.md に記載されているページと、その参照先パスのセットを作成します。

ステップ 3 - 壊れた wikilink をチェックする

対象となる各 wiki ページから、すべての [[wikilinks]] を抽出します。それぞれが実在するファイルに解決されるかを確認します。一致するファイルが見つからない場合、見つかったページ、壊れたリンクテキスト、明らかであれば修正案を付けて、壊れた wikilink として報告します。

また、raw/ 内を指すリンクを含む wiki ページも報告します。wiki-ingest がファイルを ingested/ に移動すると、raw/ ソースへのリンクは壊れます。これらは将来的に壊れる警告として報告します：「[[Page]] は raw/ にリンクしています。取り込み後に壊れます。取り込み完了後、ingested// に更新してください。」これらは現時点では壊れていませんが、確実に壊れるリンクです。

ステップ 4 - 孤立ページをチェックする

対象セット内の各ページについて、次を確認します。

• index.md に記載されているか？
• 対象セット内の別のページから wikilink で参照されているか？

どちらにも該当しない場合、孤立ページとして報告します。新しいページが意図的に孤立している場合もありますが、いずれにせよ報告し、判断は人間に委ねます。

ステップ 5 - 古い index エントリをチェックする

index.md に記載されている各ページについて、参照先ファイルが存在するか確認します。存在しない場合、古い index エントリとして報告します。

ステップ 5b - 長すぎる index エントリをチェックする

index.md の各エントリについて、1 行の説明（]]: と末尾の `path` の間のテキスト）の長さを測定します。150 文字を超える場合、長すぎる index エントリとして報告します（注意喚起）。index.md は各実行時にすべての運用スキルによって全文が読み込まれるため、説明が長いと実行ごとのコストが増加します。修正案：150 文字以内に簡潔にまとめます。

ステップ 6 - 定性的および構造的な確認

概念上の問題： Overview.md を読み、明らかな矛盾や古さがないか確認します。具体的な wiki ページと矛盾しているように見える主張や、大幅に古くなっていると思われるページを探します。これは定性的な確認にとどめ、コンテンツ全体のレビューは行いません。

つながりの不足： index.md の説明をスキャンし、互いにリンクしていないページの組み合わせで、重要な用語が重複していないか確認します。index の説明に複数の主要な概念が共通しているにもかかわらず、相互に wikilink がないページは、つながりが不足している候補です。意味のある重複がある組み合わせを報告し、根拠の薄いキーワードの偶然の一致は報告しません。これは簡易的なヒューリスティック確認です。ユーザーがつながりが実際にあると判断した場合、実際のリンク追加は wiki-integrate が行います。

ステップ 6b - ページタイトルとファイル名の em-dash をチェックする

ページのファイル名や title: フロントマター項目に含まれる em-dash（—）は、LLM の出力で繰り返し発生するアーティファクトです。これにより wikilink が解決できなくなり（[[Topic - Subtopic]] へのリンクは Topic — Subtopic.md という名前のファイルには解決されません）、意図した名前でページを検索できなくなり、vault の em-dash 規則にも違反します。

対象となる各ページについて：

1. ファイル名に — 文字が含まれていないか確認します
2. title: フロントマター項目を読み、— 文字が含まれていないか確認します

各該当箇所について、ファイルパス、見つかった場所（ファイル名／title 項目）、問題の文字列、修正案を添えて、em-dash 違反として報告します。修正案：— を -（スペース、ハイフン、スペース）に置き換えます。

Step 6c - 古くなったページを確認する

対象範囲内の各ページについて、次の条件を確認します。

日付フィールドの不足（エラー）： ページのフロントマターに date: も updated: もない場合は、日付フィールド不足エラーとして報告します。両方のフィールドがない場合、作成時に問題が発生したことを示します。ページがスキルによって書き込まれていないか、フロントマターの形式が不正です。

古くなったページ（軽度の警告）： ページに updated: フィールドがあり、その日付が今日から90日より前の場合は、古くなったページとして報告します。次のページはこの確認の対象外です。

• status: artefact、status: snapshot、status: archived - 定義上、変更されないページです
• page_type: reference - リファレンスページの内容はほぼ静的であり、更新頻度が低いことが想定されます

updated: フィールドがないページ（ただし date: はあるページ）は、何も報告せずにスキップします。updated: がないことはエラーではありません。

古くなったページごとに、パス、updated: の日付、最終更新からの日数を報告します。 日付フィールド不足エラーごとに、パスと不足しているフィールドを報告します。

Step 6d - スキーマ準拠チェック（プロビナンスフィールド）

対象範囲内の各ページについて、4つのプロビナンスフィールド（status:、description:、source:、reliability:）を検証します。検出項目は次の2種類です。

エラー（重大なフラグ）：

• source: があり、reliability: がない - source: はありますが、reliability: がありません。これらのフィールドは連動するため、片方だけがあるのは内部矛盾です。パスと該当するフィールドの組み合わせを添えて、スキーマエラーとして報告します。
• status: の値が無効 - status: はありますが、その値が有効な列挙値（active、stub、artefact、archived、snapshot）のいずれでもありません。パス、フィールド、見つかった無効な値、有効な値を添えて、スキーマエラーとして報告します。
• reliability: の値が無効 - reliability: はありますが、その値が有効な値（high、medium、low）のいずれでもありません。パス、フィールド、見つかった無効な値、有効な値を添えて、スキーマエラーとして報告します。
• page_type: の値が無効 - page_type: はありますが、その値が wiki-schema.md に記載された有効な列挙値の一覧にありません。パス、フィールド、見つかった無効な値、スキーマで定義された有効な値を添えて、スキーマエラーとして報告します。

軽度の警告（情報提供）：

• スキルが更新したページに status: または description: がない - ページに updated: があり（3b以降にスキルが書き込んだことを意味します）、page_type: が knowledge、research-note、survey のいずれかですが、status: または description: がありません。updated: のない古いページは、何も報告せずにスキップします。これらは3bより前のページであり、次回更新時にフィールドが追加されます。不足しているフィールドを添えて、プロビナンスフィールド不足として報告します。
• source: があるが ## Sources セクションがない - フロントマターに source: がある場合、取り込まれた情報の出所を示すため、本文に ## Sources セクションがあるべきです。セクションがなくても重大なエラーではありませんが、報告する価値があります。パスを添えて、Sources セクション不足として報告します。
• スキルが更新したページに page_type: がない - ページに updated: があり（スキルが書き込んだことを意味します）、page_type: がありません。updated: のないページは、何も報告せずにスキップします。これらはこの機能より前のページであり、次回更新時にフィールドが追加されます。パスを添えて、page_type 不足として報告します。

Step 6e - log.md のサイズを確認する

log.md 内の ## [ エントリー数を数えます。log.md は先頭に追加される形式で、crystallize と lint は実行のたびに全体を読み込むため、大きすぎるログは継続的なコンテキストコストになります。エントリー数が150を超える場合は、エントリー数としきい値（150）を添えて、ログ過大として報告します。lint は log.md を変更しません。修正するには wiki-crystallize を実行します。最も古いエントリーをアーカイブし、直近の50件を残すかどうかを確認します。

ステップ 7 - 孤立したバイナリアセットを確認する

ブラックリスト対象のパス、raw\、archive\、ingested\ の外にある各 Markdown 以外のファイルについて、対象範囲内のすべてのページを検索し、このファイル名への参照があるか確認します。参照が見つからない場合は、孤立したバイナリアセットとしてフラグを付けます。関連コンテンツと同じ場所に文脈上配置されているファイル（例：ドメインのサブフォルダーにある、そのドメインのページから参照される PDF）は孤立ファイルではありません。Wiki 内のどこにも参照がないファイルのみフラグを付けます。

ステップ 7a - ingested/ 内の孤立したソースを確認する

ingested/ 内のすべてのファイルには、それを参照する Wiki ページが少なくとも 1 つ必要です。ページ本文の Sources セクションに ingested/ パスを記載します。Wiki から参照されていないソースは処理済みですが、ナレッジグラフに痕跡が残っていません。

ingested/ 内の各ファイル（assets/ を含むすべてのサブディレクトリ）について、次の手順を実行します。

1. 対象範囲内のすべての Wiki ページを検索し、ファイルの相対パス（例：ingested/documentation/foo.md）を探します。ページ全体を確認します。## Sources セクション本文、changes: フロントマターのフィールド、その他パス参照が記載されている可能性のある箇所を確認してください。記載場所にかかわらず、一致するものはすべて有効な参照として扱います。
2. 一致するものが見つからない場合は、孤立したソースとしてフラグを付けます：「ingested/[subdir]/filename を参照する Wiki ページがありません」

参照のない ingested/assets/ 内のソースは想定される状態です（取り込み時に読み取れなかったためです）。警告ではなく、重要度の低い注記としてフラグを付け、新しい機能が利用可能になった場合に再度取り込みを試せるよう、ユーザーに知らせます。

ステップ 8 - lint レポートを作成する

[wiki-root]/archive/lint-YYYY-MM-DD.md を作成します。

---
title: Lint Report YYYY-MM-DD
date: YYYY-MM-DD
---

# Lint Report - YYYY-MM-DD

## Summary
- Broken wikilinks: N
- Future breakage warnings (raw/ links): N
- Orphan pages: N
- Stale index entries: N
- Over-length index entries: N
- Missing connections (candidates): N
- Em-dash violations (titles/filenames): N
- Missing date fields (errors): N
- Stale pages (updated: > 90 days): N
- Schema errors (invalid enum values, missing field pairs): N
- Missing provenance fields (skill-touched pages): N
- Missing page_type: (skill-touched pages): N
- Missing Sources sections: N
- Orphaned binary assets: N
- Orphaned sources in ingested/: N (+ N notes in assets/)
- Conceptual flags: N
- Log size: N entries (flagged if over 150)

## Broken Wikilinks
[page where found, broken link, suggested fix]

## Future Breakage Warnings
[page where found, raw/ link, suggested post-ingest destination]

## Orphan Pages
[page path, reason it may be orphaned]

## Stale Index Entries
[index entry, the path that no longer resolves]

## Over-length Index Entries
[index entry, current description length, suggested: tighten to 150 chars max]

## Missing Connections
[page pair, overlapping terms, suggested action: run wiki-integrate]

## Em-dash Violations
[file path, where found (filename / title field), suggested fix: replace — with ' - ']

## Missing Date Fields
[file path, which of date: / updated: are absent; likely indicates malformed frontmatter or non-skill creation]

## Stale Pages
[file path, updated: date, days since last touch; not flagged if status: artefact/snapshot/archived or page_type: reference]

## Schema Errors
[file path, field(s) affected, nature of error (invalid enum value / source: without reliability: / invalid page_type: value)]

## Missing Provenance Fields
[file path, which of status: / description: are absent; page has updated: and is a fact-establishing page_type]

## Missing page_type:
[file path, page has updated: but page_type: is absent; add page_type: using values from wiki-schema.md, or run wiki-integrate to infer and confirm]

## Missing Sources Sections
[file path, has source: in frontmatter but no ## Sources section in body]

## Orphaned Binary Assets
[file path, reason it has no wiki references]

## Orphaned Sources in ingested/
[file path, no wiki page references this source; consider re-ingesting or archiving]

## Notes: ingested/assets/
[file path, was unreadable at ingest time; re-attempt if capabilities have improved]

## Conceptual Flags
[page, nature of potential issue]

## Log Size
[log.md entry count; flagged if over 150 - run wiki-crystallize to archive the oldest entries, keeping the 50 most recent]

ステップ 9 - log.md の先頭に追加する

新しいエントリーを log.md の先頭、ヘッダー行の下、既存のすべてのエントリーの上に追加します。

## [YYYY-MM-DD] lint | Full wiki pass
Summary: N broken links, N orphans, N stale entries, N missing connections, N date-field errors, N stale pages, N schema errors, N missing provenance/page_type fields, N orphaned assets.
Report: archive/lint-YYYY-MM-DD.md

ステップ 10 - 検出結果を提示する

概要を報告します。自動修正の提案はしないでください。次の対応を提案します。

• 壊れた Wiki リンク -> 手動で修正するか、該当ページで wiki-integrate を実行します
• 将来的な破損の警告 -> 次回の取り込み実行後に、raw/ のリンクを ingested/ のパスに更新します
• 孤立したページ -> wiki-integrate を実行するか、非推奨の場合は archive/ に移動します
• 古いインデックス項目 -> index.md から削除するか、パスを更新します
• 長すぎるインデックス項目 -> 説明を最大 150 文字に短縮します
• 接続の不足 -> フラグが付いたページの組み合わせで wiki-integrate を実行します
• 全角ダッシュの違反 -> ファイル名を変更し（— を - に置き換え）、title: フィールドを更新します。古い名前を参照している Wiki リンクを検索し、更新します
• 日付フィールドの不足 -> ページを確認します。スキルによって作成されたページの場合、フロントマターの形式が正しくないため、手動で修正する必要があります
• 古いページ -> 確認して更新します。または、意図的に固定されている場合は status: artefact、snapshot、archived のいずれかを設定します
• スキーマエラー -> フロントマターを手動で修正します。source: がある場合は reliability: を追加し、status:、reliability:、page_type: の無効な列挙値を修正します
• プロベナンスフィールドの不足 -> ページで wiki-ingest または wiki-crystallize を再実行し、status: と description: を取り込みます。または、スキーマに従って手動で追加します
• page_type: の不足 -> wiki-schema.md の列挙値を使って、ページのフロントマターに page_type: を追加します。または、wiki-integrate を実行すると、タイプが推定されて確認されます
• Sources セクションの不足 -> ページ本文に ## Sources セクションを追加し、source: のパスを記載します
• 孤立したバイナリアセット -> 適切な場所に移動するか、不要であれば削除します
• ingested/ 内の孤立したソース -> ソースファイルを再取り込みします（raw/ に戻して wiki-ingest を実行します）。または、Wiki ページが作成されなかった理由を調査します
• ingested/assets/ 内の注記 -> 新しいツールや機能が利用可能であれば、再取り込みを試します
• ログの肥大化 -> wiki-crystallize を実行します。最新の 50 件を残し、最も古いログエントリーをアーカイブするかどうかを確認します

---

主なルール

1. Wiki ページは絶対に変更しないでください - archive/ にリンターレポートを書き込む場合を除き、読み取り専用です
2. ファイルは絶対に削除しないでください - フラグを付けるだけにし、判断は人間に委ねます
3. 文脈に沿って配置されたファイルにはフラグを付けないでください - そのファイルのドメイン内に Wiki への参照がある場合、孤立ファイルではありません
4. ブラックリストに登録されたパスは完全にスキップします - リンターはブラックリストに登録されたディレクトリ内のコンテンツをスキャンしません
5. index_excludes は Wiki ページではありませんが、有効なリンク先です - ページ一覧から除外されていても、archive/ と ingested/ はリンク解決のために読み取り可能です
6. レポートは Wiki のルートではなく、archive/ に保存します

---

クラウド同期されたボルト

クラウド同期サービスに保存されたボルトには、ローカルにダウンロードされていないファイルがあり、ゼロバイトのプレースホルダーとして表示される場合があります。ファイルの読み取り結果が予期せず空の場合は、同期の問題の可能性があることを示し、再試行する前にユーザーに確認してください。ゼロバイトのファイルを、正常に処理された空のファイルとして扱わないでください。