Agent Skills by ALSEL
Anthropic Claudeセキュリティ⭐ リポ 0品質スコア 50/100

wiki-lint

Obsidian wikiの健全性を監査・維持するスキルです。孤立ページの検出、矛盾の発見、古くなったコンテンツの特定、壊れたwikiリンクの修正など、ナレッジベースの全般的なメンテナンスを行いたいときに使用します。「wikiを整理して」「修正が必要な箇所は?」「ノートを監査して」「wikiの健全性チェック」といった指示でも起動します。

description の原文を見る

> Audit and maintain the health of the Obsidian wiki. Use this skill when the user wants to check their wiki for issues, find orphaned pages, detect contradictions, identify stale content, fix broken wikilinks, or perform general maintenance on their knowledge base. Also triggers on "clean up the wiki", "what needs fixing", "audit my notes", or "wiki health check".

SKILL.md 本文

Wiki Lint — ヘルスチェック

Obsidian ウィキのヘルスチェックを実行しています。ウィキの価値を時間とともに低下させる構造的問題を見つけて修正することが目標です。

スキャン前に: llm-wiki/SKILL.md の Retrieval Primitives テーブルに従ってください。ページ全体読み込みより frontmatter スコープのgrep とセクションアンカー読み込みを優先してください。大規模なボルトでは、ウィキをリントするためにすべてのページを無差別に読むことは、このフレームワークが避けるために構築されたものです。

開始する前に

  1. Config を解決するllm-wiki/SKILL.md の Config Resolution Protocol に従う (CWD を上へ歩いて .env~/.obsidian-wiki/config → プロンプトセットアップを探す)。これで OBSIDIAN_VAULT_PATH を取得します
  2. index.md を読んで、ページ全体のインベントリを確認
  3. log.md を読んで、最近のアクティビティコンテキストを確認

リントチェック

これらのチェックを順に実行します。途中で検出結果を報告してください。

1. 孤立したページ

受信ウィキリンクがゼロのページを検出します。これらは何にも接続されていないナレッジアイランドです。

チェック方法:

  • ボルト内のすべての .md ファイルをグロブ
  • 各ページに対して、[[page-name]] 参照をボルトの残り部分でグレップ
  • 受信リンクがゼロのページ (index.mdlog.md を除く) が孤立したページ

修正方法:

  • どの既存ページが孤立したページにリンクするべきかを特定
  • 適切なセクションにウィキリンクを追加

2. 壊れたウィキリンク

存在しないページを指す [[wikilinks]] を検出します。

チェック方法:

  • すべてのページで \[\[.*?\]\] をグレップ
  • リンクターゲットを抽出
  • 対応する .md ファイルが存在するかチェック

修正方法:

  • ターゲットの名前が変更されている場合、リンクを更新
  • ターゲットが存在すべき場合、それを作成
  • リンクが間違っている場合、削除または修正

3. 見出し (frontmatter) が足りない

すべてのページには以下が必要です: title、category、tags、sources、created、updated。

チェック方法:

  • 各ページ全体を読むのではなく、frontmatter ブロックをグレップ (ファイルの先頭の ^--- にスコープ)
  • 必須フィールドが足りないページをフラグ

修正方法:

  • 足りないフィールドを妥当なデフォルト値で追加

3a. 見出しサマリーが足りない (ソフト警告)

すべてのページは summary: frontmatter フィールドを持つ べき です — 1-2 文、≤200 文字。これは安価な検索 (例えば wiki-query のインデックスのみモード) が、ページ本体を開かないために読むものです。

チェック方法:

  • ボルト全体で frontmatter の ^summary: をグレップ
  • それがないページをフラグ、ただしエラーではなくソフト警告として — このフィールドの前のページは問題ありません。このチェックは新しい書き込みで ingest スキルがそれを埋めるよう促すために存在します
  • サマリーが 200 文字を超えるページもフラグ

修正方法:

  • ページを再 ingest するか、手動で短いサマリー (ページのコンテンツの 1-2 文) を書く

4. 古いコンテンツ

updated タイムスタンプが、そのソースと比較して古いページ。

