❯ Good afternoon. I'm wondering if we can change some things in the /link-and-tag skill. ● Sure! Let me find the skill file first. ● Searched for 3 patterns (ctrl+o to expand) ● Bash(find /home/wm/.claude/plugins -name "*.md" | xargs grep -l "link-and-tag\|link_and_tag" 2>/dev/null; find /media/wm/Birch/Church/Obsidian/CPB/.claude -type f 2>…) ⎿ /media/wm/Birch/Church/Obsidian/CPB/.claude/.claude-plugin/marketplace.json /media/wm/Birch/Church/Obsidian/CPB/.claude/.claude-plugin/plugin.json /media/wm/Birch/Church/Obsidian/CPB/.claude/settings.local.json … +17 lines (ctrl+o to expand) ● Read 1 file (ctrl+o to expand) ● Got it. What changes would you like to make? ❯ We don't need to search the /OTD directory for linkable notes as those are Daily Notes. ● Update(.claude/skills/link-and-tag/SKILL.md) ⎿ Added 1 line, removed 1 line 25 Search the vault for existing note filenames that appear as plain text in the target note but are NOT already linked. 26 27 **How to search:** 28 -- Use `find_by_name` to build a list of existing note filenames across `1 Focus/`, `2 Commonplace/`, and `OTD/` 28 +- Use `find_by_name` to build a list of existing note filenames across `1 Focus/` and `2 Commonplace/` 29 - For each filename, check if that text appears unlinked in the target note's body 30 - Ignore case for matching but preserve original case in suggestions 31 ● Done. OTD/ is no longer in scope for link candidate searches. ❯ Excellent. Can you give me a summary of what the skill all does now? ● Here's what /link-and-tag does: 1. Reads the target note — parses the body text, existing [[wiki-links]], and existing tags: in frontmatter. 2. Scans for linkable mentions — searches 1 Focus/ and 2 Commonplace/ for note filenames that appear as plain text in the target note but aren't already linked. Filters out common words, already-linked text, and text inside code/YAML blocks. 3. Suggests tags — scans existing vault tags and matches them to the note's content themes, suggesting up to 5 (preferring existing tags over new ones). 4. Presents suggestions — shows a summary of proposed links (with line numbers) and tags before making any changes. 5. Applies with permission — only modifies the note after you approve. Wraps plain text in [[...]], uses [[Note Title|original text]] aliasing when needed, and adds tags to frontmatter. Key rules: never auto-applies, never removes existing links or tags, skips template files and Waypoint index files, doesn't link text inside headings, and favors conservative/high-quality suggestions over quantity. ❯ So in order for this to work properly I need to actively viewing a note before invoking the skill? ● Not necessarily — you just need to tell me which note to enrich when you invoke it. You can reference it by name or path and I'll read it directly. You don't need to have it open in Obsidian. ❯ /rename link-and-tag ⎿ Session renamed to: link-and-tag ❯ It should be worth mentioning that directories that have a period at the end more than likely has a waypoint file inside that directory. The waypoint plugin automatically creates these %% Error: Cannot create a waypoint in a note that's not the folder note. For more information, check the instructions [here](https://github.com/IdreesInc/Waypoint) %% Begin Waypoint %% and %% End Waypoint %% in them. Should we update the skill to reflect this or are we good as we stand? ● The skill already has the rule "Don't suggest links to Waypoint index files," but it doesn't explain how to identify them. Worth adding that detail so the skill can actually filter them reliably. Let me update it. ● Update(.claude/skills/link-and-tag/SKILL.md) ⎿ Added 1 line, removed 1 line 67 - **Never auto-apply** — always present suggestions and wait for approval 68 - Preserve all existing links and tags; only add, never remove 69 - Don't suggest links to template files (`9 meta/-tmp/`, `9 meta/--tmp/`) 70 -- Don't suggest links to Waypoint index files 70 +- Don't suggest links to Waypoint index files — these are notes containing `%% Begin Waypoint %%` / `%% End Waypoint %%` blocks; folders whose names end with `.` (e.g. `1 Focus +.`) typically contain one 71 - Don't link text that's inside headings (`#`, `##`, etc.) unless the user requests it 72 - If a note title ends with `.` (e.g. `Photography.`), the link should include the dot: `[[Photography.]]` 73 - Be conservative — fewer high-quality suggestions are better than many noisy ones ● Done. The skill now knows both the marker to look for and the naming convention as a quick heuristic.