New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Lexicon

by jackfranklin in jackfranklin/dotfiles

Define, review, and audit a project's domain vocabulary across code and documentation.

MITAuto-check passedDevelopment

Install Lexicon

skills CLI
$ npx skills add jackfranklin/dotfiles --skill lexicon -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install jackfranklin/dotfiles lexicon --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/jackfranklin/dotfiles.git skills-src && mkdir -p .claude/skills && cp -r skills-src/claude/skills/lexicon .claude/skills/lexicon && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
lexicon
GitHub stars
255
Token cost
~2.1k tokens
SKILL.md length
977 words
Files
2
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Define, review, and audit a project's domain vocabulary across code and documentation.

  • Works in 3 steps: Lexicon authoring → Lexicon audit → Naming critique
  • Editing a lexicon
  • SKILL.md covers Invariants, Workflows, Term admission rules and Review and resolution procedure, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Lexicon is an agent skill from jackfranklin/dotfiles. Define, review, and audit a project's domain vocabulary across code and documentation. Use when creating or editing a lexicon, glossary, or term list; auditing against a lexicon for drift, invented vocabulary, and deprecated terms; critiquing project vernacular; reconciling conceptual models; or planning naming refactors.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `README.md`).

It sits in Development, covering Refactoring. The repository describes itself as: My dotfiles for my dev environment, compromising of tmux, vim, zsh and git. The licence is MIT.

When your agent uses it

  • Editing a lexicon
  • Auditing against a lexicon for drift
  • Invented vocabulary
  • Deprecated terms

Example prompts

  • “/lexicon”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Lexicon authoring
  2. Lexicon audit
  3. Naming critique

What it can do on your machine

Read from SKILL.md and the folder at commit cb5501c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Lexicon loads about 2.1k tokens when it runs. Until then it costs about 83 tokens; SKILL.md has 977 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~83
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from jackfranklin/dotfiles at commit cb5501c, republished under its MIT licence (© jackfranklin). 977 words, ~2,110 tokens.

Download SKILL.mdSave it as .claude/skills/lexicon/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
lexicon
description
Define, review, and audit a project's domain vocabulary across code and documentation. Use when creating or editing a lexicon, glossary, or term list; auditing against a lexicon for drift, invented vocabulary, and deprecated terms; critiquing project vernacular; reconciling conceptual models; or planning naming refactors.

Lexicon

Maintain a small, opinionated vocabulary for concepts humans and agents must understand consistently. Treat terminology disagreements as possible disagreements about the domain model, not merely word choice.

Prevent terminology drift, invented vocabulary, obsolete conceptual framings, and synonym bloat.

Invariants

  • One term per concept: Keep one canonical term; reject generic terms and speculative synonyms. Never invent a compromise name that fuses competing alternatives.
  • Evidence-based: Admit terms grounded in code, documentation, schemas, project history, or relevant external sources.
  • Terminology authority: The lexicon governs terminology. Ground definitions in established project meaning; do not use entries to introduce or adjudicate architecture, implementation choices, or project status. Surface unresolved domain decisions to the user.
  • Boundaries, not specs: Include only the facts needed to identify a concept and distinguish easily confused neighbors; do not turn entries into procedures or miniature specifications. Link to authoritative documentation for implementation, operational details, and decision history.
  • Definition test: Could this fact change while the term still meant the same thing? If so, omit it from the definition and link to its authoritative source when useful. Retain conditions, relationships, or lifecycle facts only when necessary to distinguish the concept.
  • User authority: Let the user adjudicate conceptual conflicts. Never silently pick a winner or reopen explicit decisions.

Workflows

Select based on user intent (ask if ambiguous):

  1. Lexicon authoring: Create or expand LEXICON.md.
  2. Lexicon audit: Sweep the codebase against LEXICON.md to catch drift, invented vocabulary, and deprecated terms.
  3. Naming critique: Evaluate the project's current vernacular for clarity and suggest better domain terms.
1. Lexicon authoring
  • Load: Locate and read the entire authoritative lexicon. Check LEXICON.md, TERMS.md, GLOSSARY.md, CONTEXT.md, and relevant README.md sections; report overlaps and ask if authority is unclear. Default new lexicons to root LEXICON.md.
  • Survey: Use 2+ parallel read-only subagents to extract domain terms from (a) specs/docs, (b) schemas/APIs/public types, and (c) conceptual conflicts affecting terminology. Require each candidate to state the terminology problem and exact evidence locations, not raw search dumps.
  • Resolve: Run the Review and resolution procedure.
  • Link: Reference the lexicon in AGENTS.md when newly created.
