tag-taxonomy
Obsidian Wiki 全体でタグを統制語彙に基づいて統一管理するスキルです。「タグを直して」「タグを整理して」「タグ監査」「どのタグを使えばいい」などのユーザー発言や、Wiki ページの作成・更新時に適切なタグを選ぶ必要がある場面でトリガーされます。タグ規則の確認、タグ体系への新規タグ追加、Wiki ページへのタグ付与を行う際は、必ずこのスキルのタクソノミーファイルを参照してください。
description の原文を見る
> Enforce consistent tagging across the Obsidian wiki using a controlled vocabulary. Use this skill when the user says "fix my tags", "normalize tags", "clean up tags", "tag audit", "what tags should I use", "tag taxonomy", or whenever you're creating or updating wiki pages and need to choose the right tags. Also trigger when the user asks about tag conventions, wants to add a new tag to the taxonomy, or says "my tags are a mess". Always consult this skill's taxonomy file before assigning tags to any wiki page.
SKILL.md 本文
タグ分類法 — Wiki タグ用の統制された語彙
wiki全体でタグの一貫性を強制し、統制された語彙にタグを正規化しています。
始める前に
- 設定を解決する —
llm-wiki/SKILL.mdの設定解決プロトコルに従う(CWD から.env→~/.obsidian-wiki/config→ プロンプト設定をたどる)。これによりOBSIDIAN_VAULT_PATHが得られます $OBSIDIAN_VAULT_PATH/_meta/taxonomy.mdを読む — これが正規のタグリストですindex.mdを読む — wikiのスコープを理解します
分類ファイル
正規のタグ語彙は $OBSIDIAN_VAULT_PATH/_meta/taxonomy.md に存在します。以下を定義します:
- 正規タグ — 使用すべきタグ
- エイリアス — 正規形にマップされるべき一般的な代替案
- ルール — ページあたり最大5タグ、小文字/ハイフン区切り、狭いものより広いものを優先
- 移行ガイド — 既知の不整合のための具体的な名前変更
タグ付けする前に必ずこのファイルを読んでください。 これが真実の源です。
予約されたシステムタグ
visibility/ は特別なルールを持つ予約タググループです。これらのタグはドメインやタイプタグではなく、分類法語彙とは別に管理されます:
| タグ | 目的 |
|---|---|
visibility/public | 明示的に公開 — すべてのモードで表示(タグなしと同じ) |
visibility/internal | チームのみ — フィルター済みクエリ/エクスポートモードで除外 |
visibility/pii | 機密データ — フィルター済みクエリ/エクスポートモードで除外 |
visibility/ タグのルール:
- 5タグ制限にカウントされない
- ページあたり最大1つの
visibility/タグのみ - コンテンツが明らかに公開の場合は完全に省略 — タグ不要
- 単にコンテンツが技術的だという理由で
visibility/internalを追加しない;本当にチーム制限の知識の場合のみ使用 - タグ監査を実行する際、
visibility/タグ使用を別途報告 — 不明または非正規タグとしてフラグを立てないでください
タグを正規化する際は、visibility/ タグはそのまま — エイリアスマッピングの対象ではありません。
モード1:タグ監査
ユーザーがタグの現在の状態を確認したいとき:
ステップ1:すべてのページをスキャン
Glob: $VAULT_PATH/**/*.md (_archives/, .obsidian/, _meta/ を除く)
抽出:YAML frontmatterからtags フィールド
ステップ2:タグ頻度テーブルを作成
見つかった各タグについて、それを使用しているページ数をカウントします。フラグを立てます:
- 不明なタグ — 分類法の正規リストにない
- エイリアスタグ — 正規形の代わりにエイリアスを使用(例:
reactの代わりにnextjs) - 過度にタグ付けされたページ — 5タグ以上あるページ
- タグなしページ — タグがないか空のタグフィールド
ステップ3:報告
## タグ監査レポート
### サマリー
- 合計ユニークタグ数:47
- 使用された正規タグ:32
- 見つかった非正規タグ:15
- タグ制限を超えるページ(5):3
- タグなしページ:2
### 見つかった非正規タグ
| 現在のタグ | → 正規タグ | 影響を受けるページ |
| ----------- | ----------- | -------------- |
| `nextjs` | `react` | 4 |
| `next-js` | `react` | 2 |
| `robotics` | `ml` | 1 |
| `windows98` | `retro` | 3 |
### 不明なタグ(分類法にない)
| タグ | ページ | 推奨事項 |
| ------------ | ----- | -------------------------------- |
| `flutter` | 1 | フレームワークの下に分類法に追加 |
| `kubernetes` | 2 | DevOpsの下に分類法に追加 |
### タグ制限を超えるページ
| ページ | タグ数 | タグ |
| ---------------------- | --------- | -------------------- |
| `entities/jane-doe.md` | 8 | ai, ml, founder, ... |
モード2:タグ正規化
ユーザーがタグを修正したいとき:
ステップ1:監査を実行(上記)
ステップ2:修正を適用
非正規タグがあるページごと:
- ページを読む
- エイリアスタグを分類法の正規形で置き換える
- ページに5タグ以上ある場合、どのタグを削除するかを提案(最も具体的/関連性の高いものを保持)
- 更新された frontmatter を書き込む
例:
# 修正前
tags: [nextjs, ai, ml-engineer, windows98, creative-coding, game, 8-bit, portfolio]
# 修正後
tags: [react, ai, ml, retro, generative-art]
ステップ3:不明なものを処理
分類法にないタグで、エイリアスでもないもの:
- タグが2ページ以上で使用されている場合、分類法に追加することを提案
- タグが1ページでのみ使用されている場合、最も近い正規タグで置き換えることを提案
- 不明なタグへの変更を行う前に、ユーザーに確認を取る
ステップ4:分類法を更新
新しい正規タグが合意された場合、_meta/taxonomy.md の正しいセクションに追加します。
モード3:新しいページへのタグ付け
wiki ページを作成し、タグを選択する必要があるとき:
_meta/taxonomy.mdを読む- ページを最適に説明する最大5つのタグを選択:
- 1~2 ドメインタグ(どの主題分野か)
- 1 タイプタグ(何の種類か)
- 0~1 プロジェクトタグ(プロジェクト固有の場合)
- 0~1 追加の説明タグ
- 正規タグのみを使用 — エイリアスは使用しない
- 既存のタグが当てはまらない場合、分類法に追加する価値があるかを確認
モード4:新しいタグを追加
ユーザーが語彙にタグを追加したいとき:
- 既存のタグがすでにコンセプトをカバーしているかを確認(該当する場合は提案)
- 本当に新しい場合、どのセクション(ドメイン、タイプ、プロジェクト)に属するかを判断
_meta/taxonomy.mdに以下を含めて追加:- 正規タグ名
- 何に使用されるか
- リダイレクトするエイリアス
タグ操作後
log.md に追加:
- [TIMESTAMP] TAG_AUDIT tags_normalized=N unknown_tags=M pages_modified=P
または正規化の場合:
- [TIMESTAMP] TAG_NORMALIZE tags_renamed=N pages_modified=M new_tags_added=P
hot.md — $OBSIDIAN_VAULT_PATH/hot.md を読む(wiki-ingest のテンプレートから不足している場合は作成)。最近のアクティビティを1行の要約で更新 — 例:「タグ監査:28ページ全体で14タグを正規化;2つの新しい正規タグを追加。」最後の3つの操作を保持します。updated タイムスタンプを更新します。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- ar9av
- リポジトリ
- ar9av/obsidian-wiki
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/ar9av/obsidian-wiki / ライセンス: MIT
関連スキル
secure-code-guardian
認証・認可の実装、ユーザー入力の保護、OWASP Top 10の脆弱性対策が必要な場合に使用します。bcrypt/argon2によるパスワードハッシング、パラメータ化ステートメントによるSQLインジェクション対策、CORS/CSPヘッダーの設定、Zodによる入力検証、JWTトークンの構築などのカスタムセキュリティ実装に対応します。認証、認可、入力検証、暗号化、OWASP Top 10対策、セッション管理、セキュリティ強化全般で活用できます。ただし、構築済みのOAuth/SSO統合や単独のセキュリティ監査が必要な場合は、より特化したスキルの検討をお勧めします。
claude-authenticity
APIエンドポイントが本物のClaudeによって支えられているか(ラッパーやプロキシ、偽装ではないか)を、claude-verifyプロジェクトを模した9つの重み付きルールベースチェックで検証できます。また、Claudeの正体を上書きしているプロバイダーから注入されたシステムプロンプトも抽出します。完全に自己完結しており、httpx以外の追加パッケージは不要です。Claude APIキーまたはエンドポイントを検証したい場合、サードパーティのClaudeサービスが本物か確認したい場合、APIプロバイダーのClaude正当性を監査したい場合、複数モデルを並行してテストしたい場合、またはプロバイダーが注入したシステムプロンプトを特定したい場合に使用できます。
anth-security-basics
Anthropic Claude APIのセキュリティベストプラクティスを適用し、キー管理、入力値の検証、プロンプトインジェクション対策を実施します。APIキーの保護、Claudeに送信する前のユーザー入力検証、コンテンツセーフティガードレールの実装が必要な場合に活用できます。「anthropic security」「claude api key security」「secure anthropic」「prompt injection defense」といったフレーズでトリガーされます。
x-ray
x-ray.mdプレ監査レポートを生成します。概要、強化された脅威モデル(プロトコルタイプのプロファイリング、Gitの重み付け攻撃面分析、時間軸リスク分析、コンポーザビリティ依存関係マッピング)、不変条件、統合、ドキュメント品質、テスト分析、開発者・Gitの履歴をカバーしています。「x-ray」「audit readiness」「readiness report」「pre-audit report」「prep this protocol」「protocol prep」「summarize this protocol」のキーワードで実行されます。
semgrep
Semgrepスタティック分析スキャンを実行し、カスタム検出ルールを作成します。Semgrepでのコードスキャン、セキュリティ脆弱性の検出、カスタムYAMLルールの作成、または特定のバグパターンの検出が必要な場合に使用します。重要:ユーザーが「バグをスキャンしたい」「コード品質を確認したい」「脆弱性を見つけたい」「スタティック分析」「セキュリティlint」「コード監査」または「コーディング標準を適用したい」と尋ねた場合も、Semgrepという名称を明記していなくても、このスキルを使用してください。Semgrepは30以上の言語に対応したパターンベースのコードスキャンに最適なツールです。
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を再度有効化します。