Spring Data Jpa
Add or extend Spring Data JPA entities and repositories that match your repo’s existing ID, sequence, Lombok, and fetch conventions.
Overview
Spring Data JPA is an agent skill for the Build phase that discovers existing JPA entity conventions and generates new entities that match them.
Install
npx skills add https://github.com/amplicode/spring-skills --skill spring-data-jpaWhat is this skill?
- Ordered substeps 1.1→1.5: list entities, score conventions, then apply ID/sequence/access rules
- Detects ID strategy among SEQUENCE, IDENTITY, and UUID with per-table vs shared sequence generators
- Scores annotation placement, `serialVersionUID`, lazy `@ManyToOne`, and fluent vs void setters from live code
- Uses `list_all_domain_entities` (or equivalent) to read representative entities before generating new ones
- Convention workflow uses ordered substeps 1.1 through 1.5 without skipping
Adoption & trust: 1 installs on skills.sh; 54 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You need another JPA entity but your project already has inconsistent—or unstated—rules for IDs, sequences, and mapping style.
Who is it for?
Solo developers on Spring Boot services who extend domain models and want one consistent persistence style.
Skip if: Greenfield projects with zero existing entities to inspect, or non-JVM stacks.
When should I use this skill?
Adding JPA entities or repositories and the codebase already has domain entities to mirror.
What do I get? / Deliverables
After the skill runs, new entities and repositories follow scored project conventions for ID generation, fetch type, annotations, and setters.
- New entity classes aligned to detected ID and mapping conventions
- Repository interfaces consistent with existing Spring Data patterns
Recommended Skills
Journey fit
How it compares
Use instead of generic “create JPA entity” prompts when convention detection from the repo matters more than textbook examples.
Common Questions / FAQ
Who is spring-data-jpa for?
Indie backend developers using Spring Boot and Hibernate who add entities without breaking team-wide persistence patterns.
When should I use spring-data-jpa?
Use it in Build → backend when scaffolding repositories, mirroring legacy tables, or expanding a modular monolith after listing existing domain entities.
Is spring-data-jpa safe to install?
Review the Security Audits panel on this page; the skill reads project source and may invoke listing tools—avoid running it on repos with untrusted macros or secrets in entity files.
SKILL.md
READMESKILL.md - Spring Data Jpa
# Detect Entity Conventions Follow substeps 1.1 → 1.2 → 1.3 → 1.4 → 1.5 in order. Do not skip or reorder them. --- ## Step 1.1: Find existing entities Call `list_all_domain_entities` to get a list of entities in the project. Pick 2–3 representative ones and read their source files. --- ## Step 1.2: Score each convention For each convention below, determine the answer from the code and assign a confidence score (1–100): General conventions: - **ID strategy** — check existing `@Id` fields: is it `Long` with `@GeneratedValue(strategy = SEQUENCE)` (sequence), `Long` with `@GeneratedValue(strategy = IDENTITY)` (identity/autoincrement), or `UUID` with `@GeneratedValue(strategy = UUID)` (client-generated)? Default: database-generated (`Long` + `SEQUENCE`) - **Sequence scope** — if SEQUENCE is used, check `@SequenceGenerator`: is there a dedicated sequence per table (each entity has its own `generator` name), a shared sequence across all tables (one common generator), or is `@SequenceGenerator` omitted entirely (Hibernate default sequence)? Default: dedicated sequence per table - **Annotation placement** — are `@Column`, `@Id`, etc. on fields or getter methods? Default: on fields - **`serialVersionUID`** — does any entity declare `private static final long serialVersionUID`? Default: not generated - **FetchType on @ManyToOne / @OneToOne** — check the `fetch` attribute. Default: `LAZY` - **Fluent setters** — do setters return `this` or `void`? Default: `void` - **Field access modifier** — are fields `private` or `protected`? Default: `private` - **Naming strategy** — does the project rely on JPA Implicit Naming Strategy (names omitted from `@Table`/`@Column`), or are all names explicit? Default: explicit — always name JPA objects explicitly so that no Implicit Naming Strategy affects the code - **Table name template** — check `@Table(name=...)` values: case (lower/upper/as-is), prefix, postfix, underscores, pluralized? Default: lower case, underscore, no prefix/postfix, not pluralized - **Column name template** — check `@Column(name=...)` values: case (lower/upper/as-is), prefix, postfix, underscores? Default: lower case, underscore, no prefix/postfix - **Entity class name convention** — is the Java class name transformed in any way (prefix/postfix)? Default: as-is, no transformation - **Index/constraint name case** — check `@Index(name=...)`, `@UniqueConstraint(name=...)`. Default: `lower` Constants Generation conventions (score separately): - **Constants generated?** — does any entity have `public static final String` constants for entity/table/column names? Default: no - **What is generated** — entity name constant, table name constant, column name constants? Default: all three if constants are used - **Where constants are placed** — in the same class, or in a separate nested/inner class? Default: same class Lombok conventions (score separately — only relevant if Lombok is on the classpath): - **Lombok used?** — are any Lombok annotations present on entities? Default: yes - **`@Getter` and `@Setter`** — is `@Getter`/`@Setter` on class level? Default: yes - **`@Builder`** — is `@Builder` used? Default: no - **`@AllArgsConstructor`** — is `@AllArgsConstructor` used? Default: no - **`@NoArgsConstructor`** — is `@NoArgsConstructor` used? Default: no - **`@ToString`** — is `@ToString` used? Default: no - **`@ToString(onlyExplicitlyIncluded = true)`** — is this variant used? Default: no equals & hashCode conventions (score separately): - **equals/hashCode style** — check existing `equals`/`hashCode` implementations: is it manual with `HibernateProxy` check (proxy-safe pattern), or generated via Lombok `@EqualsAndHashCode(onlyExplicitlyIncluded = true)` on specific fields (e.g. `id`)? Default: manual with HibernateProxy. If no `equals`/`hashCode` implementations are found in the project — confidence is high (90), use the default without asking. - **`@EqualsAndHashCode` fields** — if Lombok is used, which fields are included