Glossary sync

Skill rulebased-io/claude-plugin/packages/second-brain/skills/glossary-sync

Claude Code plugins by rulebased.io — harness audit/init/recommend + second-brain capture/connect/review/organize

Install

npx -y skills add rulebased-io/claude-plugin --skill glossary-sync

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

Detect new domain-specific terms in notes and add them to the glossary. Use to keep the glossary up-to-date with evolving vocabulary.

SKILL.md

3.2 KB, as published. Nobody here has run it

Scan notes for new terms and sync them into the glossary.

When to Use

After writing several new notes with domain-specific vocabulary
Periodic glossary maintenance
/rulebased-second-brain:glossary-sync invoked

Procedure

Step 1: Locate Glossary

Glob for **/glossary.md in the brain
If no glossary exists, propose creating resources/glossary.md:

---
title: Glossary
created: {date}
updated: {date}
tags: [glossary, reference]
type: reference
---

# Glossary

Terms and definitions used in this brain.

## A
## B
...
## Z

Step 2: Load Existing Terms

Parse the glossary file:

Extract all ### Term headings as registered terms
Build a set of known terms (case-insensitive) for deduplication

Step 3: Determine Scan Scope

Read $ARGUMENTS:

Argument	Scope
(empty) or `recent`	Files changed in the last 7 days (`git diff --name-only` or file mtime)
`full`	All `.md` files in the brain

Exclude from scanning:

system/ directory (configuration, not content)
archives/ directory
Hidden directories
The glossary file itself

Step 4: Detect New Terms

Scan target files for term candidates:

Include — terms worth adding:

Domain-specific concepts (e.g., "Zettelkasten", "Spaced Repetition")
Project-specific abbreviations or acronyms with special meaning
Words used with a specific meaning different from common usage
Technical terms that appear 2+ times across different notes

Exclude — terms to skip:

Generic development terms (API, JSON, Git, HTTP, CSS, HTML, npm, etc.)
Common natural language words (even if frequently used)
Terms that appear only once and are unlikely to recur
Terms already registered in the glossary

Step 5: Present Candidates

## Glossary Sync — {scope} ({date})

### New Term Candidates ({N})

| Term | Draft Definition | Source |
|------|-----------------|--------|
| `Term Name` | One-line definition | `file.md:42` |

### Already Registered (skipped)
- term1, term2, ...

Add terms? (all / select numbers / cancel)

Step 6: User Confirmation and Insertion

For each approved term:

Let user edit the draft definition if needed
Insert into glossary under the correct alphabetical section (## A, ## B, etc.)
Use the format:

### Term Name

One-line definition.

If the alphabetical section doesn't exist, create it in order
Maintain alphabetical order within each section

Report results:

Glossary sync complete:
  Added: {N} terms
  Skipped: {M} terms
  Total glossary size: {T} terms

Rules

Never add terms without user approval. Always present candidates first.
Draft definitions are suggestions — the user has final say on wording.
Alphabetical ordering uses the term's first letter (case-insensitive).
One term = one ### heading + one-line definition. Keep it concise.
If a term could be an alias of an existing term, flag it instead of adding a duplicate.
Preserve existing glossary formatting and content — only append, never rewrite.

$ARGUMENTS