Borrowing it
Nothing to install: this file belongs to shinyobjectz/montology. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/shinyobjectz/montology/main/.claude/skills/words/SKILL.mdgit clone --depth 1 https://github.com/shinyobjectz/montologyWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shinyobjectz/montology/words)<a href="https://agentmods.dev/skills/shinyobjectz/montology/words"><img src="https://agentmods.dev/badge/skills/shinyobjectz/montology/words/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shinyobjectz/montology/words"><img src="https://agentmods.dev/badge/skills/shinyobjectz/montology/words.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00048 | $0.03949 |
| Opus 5.5 | $0.00019 | $0.01580 |
| Sonnet 5.5 | $0.00010 | $0.00790 |
| Haiku 4.5 | $0.00005 | $0.00395 |
Grade A, and why
words scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 117 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GENERATED FILE. The database at
.monty/ontology.dbis the truth; this renders from it. Hand edits are lost on the next sync — change the database instead (monty onto add), which is also whatmonty lintverifies.
The words
| word | code | kind | is | test |
|---|---|---|---|---|
| act (inside scan) | scan.act |
core · noun | one thing the code does, read off the tree: a subject, a verb and an object at a place — the half of a codebase that declarations cannot see | what the code does, not what it declares |
| amendment (inside ontology) | onto.amendment |
core · noun | a word's own text corrected in place — the name and its history stay, and what the field said before is ledgered; the counterpart to a rename, which retires the name instead | what a word used to say |
| candidate (inside scan) | scan.candidate |
core · noun | a recurring declared name with no word — vocabulary the codebase is asking for | what wants a definition |
| code (inside ontology) | onto.code |
core · value | a word's dotted address (har, har.cell) — prefixes must resolve to words, so the namespace stays a tree | where a word lives |
| collision (inside scan) | scan.collision |
core · noun | a declaration named after a word that means something else — the failure scan exists to catch | where code and vocabulary disagree |
| convergence (inside scan) | scan.convergence |
core · noun | the state a tended lexicon reaches: new concepts per sample decaying toward zero while the code keeps growing | whether the vocabulary settles |
| coverage (inside ontology) | onto.coverage |
core · noun | the two-way check between questions and words: a question no word answers is a hole, and a word no question motivates is vocabulary nobody asked for | does this vocabulary answer for itself |
| disclosure (inside ontology) | onto.disclosure |
core · noun | how much of the vocabulary a render keeps resident and how much it points at — the always-loaded page, the reference pages behind it, the database behind those | what every agent is made to carry |
| divergence (inside scan) | scan.divergence |
core · noun | one word declared as more than one value — the finding no exception silences, because sharing a name is a decision and meaning two things is not | where one noun holds two things |
| doctrine (inside ontology) | onto.doctrine |
core · noun | a decision written down in the database — because a decision that is not written down gets re-litigated | why it is this way |
| drift (inside scan) | scan.drift |
core · noun | a value or prose that moved away from the vocabulary it claims: a rogue literal, a near-duplicate, a stale render | what the gate exists to catch |
| edge (inside ontology) | onto.edge |
core · noun | a relation the ontology holds between two things it names — containment, a route, a ruling, a bearing — and every one of them gates something, because an edge nothing can check is a drawing | what connects two things we name |
| exception (inside ontology) | onto.exception |
core · noun | a recorded decision that a symbol may share a word's name — with the reason it was granted and the paths it holds in, because a reasonless allow-list is one nobody reads | which collisions we keep |
| genus (inside ontology) | onto.genus |
core · noun | the more general word a word is a kind of — containment says where a word lives, this says what it IS, and a word inherits its genus's rulings | what kind of thing is it |
| gist (inside ontology) | onto.gist |
core · noun | a definition rendered to its first sentence — what a resident page carries when the whole definition is not worth its place in context | the short form of a meaning |
| glossary (inside ontology) | onto.glossary |
core · noun | the whole ontology rendered to one page — every word, ruling and doctrine block, from the database, with the intake it grew from as appendix | what our words mean, on one page |
| intake (inside workspace) | ws.intake |
core · noun | the phased questions a workspace starts with — asked in a form, answered on disk, each round written from the last — before any word is authored | what was asked, what they said |
| intent (inside ontology) | onto.intent |
core · noun | one named way to change the vocabulary, and the only way anything that is not a person at a terminal may do so | how a change is asked for |
| migration (inside scan) | scan.migration |
core · noun | a renamed word propagated through the code by token — sweep reports, apply rewrites, the diff is the review | how the code catches up |
| ontology | onto |
core · noun | a repo's vocabulary as a database: words, doctrine, rulings — enforced by scan, rendered to prose, never authored in prose | what the words are |
| phantom (inside surface) | surf.phantom |
core · noun | a surface with no seam: declared, never met — the mirror of a candidate, which is a declaration with no word | what nothing touches |
| proposal (inside ontology) | onto.proposal |
core · noun | a set of changes to the vocabulary, reviewed before it lands — stored as intents rather than as a second copy of the words, so it reads as a diff of meaning and replays through the same door a person uses | what someone wants the words to become |
| question (inside ontology) | onto.question |
core · noun | something the vocabulary must be able to answer — kept as a requirement, linked to the words that answer it, and checked both ways | what someone needs to be able to ask |
| recipe (inside ontology) | onto.recipe |
core · noun | a named composition of utility classes — the unit a utility-first design vocabulary trades in above single tokens | what a repeated class string wants to be |
| relation (inside ontology) | onto.relation |
core · noun | one word doing something to another, authored rather than mined — the ontology's own graph, which no amount of reading code will produce because code holds an implementation and not an ontology | what acts on what |
| rigidity (inside ontology) | onto.rigidity |
core · value | whether a word names what a thing IS and cannot stop being, or a role it plays for a while — the one metaproperty that makes a wrong subsumption catchable | could a thing stop being this |
| ruling (inside ontology) | onto.ruling |
core · noun | a recorded boundary decision: an overload (say Y not X), a collision (whose word it is, who moved), or a rename (was, now, why) | how arguments end |
| scan | scan |
core · noun | the parse-and-measure sweep of a codebase: every declaration measured, every dependency surface and the seams between them, checked against the vocabulary | what the code claims |
| seam (inside surface) | surf.seam |
core · noun | one point where two surfaces meet — an import that resolves, a call that lands, a config key read; direction is an attribute, so inputs and outputs need no words of their own | where two things touch |
| surface | surf |
core · noun | what a thing exposes: its named, callable, importable face — ours and a dependency's alike, whose it is being an attribute and not a second word | what something offers |
| sync (inside ontology) | onto.sync |
core · verb | rendering the database to the generated words skill — prose is output, never source | how agents read it |
| token (inside ontology) | onto.token |
core · noun | a named design value — color, space, radius, shadow, font, breakpoint — the vocabulary a visual system trades in | what design means |
| vitals (inside scan) | scan.vitals |
core · noun | the at-a-glance state of a repo's meaning: the gate, the vocabulary, the design system, the guard — one verdict (tended, drifting, untended) | how the repo is doing |
| word (inside ontology) | onto.word |
core · noun | one term with one meaning: definition, the one-line test, an optional owner and dotted code | what we mean |
| workspace | ws |
core · noun | any repo montology is initialized into — found by walking up for .monty, the way git finds .git | where work happens |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +28 lines 0887b8fdca44
- 1mo ago First seen · 89 lines · 48 tokens per session scan A 3b95ec16ba20
words is a skill published in the GitHub repository shinyobjectz/montology (52 stars, last pushed 16d ago), licensed Apache-2.0. It adds 48 tokens to every session and 3,949 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
extract-design
Extract the full design language from any website URL. Produces 8 output files including AI-optimized markdown, visual HTML preview, Tailwind config, React theme, shadcn/ui theme, Figma variables, W3C design tokens, and CSS variables. Also runs WCAG accessibility scoring. Use when user says 'extract design', 'get…
designlang-tokens
Use when styling UI for cal.com — references the extracted design system tokens instead of inventing colors, spacing, or typography.
omd-apply
A skill that applies a project's DESIGN.md file as visual and brand guidance for interface work. It covers components, colors, fonts, layout, copy, motion, and visual assets.
bench-fixture-gen
Generates the shared per-task fixture that every competing arm starts from: a realistic dataset plus an image asset base. Fairness rule: fixtures are generated ONCE per task by this preprocessor and sealed (sha256) before any arm runs; arms never generate their own.
design-md-extractor
Extract and document the visual style of public websites as reusable DESIGN.md files. Use when the user asks to analyze a website's design system, extract styles, create design tokens, produce DESIGN.md, generate an agent-readable style guide, or build from a website's visual language.
dembrandt
A TypeScript command-line tool that renders a web page with Playwright and examines its actual styles. It turns colours, typography, spacing, borders, shadows, animation curves, components, and breakpoints into structured design tokens.