2. Lexicon audit
  • Load standard: Read canonical terms, implementation references, and _Avoid_ entries.
  • Scan: Use 2+ parallel subagents to search for avoided terms, canonical misuse, new or invented vocabulary, and conceptual conflicts. Exclude generated/vendored files.
  • Check safety: Deduplicate and inspect replacements for legitimate multi-domain uses, compound identifiers, third-party interfaces, serialized strings, logs, fixtures, and compatibility surfaces. Treat any ambiguous occurrence as a semantic question, not a mechanical replacement; surface uncertain exclusions and classify clear violations by safety tier.
  • Resolve: Run the Review and resolution procedure.
  • Apply and verify: Apply only approved fixes, verify per their safety tier, and summarize what changed and what remains open.
3. Naming critique
  • Load vernacular: Read the existing lexicon; if none exists, infer current usage from the request and authoritative project sources.
  • Survey: Reuse the authoring survey or audit scan if run together; otherwise use 2+ parallel subagents across specs, schemas, and core code.
  • Inspect: Flag misleading, overloaded, inconsistent, idiosyncratic, or nonparallel names, including multiple names for one idea and one name for multiple ideas. Distinguish genuine conceptual issues from harmless prose variation.
  • Resolve: Run the Review and resolution procedure. Treat findings as naming improvements, not lexicon changes, unless the concept independently passes admission rules and the user asked for lexicon edits.
Show full SKILL.md (429 more words)Show less

Term admission rules

Admit a term when its entry resolves an evidenced ambiguity in naming or meaning, or explains a project-specific distinction readers need to use the term correctly.

For each candidate, answer: What naming or interpretation error does this entry prevent? State the terminology problem and its evidence, including for candidates found during audits or naming critiques. Do not invent competing names to justify an entry.

Prominence, frequency, and architectural importance are insufficient. Reject entries that merely identify a project or technology, repeat a standard definition, or document implementation or project history.

Review and resolution procedure

  1. Classify findings by next action:
    • Add to the lexicon: Clear concept passing admission rules.
    • Discuss with the user: Drift, competing names, boundary conflicts, or ambiguous uses.
    • Propose a project edit: Naming improvement or unambiguous lexicon violation.
    • Discard: Fails admission rules or irrelevant match.
  2. Challenge consequential findings: For authoring additions, audit mechanical replacements, and close boundary distinctions, invoke a fresh skeptical subagent with candidates, proposed definitions, and evidence (no advocacy). Have the reviewer check both term admission and whether each sentence of a proposed definition passes the definition test. Incorporate objections before proceeding.
  3. Write accepted terms: Add Add to the lexicon terms immediately; notify user with a concise list.
  4. Resolve questions: Present Discuss with the user items as questions on boundaries and meaning. Retain replaced canonical terms under _Avoid_.
  5. Propose project edits: For naming critiques, present the smallest high-value replacements. For audits, batch fixes by term and report the replacement direction, count, ambiguity-check result, safety tier, and representative locations. Apply only user-approved changes.

Change safety tiers

  • Tier 1 (Prose & local): Prose, comments, unexported identifiers.
  • Tier 2 (Structural): Shared types, interfaces, cross-module signatures. Requires explicit approval + typecheck/test.
  • Tier 3 (Compatibility-sensitive): Persisted schemas, public APIs, wire contracts, CLI flags, serialized data, logs. Requires migration/compatibility plan.

A term's highest-risk occurrence dictates its approval tier. Never treat mixed-risk terms as mechanical.

Lexicon format

Use this shape when creating or materially restructuring a lexicon. Preserve an existing format when it carries the same semantics.

markdown
# Project Lexicon

The canonical domain language for this project and the conceptual boundaries those terms represent.

## <Domain or subsystem>

### Canonical Term

One or two sentences stating what the concept is and its boundary or lifecycle role.
"Not to be confused with X; X differs because ..."

* _Reference_: `src/types.ts#CanonicalTerm` (stable public type, table, or API contract)
* _AKA_: External Term — used by Specific Standard or Upstream Project
* _Avoid_: DeprecatedTerm — superseded in PR #123
  • Scope: Canonical compound nouns for exported, persisted, public, and wire identifiers; concise names and descriptive modifiers (activeUser, userId) allowed in unambiguous local scope.
  • AKA restraint: Only list alternatives used by an external source (standard, paper, upstream library). Exclude English synonyms and competing internal names.
  • Avoid restraint: Only list evidenced deprecated names or alternatives explicitly rejected by the user for this concept; retain them after cleanup. Replacing a technology or component does not by itself make its name a deprecated synonym.
  • Omit metadata bullets (_Reference_, _AKA_, _Avoid_) when not applicable.

© jackfranklin, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in claude/skills/lexicon of jackfranklin/dotfiles.

  • SKILL.md
  • README.md

Open the folder on GitHubat commit cb5501c

Compare with similar skills

