313 frameworks spring db migrations flyway
Skill jabrena/plinth/skills/313-frameworks-spring-db-migrations-flyway
Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers.
npx -y skills add jabrena/plinth --skill 313-frameworks-spring-db-migrations-flywayAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Use when you need to add or review Flyway database migrations in a Spring Boot application — Maven dependencies, db/migration scripts, spring.flyway.* configuration, baseline and validation, and alignment with JDBC or Spring Data JDBC. This should trigger for requests such as Add or review Flyway migrations in a Spring Boot project; Configure spring.flyway or db/migration layout; Add versioned Flyway SQL migrations for Spring Boot; Review Spring Boot database migration ordering; Fix repeatable Flyway migrations in a Spring project. Part of Plinth Toolkit
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.3 KB, as published. Nobody here has run it
Spring — Database migrations (Flyway)
Apply Flyway migration guidelines for Spring Boot.
What is covered in this Skill?
- flyway-core and database-specific Flyway modules (e.g. PostgreSQL) with Spring Boot BOM
- Versioned SQL under
src/main/resources/db/migration(V{version}__{description}.sql) spring.flyway.*properties: locations, baseline-on-migrate, validate-on-migrate- Optional Java migrations (
BaseJavaMigration) for data backfills - Forward-only discipline: do not rewrite applied migrations in shared environments
- Parallel Change as the safe expand, migrate, contract workflow for breaking or data-sensitive schema changes
- Coordination with
@311-frameworks-spring-jdbcand@312-frameworks-spring-data-jdbc
Scope: Apply recommendations based on the reference rules and good/bad examples.
Constraints
Before applying Flyway or SQL changes, ensure the project compiles. After improvements, run full verification.
- MANDATORY: Run
./mvnw compileormvn compilebefore applying any change - SAFETY: If compilation fails, stop immediately
- VERIFY: Run
./mvnw clean verifyormvn clean verifyafter applying improvements - BEFORE APPLYING: Read the reference for detailed rules and good/bad patterns
- BREAKING CHANGE REVIEW: Before recommending or applying a migration, assess whether it can break deployed application versions, dependent services, reports, jobs, or production data interpretation; if yes, require explicit human review before proceeding
- EDGE CASE: If the user goal is ambiguous, stop and ask a clarifying question before editing files or running project-wide commands
- EDGE CASE: If required context, files, credentials, or tools are missing, report the blocker explicitly and ask whether to proceed with setup or fallback guidance
- EDGE CASE: If requested changes conflict with project constraints or safety boundaries, explain the conflict and ask for user confirmation on the preferred trade-off
When to use this skill
- Add or review Flyway migrations in a Spring Boot project
- Configure spring.flyway or db/migration layout
- Add versioned Flyway SQL migrations for Spring Boot
- Review Spring Boot database migration ordering
- Fix repeatable Flyway migrations in a Spring project
Workflow
- Read references and assess project context
Read references/313-frameworks-spring-db-migrations-flyway.md, references/313-frameworks-spring-db-migrations-flyway-antipatterns.md, and references/313-frameworks-spring-db-migrations-flyway-parallel-change.md, then inspect the current project setup before proposing changes.
- Gather scope and decide target improvements
Identify requested outcomes, constraints, and the minimum safe set of changes to apply.
- Apply framework-aligned changes
Implement or refactor configuration/code following the reference patterns and project conventions. Use Parallel Change (expand, migrate, contract) as the safe default for breaking or data-sensitive schema changes.
- Run verification and report results
Execute appropriate build/tests and summarize what changed, what was verified, and any follow-up actions.
Reference
For detailed guidance, examples, and constraints, see: