Maps & Geo

316-frameworks-spring-mongodb-migrations-mongock - Claude MCP Skill

Use when you need to add or review Mongock MongoDB data migrations in a Spring Boot application — including Maven coordinates, Spring Data MongoDB drivers, migration scan packages, @ChangeUnit classes, lock/transaction settings, and optional policy-approved MongoDB integration verification. This should trigger for requests such as Add Mongock migrations in Spring Boot; Review Spring MongoDB data migrations; Configure Mongock change units for Spring Data MongoDB; Create Mongock change units for Spring Boot MongoDB; Review Mongock migration ordering in a Spring service. Part of Plinth Toolkit

SEO Guide: Enhance your AI agent with the 316-frameworks-spring-mongodb-migrations-mongock tool. This Model Context Protocol (MCP) server allows Claude Desktop and other LLMs to use when you need to add or review mongock mongodb data migrations in a spring boot application — in... Download and configure this skill to unlock new capabilities for your AI workflow.

🌟3 stars • 91 forks
📥0 downloads

Documentation

SKILL.md
# Spring - MongoDB migrations (Mongock)

Apply Mongock migration guidelines for Spring Boot and Spring Data MongoDB.

**What is covered in this Skill?**

- Mongock BOM, Spring Boot runner, and Spring Data MongoDB driver coordinates
- `mongock.migration-scan-package` configuration and startup execution
- Code-first `@ChangeUnit` migrations with `@Execution` and rollback hooks
- Locking, idempotency, transaction limits, and forward-only rollout discipline
- Optional MongoDB-backed integration tests using only project-approved, pinned, or already-available container images when the user permits external runtime dependencies
- Coordination with `@315-frameworks-spring-mongodb`

**Scope:** Apply recommendations based on the reference rules and good/bad examples.

## Constraints

Compile before Mongock or MongoDB migration changes; verify after changes.

- **MANDATORY**: Run `./mvnw compile` or `mvn compile` before applying any change
- **SAFETY**: If compilation fails, stop immediately
- **VERIFY**: Run `./mvnw clean verify` or `mvn clean verify` after applying improvements
- **BEFORE APPLYING**: Read the reference for detailed rules and good/bad patterns
- **EDGE CASE**: If the project Spring Data MongoDB version is not compatible with the selected Mongock driver, stop and ask whether to pin/upgrade Mongock or use a lower driver generation
- **EXTERNAL RUNTIME GATE**: Do not pull or execute Docker images for MongoDB verification unless the user explicitly approves and the image is pinned, policy-approved, or already present in the project configuration

## When to use this skill

- Add Mongock migrations in Spring Boot
- Review Spring MongoDB data migrations
- Configure Mongock change units for Spring Data MongoDB
- Create Mongock change units for Spring Boot MongoDB
- Review Mongock migration ordering in a Spring service

## Workflow

1. **Read references and inspect MongoDB setup**

Read `references/316-frameworks-spring-mongodb-migrations-mongock.md`, `references/316-frameworks-spring-mongodb-migrations-mongock-antipatterns.md`, and `references/316-frameworks-spring-mongodb-migrations-mongock-parallel-change.md`, then inspect `pom.xml`, Spring Boot version, dependency management, MongoDB configuration, existing full-context tests, and existing `@315-frameworks-spring-mongodb` persistence patterns.

2. **Choose runner, driver, and execution policy**

Select Mongock coordinates compatible with the active Spring Data MongoDB generation, configure migration scan packages, and decide startup vs controlled-job execution.

3. **Apply framework-aligned migrations**

Implement/refactor `@ChangeUnit` classes with idempotent operations, explicit ordering, rollback hooks, and safe lock/transaction settings.

4. **Run verification and report results**

Execute build/tests. Run MongoDB-backed migration checks only when the project already defines an approved MongoDB test runtime or the user explicitly approves a pinned container image. If generic `@SpringBootTest` smoke tests do not provide MongoDB, disable Mongock only for those tests with `mongock.enabled=false`. Summarize outcomes and follow-up risks.

## Reference

For detailed guidance, examples, and constraints, see:

- [references/316-frameworks-spring-mongodb-migrations-mongock.md](references/316-frameworks-spring-mongodb-migrations-mongock.md)
- [references/316-frameworks-spring-mongodb-migrations-mongock-antipatterns.md](references/316-frameworks-spring-mongodb-migrations-mongock-antipatterns.md)
- [references/316-frameworks-spring-mongodb-migrations-mongock-parallel-change.md](references/316-frameworks-spring-mongodb-migrations-mongock-parallel-change.md)

Signals

Avg rating0.0
Reviews0
Favorites0

Information

Repository
jabrena/cursor-rules-java
Author
jabrena
Last Sync
9/5/2026
Repo Updated
9/4/2026
Created
6/16/2026

Reviews (0)

No reviews yet. Be the first to review this skill!

Related Skills

cursorrules

CrewAI Development Rules

43932Has guide

mem0-test-integration

Verify a Mem0 integration produced by /mem0-integrate. Runs in the same workspace on the same branch (loose coupling) — installs dependencies, runs the repo's native test suite, then exercises a real end-to-end smoke flow against the user's API key. Produces a scorecard. TRIGGER when: user has just run /mem0-integrate and says "verify", "test the integration", "run /mem0-test-integration", or when a .mem0-integration/ directory exists and tests have not been run yet on the current branch. DO NOT TRIGGER when: the user wants to run general project tests (defer to the repo's native test command), or when no prior /mem0-integrate run exists in the current branch (ask them to run /mem0-integrate first). This skill ONLY catches compile and runtime bugs by design. Logical integration errors — wrong data stored, wrong time retrieved, wrong user scoping — are on the human reviewer.

10787

mem0-oss-to-platform

Plan and then execute a migration of a project from the mem0 open-source / self-hosted SDK (the local `Memory` class) to the mem0 Platform / hosted / managed SDK (the `MemoryClient` class). Use this whenever a developer wants to move, switch, or migrate their mem0 usage off OSS/self-hosted to the hosted API — e.g. "migrate my mem0 setup to the platform", "switch from self-hosted mem0 to MemoryClient", "use my mem0 API key instead of a local Qdrant", "move mem0 to the cloud/hosted/managed service", or "replace my local mem0 vector store + embedder config with the platform". Applies to Python (`from mem0 import Memory` → `from mem0 import MemoryClient`) and TypeScript/JavaScript (`import { Memory } from "mem0ai/oss"` → `import MemoryClient from "mem0ai"`). Trigger even when the user doesn't say the word "migrate" but clearly wants their existing mem0 integration to run against the hosted platform. It first produces a reviewable migration plan, then executes it after the developer approves. Strictly scoped to the mem0 integration — it does not refactor, restructure, or "improve" any unrelated code.

10787

update-chrome-binaries-test-region

- Confirm the AWS CLI is logged into account `678892195805` by running `aws sts get-caller-identity`. If not, ask the user to log in.

6396

Related Guides