Lexicon next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Lexicon compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Lexicon this skilljackfranklin/dotfiles255—~2.1kAutomated safety check: PassMIT
Guidelinesakash-network/node1.1k20 repos~577Automated safety check: PassMIT
Migrate Core Code to Submodulestinyhumansai/openhuman42k—~2.6kAutomated safety check: PassGPL-3.0
Component Refactoringlangflow-ai/langflow155k—~3.5kAutomated safety check: PassMIT
Ponytail Lazy Developer ModeDietrichGebert/ponytail160k1 repos~873Automated safety check: PassMIT
ast-grep Structural Searchcode-yeongyu/oh-my-openagent70k—~3.3kAutomated safety check: PassMIT

Similar skills

  • Guidelines

    akash-network/node

    Behavioral guidelines to reduce common LLM coding mistakes. An agent skill from akash-network/node.

    1.1k GitHub starsUsed in 20 repos~577 tokens
    DevelopmentAuto-check passed

  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    42k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    155k GitHub stars~3.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Ponytail Lazy Developer Mode

    DietrichGebert/ponytail

    Makes the agent pick the laziest solution that works: skip unneeded work, reuse what exists, prefer the standard library and platform features, and keep diffs small.

    160k GitHub starsUsed in 1 repo~873 tokens
    DevelopmentAuto-check passed

  • ast-grep Structural Search

    code-yeongyu/oh-my-openagent

    Searches and rewrites code by syntax-tree shape across 25 languages with ast-grep, for codemods, structural queries and YAML lint rules, using a Python wrapper script.

    70k GitHub stars~3.3k tokensUpdated today
    DevelopmentAuto-check passed

  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated today
    DevelopmentAuto-check passed

More from jackfranklin/dotfiles

All 21 skills in this repo

  • GitHub Code Review

    jackfranklin/dotfiles

    Perform a thorough, read-only review of one GitHub pull request.

    255 GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed

  • Adr

    jackfranklin/dotfiles

    Capture an Architecture Decision Record (ADR) for a significant decision made in the current project.

    255 GitHub stars~962 tokensUpdated yesterday
    Auto-check passed

  • Jack References

    jackfranklin/dotfiles

    Manage Jack's personal technical reference library at ~/git/references.

    255 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed

  • Later

    jackfranklin/dotfiles

    Log items to come back to later — bugs found mid-task, feature ideas, project feedback — as GitHub Issues.

    255 GitHub stars~767 tokensUpdated yesterday
    Auto-check passed

  • Resolve Merge Conflict

    jackfranklin/dotfiles

    A skill your agent uses when you need to resolve an in-progress git merge/rebase conflict.

    255 GitHub starsUsed in 23 repos~427 tokens
    Auto-check passed

  • Writing Great Skills

    jackfranklin/dotfiles

    Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

    255 GitHub starsUsed in 15 repos~2.2k tokens
    Auto-check passed

Categories

Questions about Lexicon

What does Lexicon do?

Define, review, and audit a project's domain vocabulary across code and documentation. Lexicon is an agent skill from jackfranklin/dotfiles. Define, review, and audit a project's domain vocabulary across code and documentation.

When should I use Lexicon?

Lexicon fits situations like: editing a lexicon; auditing against a lexicon for drift; invented vocabulary; deprecated terms.

How do I install Lexicon in Claude Code?

Run `npx skills add jackfranklin/dotfiles --skill lexicon -a claude-code`. Or copy the skill folder (claude/skills/lexicon in jackfranklin/dotfiles) into .claude/skills/lexicon in your project. Claude Code loads it when a task matches its description.

How do I install Lexicon in Codex?

Run `npx skills add jackfranklin/dotfiles --skill lexicon -a codex`. Or copy the skill folder (claude/skills/lexicon in jackfranklin/dotfiles) into .agents/skills/lexicon in your project. Codex loads it when a task matches its description.

Can I use Lexicon in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jackfranklin/dotfiles --skill lexicon -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/lexicon, .gemini/skills/lexicon, .github/skills/lexicon and .opencode/skills/lexicon in your project.

What does Lexicon need to run?

SKILL.md names no scripts, command-line tools or credentials: Lexicon is instructions for the agent only.

Does Lexicon access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Lexicon safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Lexicon use?

Lexicon is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Lexicon use?

About 2.1k tokens (SKILL.md is roughly 8.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Lexicon?

Skills that share tags, products or a category with Lexicon: Guidelines (akash-network/node, 1.1k stars), Migrate Core Code to Submodules (tinyhumansai/openhuman, 42k stars), Component Refactoring (langflow-ai/langflow, 155k stars) and Ponytail Lazy Developer Mode (DietrichGebert/ponytail, 160k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Lexicon?

jackfranklin (a GitHub user) maintains it in jackfranklin/dotfiles, which has 255 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on October 10, 2026.

Source: jackfranklin/dotfiles on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.