Designs and implements Spring Data JPA repositories, projections, query patterns, custom repositories, CQRS read models, entity relationships, and persistence performance fixes for Java 25 and Spring Boot 4 projects. Use when the task needs repository-boundary decisions or concrete JPA implementation patterns from this skill. Do not use for generic SQL help or project-wide migration work that belongs in another skill.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
name: spring-data-jpa description: Designs and implements Spring Data JPA repositories, projections, query patterns, custom repositories, CQRS read models, entity relationships, and persistence performance fixes for Java 25 and Spring Boot 4 projects. Use when the task needs repository-boundary decisions or concrete JPA implementation patterns from this skill. Do not use for generic SQL help or project-wide migration work that belongs in another skill.
Spring Data JPA Implementation
Purpose
Use this skill when the task is specifically about persistence design or implementation in a Spring Boot codebase. This skill adds value through aggregate-root guidance, query-pattern selection, CQRS read-model decisions, and the bundled repository and relationship templates.
Critical rules
- Never create repositories for every entity. Create repositories only for aggregate roots.
- Never rely on long derived query method names when the query has become non-trivial.
- Never use
save()blindly when entity state transitions matter; understand persist versus merge behavior. - Prefer projections or dedicated query services for read-heavy paths.
- Keep transaction boundaries in the service layer unless the existing architecture intentionally does otherwise.
Workflow
Step 1: Identify the persistence problem
Collect the minimum context first:
- Is the type an aggregate root or an internal entity?
- Is the task primarily read-side, write-side, or both?
- Is the query simple lookup, filtered search, aggregation, projection, or dynamic criteria?
- Is the path performance-sensitive?
- Are there module-boundary or loose-coupling constraints that affect relationship modeling?
Step 2: Choose the implementation pattern
Use this table to decide what to load next.
| Pattern | Use when | Read |
|---|---|---|
| Simple repository | Basic CRUD and 1-2 simple lookups | Existing code or none |
@Query repository | Multiple filters, joins, sorting, readable JPQL | references/query-patterns.md |
| DTO projection | Read-only and performance-critical responses | references/dto-projections.md |
| Custom repository | Criteria API, bulk operations, EntityManager logic | references/custom-repositories.md |
| CQRS query service | Separate read and write models, reporting, specialized read paths | references/cqrs-query-service.md |
Use this decision guide:
| Need | Simple | @Query | DTO | Custom | CQRS |
|---|---|---|---|---|---|
| Basic CRUD | Yes | Yes | No | Yes | Yes |
| Custom filters | No | Yes | Yes | Yes | Yes |
| Best read performance | No | Sometimes | Yes | Sometimes | Yes |
| Complex dynamic logic | No | No | No | Yes | Yes |
| Clear read/write split | No | No | Sometimes | Sometimes | Yes |
Step 3: Load the matching reference
Load only the references needed for the current task:
references/query-patterns.mdreferences/dto-projections.mdreferences/custom-repositories.mdreferences/cqrs-query-service.mdreferences/relationships.mdreferences/performance-guide.md
Step 4: Apply the matching asset
Use the bundled templates in assets/ instead of rebuilding the pattern from scratch:
assets/query-repository.javaassets/dto-projection.javaassets/custom-repository.javaassets/query-service.javaassets/relationship-patterns.java
Step 5: Validate relationships and transaction boundaries
Before finalizing the change, check:
- repository exists only at the aggregate-root boundary
- lazy-loading behavior is intentional
- pagination or projections are used where row counts can grow
@ManyToManyhas not been introduced when a join entity is more appropriate- read services use
@Transactional(readOnly = true)where appropriate - write operations stay in service-layer transactions
Step 6: Validate performance-sensitive paths
Read references/performance-guide.md when the task includes:
- N+1 risks
- fetch-plan problems
- unbounded queries
- batch operations
- heavy read views that should use projections
High-value patterns to prefer
Repository boundaries
- Aggregate roots get repositories.
- Internal child entities usually do not.
Query style
- Use derived query methods for simple lookups.
- Use
@Queryfor joins, readable text blocks, or multiple filters. - Use DTO projections when the response does not need entities.
- Use a CQRS query service when the read model differs from the write model.
Relationships
- Prefer
@ManyToOneover@OneToManywhen possible. - Use IDs instead of entity references when loose coupling is more important than navigation.
- Treat
@ManyToManyas a warning sign; prefer an explicit join entity.
Output format
When proposing or implementing a persistence change, return:
## Recommended pattern
- Pattern:
- Why:
## Files to change
- `path/to/file`
## References used
- `references/...`
## Risks to verify
- ...
When not to use this skill
- Generic SQL or database administration work outside Spring Data JPA
- Whole-project migration planning
- Broad project scaffolding that belongs in
creating-springboot-projects
More by a-pavithraa
View allMigrates Spring Boot applications to Boot 4 with Java 25, including related Spring Modulith 2 and Testcontainers 2 upgrade work. Use when the task is a concrete upgrade, dependency transition, starter rename, test-annotation migration, or phased migration plan. Do not use for greenfield project creation or for isolated repository design questions.
Creates Java 25 and Spring Boot 4 project structures, scaffolds, and implementation starting points for new services, REST APIs, and modular backends. Use when the task is to initialize a Spring Boot project, choose an architecture, select Spring Boot 4 features, or apply the bundled templates and references in this skill. Do not use for migrating existing projects or for isolated JPA/repository work without broader project-creation context.
code-reviewer: Reviews Java 25 and Spring Boot 4 codebases, pull requests, files, and modules for migration risks, architecture boundary violations, JSpecify null-safety issues, security flaws, performance regressions, and Spring Data pitfalls. Use when the task is a concrete Java or Spring code review with code context. Do not use for Kotlin-only code, non-Spring frameworks, or generic review advice without files or diffs.
