← ClaudeAtlas

obsidian-tagginglisted

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.
rubber-ducks-syndicate/obsidian-documentation-skill · ★ 0 · AI & Automation · score 72
Install: claude install-skill rubber-ducks-syndicate/obsidian-documentation-skill
# 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: ```bash 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