Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/shinyobjectz/montology/wordsnpx skills add shinyobjectz/montology --skill wordsgit clone --depth 1 https://github.com/shinyobjectz/montologyWhat 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 | $0.00048 | $0.02808 |
| Opus 5 | $0.00024 | $0.01404 |
| Sonnet 5 | $0.00010 | $0.00562 |
| Haiku 4.5 | $0.00005 | $0.00281 |
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 yesterday.
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 — 89 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 |
|---|---|---|---|---|
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 tree-sitter 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.
- yesterday First seen · 89 lines · 48 tokens per session scan A 3b95ec16ba20
words is a skill published in the GitHub repository shinyobjectz/montology (1 stars, last pushed 7d ago), licensed Apache-2.0. It adds 48 tokens to every session and 2,808 once invoked, about $0.0002 per session on Opus 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…
ss-score
Score a visual artifact's implementation quality 0-100 against its composed StyleSeed rule set — category breakdown, evidence, and prioritized fixes.
ss-update
Check and update an existing StyleSeed installation by exact rule/skill revision, preserve project-owned design decisions, then recompile and verify the effective bundle.
ss-verify
The VISUAL gate — render a UI or visual artifact through its surface adapter, inspect the actual pixels, then fix and re-render until it passes the composed StyleSeed rule set.
designlang-tokens
Use when styling UI for cal.com — references the extracted design system tokens instead of inventing colors, spacing, or typography.
ss-setup
Configure StyleSeed by selecting the output grammar, domain, page type, brand recipe, semantic palette recipe, optional aesthetic profile, and bounded brand tokens before scaffolding a first screen.