チェック方法:

  • ページの updated タイムスタンプをソースファイルの修正時刻と比較
  • ソースがページの最後の更新後に修正されているページをフラグ

5. 矛盾

ページ間で競合する主張。

チェック方法:

  • これには関連ページの読み込みと主張の比較が必要
  • タグを共有するか、多くの相互参照があるページに焦点を当てる
  • 既存の認識された矛盾か、認識されていない矛盾かを示す可能性のある「however」「in contrast」「despite」などのフレーズを探す

修正方法:

  • 「Open Questions」セクションを追加して矛盾を記述
  • 両方のソースとそれらの主張を参照

6. インデックス一貫性

index.md がページの実際のインベントリと一致することを確認します。

チェック方法:

  • index.md にリストされているページを実際のディスク上のファイルと比較
  • index.md のサマリーがページコンテンツと一致していることを確認

7. 由来のドリフト

ページのコンテンツがどの程度推論されているか抽出されているかについて正直であるかをチェックします。llm-wiki の Provenance Markers セクションを参照してください。

チェック方法:

  • provenance: ブロックまたは ^[inferred]/^[ambiguous] マーカーを持つ各ページについて、文/箇条書きをカウントし、それぞれのマーカーで終わるもの
  • 概算分数を計算 (extractedinferredambiguous)
  • これらのしきい値を適用:
    • AMBIGUOUS > 15%: "speculation-heavy" としてフラグ — 7 個に 1 つの主張が本当に不確実であることも、ページがより厳しいソースが必要であるか synthesis/ に移動すべきであることを示唆しています
    • INFERRED > 40% で frontmatter に sources: がない場合: "unsourced synthesis" としてフラグ — ページが接続を作成していますが、引用できるものがありません
    • Hub ページ (受信ウィキリンク数上位 10) で INFERRED > 20%: "high-traffic page with questionable provenance" としてフラグ — hub ページのエラーはそれにリンクするすべてのページに伝播します
    • ドリフト: ページに provenance: frontmatter ブロックがある場合、任意のフィールドが再計算値から 0.20 以上の差がある場合にフラグ
  • スキップ provenance: frontmatter がなく、マーカーがないページ — 慣例により完全に抽出されたと見なされます

修正方法:

  • ambiguous-heavy の場合: ソースから再 ingest、不確実な主張を解決、または推論的コンテンツを synthesis/ ページに分割
  • unsourced synthesis の場合: frontmatter に sources: を追加するか、ページを synthesis として明確にラベル
  • INFERRED > 20% の hub ページの場合: 再 ingest を優先化 — ここのエラーは最も広い影響範囲があります
  • ドリフトの場合: provenance: frontmatter を再計算値に一致するよう更新

8. 断片化されたタグクラスタ

タグを共有するページが実際に互いにリンクされているかチェックします。タグはトピッククラスタを意味します。それらのページが互いに参照していない場合、クラスタは断片化されています — 一緒に織られるべきナレッジアイランド。

チェック方法:

  • ≥5 ページに表示される各タグについて:
    • n = このタグを持つページ数
    • actual_links = このタググループ内の任意の 2 ページ間のウィキリンク数 (両方向をチェック)
    • cohesion = actual_links / (n × (n−1) / 2)
  • cohesion < 0.15 で n ≥ 5 のタググループをフラグ

修正方法:

  • cross-linker スキルを断片化されたタグ用に実行 — 足りないリンクを検出して挿入します
  • タググループが大きい (n > 15) で依然として断片化されている場合、それをより具体的なサブタグに分割することを検討

9. 可視性タグの一貫性

visibility/ タグが正しく適用されており、重要な場所でサイレントに足りていないことを確認します。

チェック方法:

  • タグ付けされていない PII パターン: ページ本体を grep して、機密データを示すことが多いパターン — passwordapi_keysecrettokenssnemail:phone: の後に実際の値 (フィールド説明ではない) が続く行。ページが一致して visibility/pii または visibility/internal を欠いている場合、分類ミスの可能性がありますとしてフラグ
  • visibility/piisources: なし: visibility/pii でタグ付けされているページは常に sources: frontmatter フィールドを持つべき — 由来がない場合、分類を検証する方法はありません。sources: を欠いている visibility/pii ページをフラグ
  • 分類学の可視性タグ: visibility/ タグはシステムタグで、_meta/taxonomy.md に表示されては いけません。見つかった場合、設定ミスとしてフラグ — それらを含むページの 5 タグ制限に向かってカウントされます

