agentleFS
rubber-ducks-syndicaterubber-ducks-syndicate/obsidian-documentation-skill/skills/obsidian-tagging/SKILL.md

obsidian-tagging

Skill0 starsChanged 5 months agoMITView on GitHub

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.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 26

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.

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

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.

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.