agentleFS
Ar9avAr9av/obsidian-wiki/skills/tag-taxonomy/SKILL.md

tag-taxonomy

Skill3.7k starsChanged 9 days agoMITView on GitHub

Apply and maintain the wiki's controlled tag vocabulary. Use for choosing, normalizing, auditing, or extending tags when creating or updating wiki pages; consult the taxonomy before assigning tags.

  • Reads credentials

3 other projects use a version of this, 3 of them edited.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about Ar9av/obsidian-wiki

The biggest 5 of 27 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 27

Talked about on GitHub and Bluesky (27 times).

On GitHub · 25

20 more on GitHub

On Bluesky · 2

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. 13 are common, 2 are distinctive, and 10 are very specific to this project.

  • 13

    Common

    Most of the 3 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read $OBSIDIAN_VAULT_PATH/_meta/taxonomy.md — this is the canonical tag list

    line 14
  2. Very specific:

    Read index.md to understand the wiki's scope

    line 15
  3. Very specific:

    Only one visibility/ tag per page

    line 40
  4. Very specific:

    Never add visibility/internal just because content is technical.

    line 42
  5. Very specific:

    When running a tag audit, report visibility/ tag usage separately — do not flag them as unknown or non-canonical

    line 43
  6. Very specific:

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

    line 45
  7. Common:

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

    line 49
  8. Common:

    When the user wants to fix the tags:

    line 105
  9. Common:

    If page has > 5 tags, suggest which to drop (keep the most specific/relevant ones)

    line 115
  10. Common:

    Write the updated frontmatter

    line 116
  11. Common:

    If the tag is used on 2+ pages, suggest adding it to the taxonomy

    line 132
  12. Common:

    If the tag is used on 1 page, suggest replacing it with the closest canonical tag

    line 133
  13. Common:

    Ask the user before making changes to unknown tags

    line 134
  14. Very specific:

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

    line 138
  15. Common:

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

    line 142
  16. Common:

    Use only canonical tags — never aliases

    line 150
  17. Common:

    If no existing tag fits, check if it's worth adding to the taxonomy

    line 151
  18. Common:

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

    line 155
  19. Common:

    Check if an existing tag already covers the concept (suggest it if so)

    line 157
  20. Common:

    If genuinely new, determine which section it belongs in (Domain, Type, Project)

    line 158
  21. Very specific:

    Add it to _meta/taxonomy.md with:

    line 159
  22. Very specific:

    Never hand-edit index.md, log.md, or hot.md — the command takes the lock that keeps a parallel writer from dropping your update.

    line 179
  23. Very specific:

    Use $QMD_CLI if set; otherwise use qmd.

    line 187
  24. Distinctive:

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

    line 193
  25. Distinctive:

    Verify the collection with either:

    line 199

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

TagPurpose
visibility/publicExplicitly public — shown in all modes (same as no tag)
visibility/internalTeam-only — excluded in filtered query/export mode
visibility/piiSensitive data — excluded in filtered query/export mode

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

- Total unique tags: 47
- Canonical tags used: 32
- Non-canonical tags found: 15
- Pages over tag limit (5): 3
- Untagged pages: 2

### Non-Canonical Tags Found

| Current Tag | → Canonical | Pages Affected |
| ----------- | ----------- | -------------- |
| `nextjs`    | `react`     | 4              |
| `next-js`   | `react`     | 2              |
| `robotics`  | `ml`        | 1              |
| `windows98` | `retro`     | 3              |

### Unknown Tags (not in taxonomy)

| Tag          | Pages | Recommendation                   |
| ------------ | ----- | -------------------------------- |
| `flutter`    | 1     | Add to taxonomy under Frameworks |
| `kubernetes` | 2     | Add to taxonomy under DevOps     |

### Over-Tagged Pages

| Page                   | Tag Count | Tags                 |
| ---------------------- | --------- | -------------------- |
| `entities/jane-doe.md` | 8         | ai, ml, founder, ... |

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:

# Before
tags: [nextjs, ai, ml-engineer, windows98, creative-coding, game, 8-bit, portfolio]

# After
tags: [react, ai, ml, retro, generative-art]

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

One locked call updates the log, the index (tags appear in index entries), and the hot cache:

# audit
obsidian-wiki memory sync TAG_AUDIT \
  tags_normalized=<N> unknown_tags=<M> pages_modified=<P> \
  --takeaways "Tag audit: normalized 14 tags across 28 pages; 2 new canonical tags added."

# normalization
obsidian-wiki memory sync TAG_NORMALIZE \
  tags_renamed=<N> pages_modified=<M> new_tags_added=<P>

Never hand-edit index.md, log.md, or hot.md — the command takes the lock that keeps a parallel writer from dropping your update.

See skills/llm-wiki/references/MEMORY.md for the full procedure.

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.

${QMD_CLI:-qmd} update

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

${QMD_CLI:-qmd} embed

Verify the collection with either:

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

or, when a specific page path is known:

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

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>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.