修正方法:

  • タグ付けされていない PII パターンの場合: frontmatter タグに visibility/pii を追加 (またはチームコンテキストの場合は visibility/internal)
  • 足りない sources: の場合: 由来を追加するか、ユーザーにエスカレート — 自動入力しないでください
  • 分類学汚染の場合: _meta/taxonomy.md から visibility/ エントリを削除

10. その他の昇格候補

プロジェクト親和性を蓄積するのに十分な misc/ のページを検出します。

チェック方法:

  • $OBSIDIAN_VAULT_PATH/misc/*.md をグロブ
  • 各ページについて、affinity frontmatter フィールドを読む
  • 任意の 1 つのプロジェクトのスコアが ≥ 3 のページをフラグ

修正方法:

  • 親和性スコアが古く見える場合 (例えば、affinity: {} を持つ多くのウィキリンクがあるページ)、最初に cross-linker スキルを実行
  • 昇格させるには: ページを projects/<project-name>/references/ (または別の適切なカテゴリ) に移動、frontmatter の category を更新、promotion_status を削除、ボルトをバックリンクに grep してそれらを更新

12. 信頼度とライフサイクルスキーマ

信頼度 + ライフサイクル frontmatter スキーマを強制します (llm-wiki/SKILL.md、Confidence and Lifecycle セクションを参照)。

2 つのモード:

  • --check (デフォルト、読み取り専用) — エラーと警告を報告
  • --fix — ドリフトが検出されたとき (ルール 12e) のみ base_confidence を書き直す可能性があります。lifecycle を書き直すことはありません

ルール 12a — lifecycle enum 検証

チェック方法: すべてのページで frontmatter の ^lifecycle: をグレップ。{draft, reviewed, verified, disputed, archived} にない値をフラグ。

修正方法: n/a (人間のみがライフサイクル状態を設定すべき)

ルール 12b — base_confidence 範囲

チェック方法: すべてのページで frontmatter の ^base_confidence: をグレップ。[0.0, 1.0] 外の値、またはフィールドを完全に欠いているページをフラグ。

修正方法: n/a (間違った値はスキルが間違って計算したことを意味する — 手動修正のため浮き彫りにする)

ルール 12c — 古いページレポート (計算オーバーレイ)

古さは保存されません — これは読み取り時に計算されます: is_stale = (today − updated) > 90 days

チェック方法: 各ページについて、frontmatter から updated: を読み、is_stale を計算します。古い場合は lifecycle: もチェック。報告:

  • lifecycle: verified の古いページはより大きな注釈で (これらは最も危険 — 高信頼ページが間違っているかもしれません)
  • 他のすべての古いページを標準警告として

修正方法: --fixlifecycle を書き直し ません。古さは再 ingest が updated をバンプしたときに自動的にクリアされます。

ルール 12d — 置換完全性

チェック方法: superseded_by: "[[target]]" を持つ各ページについて:

  • ターゲットページが存在することを確認
  • ターゲットページ自体が archived でないことを確認 (円形または連鎖した置換なし)
  • サイクルがないことを確認 (A が B を置換し、B が A を置換)
  • lifecycle != archivedsuperseded_by が設定されている場合、警告 (矛盾した状態)

修正方法: n/a — 人間の解決のためにフラグ

ルール 12e — 信頼度ドリフト

チェック方法: base_confidence:sources: の両方を frontmatter に持つページについて、llm-wiki/SKILL.md の式を使用して base_confidence を再計算します。保存値が再計算値から 0.05 以上異なる場合、ドリフトとしてフラグ。

修正方法 (--fix のみ): base_confidence フィールドを再計算値で書き直します。これは frontmatter を自動的に相互作用させる 唯一のルール です。

マイグレーションタイムライン

フェーズ時期足りないフィールドの動作
フェーズ 1: ソフトローンチ初期 PR警告のみ — 任意のページで足りない base_confidence または lifecycle
フェーズ 2: 新ページが強制+2 週新しく作成されたページで足りないフィールドはエラー; 既存ページは updated が定期的なメンテナンス中にバンプされた場合も警告
フェーズ 3: 完全強制+6 週、バックフィル スクリプトが別の PR で出荷されることで制御すべてのページでエラー

出力追加

Wiki Health Report に追加:

### 信頼度/ライフサイクル問題 (N 件見つかり)
- `concepts/foo.md``lifecycle` フィール足りない (警告: フェーズ 1)
- `entities/bar.md``lifecycle: stalestate` は有効な enum 値ではない
- `concepts/scaling.md``base_confidence: 1.4` は範囲 [0.0, 1.0] の外
- `synthesis/old-analysis.md` — STALE (最後の更新 2025-10-01、182 日前) lifecycle=verified ⚠️ 高優先度
- `concepts/outdated.md` — STALE (最後の更新 2025-11-15、137 日前) lifecycle=draft
- `entities/tool-v1.md``superseded_by: [[entities/tool-v2]]` だが lifecycle=draft (archived が期待される)
- `concepts/drift-example.md` — base_confidence ドリフト: 保存=0.80、再計算=0.59 (差分=0.21)

LINT ログエントリに追加:

- [TIMESTAMP] LINT ... lifecycle_issues=N

13. 型付き関係の妥当性

relationships: frontmatter ブロックを検証します。relationships: ブロックを持たないページはスキップ — フィールドはオプション。

許可されたタイプ: extendsimplementscontradictsderived_fromusesreplacesrelated_to

チェック方法:

  • ボルト全体で frontmatter の ^relationships: をグレップ
  • relationships: ブロックを持つ各ページについて、その frontmatter を読む (ページ本体全体ではなく)
  • ブロック内の各エントリについて:
    1. タイプ検証 — 許可されたセットにない type: 値をフラグ
    2. 壊れたターゲットtarget: 文字列から [[]] を除去、正規化 (小文字、スペース→ハイフン、.md を除去)、ボルト内のそのパスに .md ファイルが存在するかチェック。未解決のターゲットをフラグ
    3. 自己参照 — 解決されたターゲットがページ自身のノード id と等しいエントリをフラグ

修正方法:

  • 無効なタイプ: 値を最も近い許可タイプに修正、またはタイプが曖昧な場合 related_to を使用
  • 壊れたターゲット: エントリを更新または削除; ターゲットページが存在すべき場合、最初にそれを作成
  • 自己参照: エントリを削除

出力追加:

### 型付き関係問題 (N 件見つかり)
- `concepts/foo.md` — relationships[1]: タイプ "contradication" は許可されたタイプではない ("contradicts" のことですか?)
- `concepts/bar.md` — relationships[0]: ターゲット "[[skills/nonexistent-skill]]" はボルト内のページに解決されない
- `entities/baz.md` — relationships[2]: 自己参照 (ターゲットはこのページ自身の id に解決)

LINT ログエントリに追加:

... relationship_issues=N

11. Synthesis ギャップ

ウィキが欠いている高値の synthesis 機会を特定 — 多くのページ間で共起するが synthesis/ ページで接続されていない概念ペア。

チェック方法:

  • synthesis/ 内のすべてのページをリスト — 各パッジが覆う概念ペアを収集 ([[wikilinks]] またはタイトルから)
  • concepts/entities/ から 10-15 個の頻繁にリンクされた概念をピック
  • 各ペアについて、両方にリンクするページをカウントするため高速グレップを実行:
    grep -rl "\[\[ConceptA\]\]" "$OBSIDIAN_VAULT_PATH" --include="*.md" > /tmp/a.txt
    grep -rl "\[\[ConceptB\]\]" "$OBSIDIAN_VAULT_PATH" --include="*.md" > /tmp/b.txt
    comm -12 <(sort /tmp/a.txt) <(sort /tmp/b.txt) | wc -l
    
  • 共起 ≥ 3 で既存の synthesis ページを持たないペアをフラグ

修正方法:

  • /wiki-synthesize を実行してトップギャップを自動的に発見・埋める

出力形式

構造化リストとして検出結果を報告:

## Wiki Health Report

### 孤立したページ (N 件見つかり)
- `concepts/foo.md` — 受信リンクなし

### 壊れたウィキリンク (N 件見つかり)
- `entities/bar.md:15` — [[nonexistent-page]] にリンク

### 見出しが足りない (N 件見つかり)
- `skills/baz.md` — 足りない: tags、sources

### 古いコンテンツ (N 件見つかり)
- `references/paper-x.md` — ソース修正 2024-03-10、ページ最後更新 2024-01-05

### 矛盾 (N 件見つかり)
- `concepts/scaling.md` は "X" と主張しているが `synthesis/efficiency.md` は "not X" と主張

### インデックス問題 (N 件見つかり)
- `concepts/new-page.md` はディスク上に存在しますが index.md にはない

### サマリーが足りない (N 件見つかり — ソフト)
- `concepts/foo.md``summary:` フィールドなし
- `entities/bar.md` — サマリーが 200 文字を超えている

### 由来問題 (N 件見つかり)
- `concepts/scaling.md` — AMBIGUOUS > 15%: 主張の 22% が曖昧 (ソース再設定または synthesis/ に移動)
- `entities/some-tool.md` — ドリフト: frontmatter は inferred=0.10、再計算=0.45
- `concepts/transformers.md` — hub ページ (受信リンク 31 件) で INFERRED=28%: ここのエラーは広く伝播
- `synthesis/speculation.md` — unsourced synthesis: `sources:` フィールドなし、55% 推論

### 断片化されたタグクラスタ (N 件見つかり)
- **#systems** — 7 ページ、cohesion=0.06 ⚠️ — このタグで cross-linker を実行
- **#databases** — 5 ページ、cohesion=0.10 ⚠️

### 可視性問題 (N 件見つかり)
- `entities/user-records.md``email:` 値パターンを含みますが `visibility/pii` タグなし
- `concepts/auth-flow.md``visibility/pii` でタグ付けされているが frontmatter `sources:` が足りない
- `_meta/taxonomy.md``visibility/internal` エントリを含む (システムタグは分類学にあってはならない)

### その他の昇格候補 (N 件見つかり)
misc/ 内のページで、1 つのプロジェクトに ≥ 3 接続があり、昇格の準備ができているもの:

| ページ | トッププロジェクト | 親和性スコア |
|---|---|---|
| `misc/web-martinfowler-articles-microservices.md` | `obsidian-wiki` | 4 |

### 型付き関係問題 (N 件見つかり)
- `concepts/foo.md` — relationships[1]: タイプ "contradication" は許可されたタイプではない
- `concepts/bar.md` — relationships[0]: ターゲット "[[skills/nonexistent]]" はページに解決されない

### Synthesis ギャップ (N 件見つかり)
頻繁に共起しますが synthesis ページがない概念ペア:

| ペア | 共起 | 提案アクション |
|---|---|---|
| [[Caching]] × [[Consistency]] | 5 ページ | `/wiki-synthesize` を実行 |
| [[Testing]] × [[Observability]] | 3 ページ | `/wiki-synthesize` を実行 |

リント後

log.md に追加:

- [TIMESTAMP] LINT issues_found=N orphans=X broken_links=Y stale=Z contradictions=W prov_issues=P missing_summary=S fragmented_clusters=F visibility_issues=V promotion_candidates=C synthesis_gaps=G relationship_issues=R

問題を自動的に修正するか、ユーザーに対処するものを決めさせることを申し出ます。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
ar9av
リポジトリ
ar9av/obsidian-wiki
ライセンス
MIT
最終更新
不明

Source: https://github.com/ar9av/obsidian-wiki / ライセンス: MIT

関連スキル

Anthropic Claudeセキュリティ⭐ リポ 8,981

secure-code-guardian

認証・認可の実装、ユーザー入力の保護、OWASP Top 10の脆弱性対策が必要な場合に使用します。bcrypt/argon2によるパスワードハッシング、パラメータ化ステートメントによるSQLインジェクション対策、CORS/CSPヘッダーの設定、Zodによる入力検証、JWTトークンの構築などのカスタムセキュリティ実装に対応します。認証、認可、入力検証、暗号化、OWASP Top 10対策、セッション管理、セキュリティ強化全般で活用できます。ただし、構築済みのOAuth/SSO統合や単独のセキュリティ監査が必要な場合は、より特化したスキルの検討をお勧めします。

by Jeffallan
汎用セキュリティ⭐ リポ 1,982

claude-authenticity

APIエンドポイントが本物のClaudeによって支えられているか(ラッパーやプロキシ、偽装ではないか)を、claude-verifyプロジェクトを模した9つの重み付きルールベースチェックで検証できます。また、Claudeの正体を上書きしているプロバイダーから注入されたシステムプロンプトも抽出します。完全に自己完結しており、httpx以外の追加パッケージは不要です。Claude APIキーまたはエンドポイントを検証したい場合、サードパーティのClaudeサービスが本物か確認したい場合、APIプロバイダーのClaude正当性を監査したい場合、複数モデルを並行してテストしたい場合、またはプロバイダーが注入したシステムプロンプトを特定したい場合に使用できます。

by LeoYeAI
Anthropic Claudeセキュリティ⭐ リポ 2,159

anth-security-basics

Anthropic Claude APIのセキュリティベストプラクティスを適用し、キー管理、入力値の検証、プロンプトインジェクション対策を実施します。APIキーの保護、Claudeに送信する前のユーザー入力検証、コンテンツセーフティガードレールの実装が必要な場合に活用できます。「anthropic security」「claude api key security」「secure anthropic」「prompt injection defense」といったフレーズでトリガーされます。

by jeremylongshore
汎用セキュリティ⭐ リポ 699

x-ray

x-ray.mdプレ監査レポートを生成します。概要、強化された脅威モデル(プロトコルタイプのプロファイリング、Gitの重み付け攻撃面分析、時間軸リスク分析、コンポーザビリティ依存関係マッピング)、不変条件、統合、ドキュメント品質、テスト分析、開発者・Gitの履歴をカバーしています。「x-ray」「audit readiness」「readiness report」「pre-audit report」「prep this protocol」「protocol prep」「summarize this protocol」のキーワードで実行されます。

by pashov
汎用セキュリティ⭐ リポ 677

semgrep

Semgrepスタティック分析スキャンを実行し、カスタム検出ルールを作成します。Semgrepでのコードスキャン、セキュリティ脆弱性の検出、カスタムYAMLルールの作成、または特定のバグパターンの検出が必要な場合に使用します。重要:ユーザーが「バグをスキャンしたい」「コード品質を確認したい」「脆弱性を見つけたい」「スタティック分析」「セキュリティlint」「コード監査」または「コーディング標準を適用したい」と尋ねた場合も、Semgrepという名称を明記していなくても、このスキルを使用してください。Semgrepは30以上の言語に対応したパターンベースのコードスキャンに最適なツールです。

by wimpysworld
汎用セキュリティ⭐ リポ 591

ghost-bits-cast-attack

Java「ゴーストビッツ」/キャストアタック プレイブック(Black Hat Asia 2026)。16ビット文字が8ビットバイトに暗黙的に縮小されるJavaサービスへの攻撃時に使用します。WAF/IDSを回避して、SQLインジェクション、デシリアライゼーション型RCE、ファイルアップロード(Webシェル)、パストトラバーサル、CRLF インジェクション、リクエストスマグリング、SMTPインジェクションを実行できます。Tomcat、Spring、Jetty、Undertow、Vert.x、Jackson、Fastjson、Apache Commons BCEL、Apache HttpClient、Angus Mail、JDK HttpServer、Lettuce、Jodd、XMLWriterに影響し、WAFバイパスにより多くの「パッチ済み」CVEを再度有効化します。

by yaklang
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: ar9av · ar9av/obsidian-wiki · ライセンス: MIT