Obsidian tagging

Skill rubber-ducks-syndicate/obsidian-documentation-skill/skills/obsidian-tagging

A modular orchestrator + specialists ecosystem for Claude Code that turns code changes and conversations into structured, linked Obsidian documentation.

Install

npx -y skills add rubber-ducks-syndicate/obsidian-documentation-skill --skill obsidian-tagging

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Specialist skill that owns the tag taxonomy of an Obsidian vault — assigning tags to new notes, keeping tags consistent, extending the hierarchy, and auditing/fixing tag drift. Normally invoked by the obsidian-documentation orchestrator as the final pass of every documentation run, and directly for "fix my tags", "what tags should this have", "tags are a mess" requests.

SKILL.md

2.9 KB, 634 tokens by cl100k_base, as published. Nobody here has run it

Tagging Specialist

You own the tag taxonomy. Every documentation run ends with your pass, because tags created ad-hoc by different skills (or humans) drift, and drifted tags make search and graph views useless.

Read ../obsidian-documentation/references/conventions.md first.

Core taxonomy

#backend            #frontend            #feature        #architecture
  #backend/api        #frontend/react    #adr            #moc
  #backend/graphql    #frontend/state    #integration    #diagram
  #backend/db         #frontend/ui       #infrastructure
#aws                                       #aws/lambda  #aws/sqs  #aws/s3

Format rules: lowercase, singular, / for hierarchy, no spaces or camelCase. A note gets 2–5 tags: one type tag (feature, architecture, adr…) plus domain tags (backend/graphql, aws/lambda…).

Reuse before invent

Before assigning any tag, list what already exists in the vault:

grep -rhoE '#[a-z][a-z0-9/_-]+' <vault> --include='*.md' | sort | uniq -c | sort -rn

(Also check frontmatter tags: lists, which don't carry #.) If an existing tag covers the concept, use it. Extend the hierarchy only when a real cluster of notes needs it — 3+ notes on GraphQL justifies #backend/graphql; one note doesn't. When you add a hierarchy level, the parent tag remains valid (#backend/graphql notes are still found via #backend).

Two modes

Assign mode (every orchestrator run): take the run's new/updated notes, assign tags from the taxonomy, ensure all notes in the run use identical spelling, write tags into frontmatter.

Audit mode (tag cleanup requests, or when you spot drift): get the inventory from the vault-scanner agent (tag-inventory scan; run the grep above inline if agents are unavailable); find near-duplicates (#front-end vs #frontend), wrong format (#Backend, plurals), single-use orphan tags, and untagged notes. Propose a rename map to the user before mass-editing, then apply it across the vault.

Example

Assign: new notes Features/Refunds/Refunds.md, Backend.md, Frontend.md → Refunds.md: [feature, backend, frontend] · Backend.md: [feature, backend/api] · Frontend.md: [feature, frontend/react]

Audit: vault contains #GraphQL (3 notes), #backend/graphql (5 notes), #payments (1 note) → propose: merge #GraphQL → #backend/graphql; keep #payments only if more payment notes are expected, otherwise drop and rely on the Features/Payments/ folder + links.