tag-taxonomy

Tag Taxonomy — Controlled Vocabulary for Wiki Tags

You are enforcing consistent tagging across the wiki by normalizing tags to a controlled vocabulary.

Before You Start

1. Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATH
2. Read $OBSIDIAN_VAULT_PATH/_meta/taxonomy.md — this is the canonical tag list
3. Read index.md to understand the wiki's scope

The Taxonomy File

The canonical tag vocabulary lives at $OBSIDIAN_VAULT_PATH/_meta/taxonomy.md. It defines:

• Canonical tags — the tags that should be used
• Aliases — common alternatives that should be mapped to the canonical form
• Rules — max 5 tags per page, lowercase/hyphenated, prefer broad over narrow
• Migration guide — specific renames for known inconsistencies

Always read this file before tagging. It's the source of truth.

Reserved System Tags

visibility/ is a reserved tag group with special rules. These tags are not domain or type tags and are managed separately from the taxonomy vocabulary:

Rules for visibility/ tags:

• They do not count toward the 5-tag limit
• Only one visibility/ tag per page
• Omit entirely when content is clearly public — no tag needed
• Never add visibility/internal just because content is technical; use it only for genuinely team-restricted knowledge
• When running a tag audit, report visibility/ tag usage separately — do not flag them as unknown or non-canonical

When normalizing tags, leave visibility/ tags untouched — they are not subject to alias mapping.

Mode 1: Tag Audit

When the user wants to see the current state of tags:

Step 1: Scan all pages

Glob: $VAULT_PATH/**/*.md (excluding _archives/, .obsidian/, _meta/)
Extract: tags field from YAML frontmatter

Step 2: Build a tag frequency table

For each tag found, count how many pages use it. Flag:

• Unknown tags — not in the taxonomy's canonical list
• Alias tags — using an alias instead of the canonical form (e.g., nextjs instead of react)
• Over-tagged pages — pages with more than 5 tags
• Untagged pages — pages with no tags or empty tags field

Step 3: Report

## Tag Audit Report
 
### Summary

Mode 2: Tag Normalization

When the user wants to fix the tags:

Step 1: Run audit (above)

Step 2: Apply fixes

For each page with non-canonical tags:

1. Read the page
2. Replace alias tags with their canonical form from the taxonomy
3. If page has > 5 tags, suggest which to drop (keep the most specific/relevant ones)
4. Write the updated frontmatter

Example:

Step 3: Handle unknowns

For tags that aren't in the taxonomy and aren't aliases:

• If the tag is used on 2+ pages, suggest adding it to the taxonomy
• If the tag is used on 1 page, suggest replacing it with the closest canonical tag
• Ask the user before making changes to unknown tags

Step 4: Update taxonomy

If new canonical tags were agreed upon, append them to _meta/taxonomy.md in the correct section.

Mode 3: Tagging a New Page

When you're creating a wiki page and need to choose tags:

1. Read _meta/taxonomy.md
2. Select up to 5 tags that best describe the page:
   • 1-2 domain tags (what subject area)
   • 1 type tag (what kind of thing)
   • 0-1 project tags (if project-specific)
   • 0-1 additional descriptive tags
3. Use only canonical tags — never aliases
4. If no existing tag fits, check if it's worth adding to the taxonomy

Mode 4: Adding a New Tag

When the user wants to add a tag to the vocabulary:

1. Check if an existing tag already covers the concept (suggest it if so)
2. If genuinely new, determine which section it belongs in (Domain, Type, Project)
3. Add it to _meta/taxonomy.md with:
   • The canonical tag name
   • What it's used for
   • Any aliases to redirect

After Any Tag Operation

Append to log.md:

Or for normalization:

hot.md — Read $OBSIDIAN_VAULT_PATH/hot.md (create from the template in wiki-ingest if missing). Update Recent Activity with a one-line summary — e.g. "Tag audit: normalized 14 tags across 28 pages; 2 new canonical tags added." Keep the last 3 operations. Update updated timestamp.

QMD Refresh After Vault Writes

QMD is a search index, not the source of truth. If $QMD_WIKI_COLLECTION is empty or unset, skip this step. Run it only after this skill has written or rewritten vault markdown. If QMD refresh fails, do not roll back the vault changes; report the QMD status separately.

Use $QMD_CLI if set; otherwise use qmd.

If the output says vectors are needed or embeddings may be stale, run:

Verify the collection with either:

or, when a specific page path is known:

Record one of:

• QMD refreshed: update + embed + verified
• QMD refreshed: update only + verified
• QMD skipped: QMD_WIKI_COLLECTION unset
• QMD skipped: qmd CLI unavailable
• QMD failed: <short error summary>