CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

mongodb-schema-design

MongoDB schema design patterns and anti-patterns. Use when designing data models, reviewing schemas, migrating from SQL, or troubleshooting performance issues caused by schema problems. Triggers on "design schema", "embed vs reference", "MongoDB data model", "schema review", "unbounded arrays", "one-to-many", "tree structure", "16MB limit", "schema validation", "JSON Schema", "time series", "schema migration", "polymorphic", "TTL", "data lifecycle", "archive", "index explosion", "unnecessary indexes", "approximation pattern", "document versioning".

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured index-style skill: excellent progressive disclosure with a complete, verified one-level-deep reference bundle and concrete commands/tool names throughout. The main weakness is token efficiency — the Action Policy and 'Working Together' sections pad the file with repeated approval rhetoric and conversational filler that could be cut to a few lines.

Suggestions

Collapse the Action Policy to a single compact statement: the bold pledge, the numbered 4-step process, the tool table, and the closing motto all restate the same approval rule — keep the table plus one sentence and cut the rest, including the 'Working Together' section's conversational lines ('We're a team—let's get this right together').

Trim the Key Principle section: the multi-paragraph explanation of flexible schemas and co-location implications duplicates the Schema Fundamentals Summary bullets immediately below it and content in fundamental-embed-vs-reference.md; keep the principle quote plus the summary bullets.

Add an explicit validation step to the Access Pattern Analysis workflow (e.g., 'Step 5: verify the proposed change against observed query stats/slow logs before recommending') so conclusions are checked against real data, not just writes.

DimensionReasoningScore

Conciseness

The Quick Reference index and access-pattern workflow are tight, but there is noticeable padding: the Action Policy states the same approval rule three ways (bold pledge, numbered list, table, closing motto), the "Working Together" section is conversational fluff ("We're a team—let's get this right together"), and the Key Principle paragraphs re-explain flexible schemas and co-location basics that the Schema Fundamentals Summary bullets and reference files already cover. This fits the 3 anchor (mostly efficient with some unnecessary explanation) better than 2, since the padding is localized rather than pervasive.

3 / 5

Actionability

Concrete, executable elements are present: `db.serverStatus().opcounters`, `$jsonSchema` with `validationLevel: "moderate"` / `validationAction: "warn"`, `$bsonSize`, named MCP tools (`mcp__mongodb__collection-schema`, `mcp__mongodb__aggregate`, `mcp__mongodb__db-stats`), a decision-framework table, and per-reference 'when to consult' descriptions. It is not 5 because the body itself contains few copy-paste-ready examples (those live in the references), and not 3 because the guidance given is specific and executable rather than pseudocode or hints.

4 / 5

Workflow Clarity

The Access Pattern Analysis workflow is a clearly sequenced 4-step process with diagnostic questions, a verification command, and an explicit method for combining query stats with slow-query logs; the "Working Together" loop (run verification commands → share output → adjust recommendation) and the approval-gated write policy provide feedback and safety checkpoints appropriate to database operations. It falls short of 5 because the workflow steps themselves lack an explicit validation checkpoint on conclusions (e.g., verifying a proposed schema change against observed data before recommending it).

4 / 5

Progressive Disclosure

The body is a clear overview that indexes all 20 bundle files (verified present in ./references/) with one-line 'when to consult' descriptions, organized into coherent groups (anti-patterns, fundamentals, patterns, diagnostic sources), with references exactly one level deep. This matches the 5 anchor: well-signaled one-level-deep references, easy navigation, and content appropriately split — the inline decision table and principles summary are reasonable overview-level material.

5 / 5

Total

16

/

20

Passed

Description

95%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it clearly states what the skill covers and when to use it, with an unusually thorough list of natural trigger terms including synonyms and domain-specific phrases. Third-person voice is used correctly and no over-claims or fluff appear.

DimensionReasoningScore

Specificity

"MongoDB schema design patterns and anti-patterns" names the domain, and "designing data models, reviewing schemas, migrating from SQL, or troubleshooting performance issues" lists several concrete capabilities. Falls short of 5 because the 'what' centers on topic coverage rather than a comprehensive list of concrete actions (e.g., it never states it provides code examples or decision frameworks), and exceeds 3 because more than 1-2 specific actions are given.

4 / 5

Completeness

Both questions are explicitly answered: 'what' via "MongoDB schema design patterns and anti-patterns" and 'when' via an explicit "Use when designing data models, reviewing schemas, migrating from SQL, or troubleshooting performance issues" clause plus a concrete trigger list. This mirrors the 5 anchor (clear what + when with concrete trigger phrases); a 4 would require the 'when' to be less explicit than it is.

5 / 5

Trigger Term Quality

The explicit trigger list — "embed vs reference", "unbounded arrays", "16MB limit", "one-to-many", "tree structure", "schema validation", "time series", "TTL", "approximation pattern", "document versioning" — comprehensively covers the natural phrases a user with a MongoDB modeling problem would actually say, including synonyms ("JSON Schema" alongside "schema validation", "index explosion" alongside "unnecessary indexes"). This matches the 5 anchor's coverage-with-synonyms standard; nothing natural is obviously missing.

5 / 5

Distinctiveness Conflict Risk

The niche is clear (MongoDB schema design) and most triggers are MongoDB-specific ("16MB limit", "embed vs reference", "MongoDB data model"), giving minimal conflict risk with other skills. Broad terms like "schema validation" or "archive" carry only trivial overlap, keeping it at the 5 anchor rather than the 4 anchor's 'minor overlap risk with closely related skills'.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

boranfurkan/reproducer-hackathon

Path

skills/.agents/skills/mongodb-schema-design/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.