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 agents/stonematt/mcp-obsidian-cli/domaingit clone --depth 1 https://github.com/stonematt/mcp-obsidian-cliWrote 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/agents/stonematt/mcp-obsidian-cli/domain)<a href="https://agentmods.dev/agents/stonematt/mcp-obsidian-cli/domain"><img src="https://agentmods.dev/badge/agents/stonematt/mcp-obsidian-cli/domain.svg" alt="Measured on agentmods" height="20"></a>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 | $0.00000 | $0.00608 |
| Opus 5 | $0.00000 | $0.00304 |
| Sonnet 5 | $0.00000 | $0.00122 |
| Haiku 4.5 | $0.00000 | $0.00061 |
Grade A, and why
domain 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 3d 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 — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
Layout: single-context
This repo is a single Node package wrapping the Obsidian CLI; there are no sub-contexts. Layout:
/
├── CONTEXT.md ← glossary of domain terms
├── docs/
│ ├── briefs/ ← PRDs / scoped initiatives
│ │ └── <name>.md
│ └── adr/ ← architectural decision records (created lazily)
└── src/ (server.js, lib/, bin/)
Before exploring, read these
CONTEXT.mdat the repo root — the canonical glossary. Use its vocabulary (Verb,ObsidianCli,VerbManifest,Pass-through tool,Typed tool,Cheatsheet,Skill parity,Reload detection) in any output (issue titles, refactor proposals, hypotheses, test names).docs/adr/— ADRs that touch the area you're about to work in. May not exist yet; create lazily when a decision crystallizes.docs/briefs/<name>.md— if the work relates to a current initiative, read the brief for the why and architecture.
If any of these files don't exist, proceed silently. Don't flag absence; don't suggest creating them upfront. The producer skills (/grill-with-docs, /to-prd) create them lazily.
Use the glossary's vocabulary
When an output names a domain concept, use the term as defined in CONTEXT.md. Don't drift to synonyms the glossary explicitly avoids (e.g. command, action for Verb; service, runner for ObsidianCli).
If a concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider), or there's a real gap (note it for /grill-with-docs).
Flag ADR conflicts
If output contradicts an existing ADR, surface it explicitly rather than silently overriding:
Contradicts ADR-0007 — but worth reopening because…
Only surface when the friction is real enough to warrant revisiting the ADR. Don't list every theoretical refactor an ADR forbids.
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.
- 3d ago First seen · 47 lines · 0 tokens per session scan A b304d1d82970
domain is an agent published in the GitHub repository stonematt/mcp-obsidian-cli (2 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 608 tokens. 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 agents, from other repositories
vault-explorer
Use proactively when researching what the vault knows about a topic, before creating new notes, or when exploring existing knowledge and connections. Run in foreground — results inform the caller's next steps. Examples: Context: User asks about a topic before creating new content. user: "What does the vault already…
coder
Sonnet implementer for a well-scoped change — edits/tests to green; not architecture calls, asks if ambiguous.
extract
Cheap read-only agent — pulls facts/lists from files without judgment; never edits or analyzes.
issue-tracker
Issues and PRDs for this repo live as GitHub issues. Use the gh CLI for all operations.
ios-tester
You are an iOS testing agent for the Bullhorn project — a Next.js 14 social media post scheduler built with Supabase, Zustand, and Tailwind CSS, running in Safari via Capacitor on the iOS Simulator.
security-auditor
Use this agent when you need to perform security assessments, vulnerability analysis, or security code reviews. Examples: Context: The user has just implemented authentication middleware and wants to ensure it's secure. user: 'I just added JWT authentication to my API. Can you review it for security issues?'…