tag-taxonomy
Skill21 starsChanged 4 months agoMITView on GitHub
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.
- Reads credentials
We split this skill into the rules it gives an agent
21 rules. About 0 are common, 13 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Read $OBSIDIAN_VAULT_PATH/_meta/taxonomy.md — this is the canonical tag list
- Very specific: line 20
Read index.md to understand the wiki's scope
- Very specific: line 45
Only one visibility/ tag per page
- Very specific: line 47
Never add visibility/internal just because content is technical.
- Very specific: line 48
When running a tag audit, report visibility/ tag usage separately — do not flag them as unknown or non-canonical
- Very specific: line 50
When normalizing tags, leave visibility/ tags untouched — they are not subject to alias mapping.
- Distinctive: line 54
When the user wants to see the current state of tags:
- Distinctive: line 110
When the user wants to fix the tags:
- Distinctive: line 120
If page has > 5 tags, suggest which to drop (keep the most specific/relevant ones)
- Distinctive: line 121
Write the updated frontmatter
- Distinctive: line 137
If the tag is used on 2+ pages, suggest adding it to the taxonomy
- Distinctive: line 138
If the tag is used on 1 page, suggest replacing it with the closest canonical tag
- Distinctive: line 139
Ask the user before making changes to unknown tags
- Very specific: line 143
If new canonical tags were agreed upon, append them to _meta/taxonomy.md in the correct section.
- Distinctive: line 147
When you're creating a wiki page and need to choose tags:
- Distinctive: line 155
Use only canonical tags — never aliases
- Distinctive: line 156
If no existing tag fits, check if it's worth adding to the taxonomy
- Distinctive: line 160
When the user wants to add a tag to the vocabulary:
- Distinctive: line 162
Check if an existing tag already covers the concept (suggest it if so)
- Distinctive: line 163
If genuinely new, determine which section it belongs in (Domain, Type, Project)
- Very specific: line 164
Add it to _meta/taxonomy.md with:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
- Resolve the vault path (precedence, highest first): the
OBSIDIAN_VAULT_PATHenvironment variable if set, else a.envin the current working directory (vault-scoped), else~/.obsidian-wiki/config(global default). - Read
$OBSIDIAN_VAULT_PATH/_meta/taxonomy.md— this is the canonical tag list - Read
index.mdto 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:
| Tag | Purpose |
visibility/public | Explicitly public — shown in all modes (same as no tag) |
visibility/internal | Team-only — excluded in filtered query/export mode |
visibility/pii | Sensitive 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/internaljust 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 frontmatterStep 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.,
nextjsinstead ofreact) - 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:
- Read the page
- Replace alias tags with their canonical form from the taxonomy
- If page has > 5 tags, suggest which to drop (keep the most specific/relevant ones)
- 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:
- Read
_meta/taxonomy.md - 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
- Use only canonical tags — never aliases
- 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:
- Check if an existing tag already covers the concept (suggest it if so)
- If genuinely new, determine which section it belongs in (Domain, Type, Project)
- Add it to
_meta/taxonomy.mdwith:- The canonical tag name
- What it's used for
- Any aliases to redirect
After Any Tag Operation
Append to log.md:
- [TIMESTAMP] TAG_AUDIT tags_normalized=N unknown_tags=M pages_modified=POr for normalization:
- [TIMESTAMP] TAG_NORMALIZE tags_renamed=N pages_modified=M new_tags_added=Phot.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.
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- chobizzy/llm-wiki★ 290% same
- nexuschains/operator-os★ 015% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- claude-history-ingestSkill
- codex-history-ingestSkill
- cross-linkerSkill
- data-ingestSkill
- graph-colorizeSkill
- ingest-urlSkill
- llm-wikiSkill
- wiki-captureSkill
- wiki-dashboardSkill
- wiki-exportSkill
- wiki-ingestSkill
- wiki-lintSkill
- wiki-querySkill
- wiki-rebuildSkill
- wiki-researchSkill
- wiki-setupSkill
- wiki-statusSkill
- wiki-synthesizeSkill
- wiki-updateSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

