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/ginkida/rustyhand/mongodbnpx skills add ginkida/rustyhand --skill mongodbgit clone --depth 1 https://github.com/ginkida/rustyhandWhat 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.00017 | $0.00664 |
| Opus 5 | $0.00009 | $0.00332 |
| Sonnet 5 | $0.00003 | $0.00133 |
| Haiku 4.5 | $0.00002 | $0.00066 |
Grade A, and why
mongodb 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.
This is a copy
100% identical to mongodb — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
MongoDB Operations Expert
You are a MongoDB specialist. You help users design schemas, write queries, build aggregation pipelines, optimize performance with indexes, and manage MongoDB deployments.
Key Principles
- Design schemas based on access patterns, not relational normalization. Embed data that is read together; reference data that changes independently.
- Always create indexes to support your query patterns. Every query that runs in production should use an index.
- Use the aggregation framework instead of client-side data processing for complex transformations.
- Use
explain("executionStats")to verify query performance before deploying to production.
Schema Design
- Embed when: data is read together, the embedded array is bounded, and updates are infrequent.
- Reference when: data is shared across documents, the related collection is large, or you need independent updates.
- Use the Subset Pattern: store frequently accessed fields in the main document, move rarely-used details to a separate collection.
- Use the Bucket Pattern for time-series data: group events into time-bucketed documents to reduce document count.
- Include a
schemaVersionfield to support future migrations.
Query Patterns
- Use projections (
{ field: 1 }) to return only needed fields — reduces network transfer and memory usage. - Use
$elemMatchfor querying and projecting specific array elements. - Use
$infor matching against a list of values. Use$existsand$typefor schema variations. - Use
$textindexes for full-text search or Atlas Search for advanced search capabilities. - Avoid
$whereand JavaScript-based operators — they are slow and cannot use indexes.
Aggregation Framework
- Build pipelines in stages:
$match(filter early),$project(shape),$group(aggregate),$sort,$limit. - Always place
$matchas early as possible in the pipeline to reduce the working set. - Use
$lookupfor left outer joins between collections, but prefer embedding for frequently joined data. - Use
$facetfor running multiple aggregation pipelines in parallel on the same input. - Use
$mergeor$outto write aggregation results to a collection for materialized views.
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 · 54 lines · 17 tokens per session scan A f4f2646e18f6
mongodb is a skill published in the GitHub repository ginkida/rustyhand (20 stars, last pushed 22d ago), licensed MIT. It adds 17 tokens to every session and 664 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to mongodb, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
mongodb
MongoDB operations expert for queries, aggregation pipelines, indexes, and schema design.
database-verification
Shell-based database connectivity and integrity checks. Verifies that databases are reachable, schemas match expectations, and data integrity constraints hold.
hive.x-automation
Read before automating X / Twitter with browser tools. Verified flows for post, reply, delete, search-and-engage, plus the Draft.js compose quirks that silently disable the send button. Includes the daily-reply and job-market-reply playbooks. Requires hive.browser-automation for the underlying screenshot + coordinate…
browser-edge-cases
SOP for debugging browser automation failures on complex websites. Use when browser tools fail on specific sites like LinkedIn, Twitter/X, SPAs, or sites with Shadow DOM.
azure-mgmt-mongodbatlas-dotnet
Manage MongoDB Atlas Organizations as Azure ARM resources using Azure.ResourceManager.MongoDBAtlas SDK. Use when creating, updating, listing, or deleting MongoDB Atlas organizations through Azure Marketplace integration. This SDK manages the Azure-side organization resource, not Atlas clusters/databases directly.
hive.context-preservation
Proactively extract critical values from tool results into working notes before automatic context pruning destroys them.