agentleFS
nimadorostkarnimadorostkar/Claude-Skills-collection/skills/backend/spring-boot/SKILL.md

spring-boot

Skill33 starsChanged 22 days agoMITView on GitHub

Use when building Spring Boot services. Covers dependency injection, transaction boundaries, JPA performance, configuration, validation, and testing slices. Trigger on "LazyInitializationException", "@Transactional not working", "n+1 queries with jpa", "spring tests are slow". Do not use for general Java or Kotlin language questions — see the java-kotlin skill.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Test slices: @WebMvcTest, @DataJpaTest, Testcontainers.

    line 29
  2. Distinctive:

    Never return entities from a controller.

    line 55
  3. Distinctive:

    Keep the transaction short.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Spring Boot

Purpose

Build Spring Boot services with correct transaction boundaries and a JPA layer that does not issue a hundred queries to render a list. Spring's defaults are safe; its abstractions hide the cost of getting them wrong.

When to Use

  • Building or reviewing a Spring Boot application.
  • Diagnosing lazy-loading exceptions or N+1 query behavior.
  • Getting transaction boundaries and propagation right.
  • Structuring a test suite that is faster than a full context load per class.

Capabilities

  • Constructor injection and bean lifecycle.
  • Declarative transactions: propagation, isolation, rollback rules.
  • JPA/Hibernate: fetch strategies, entity graphs, projections.
  • Configuration properties with validation and profiles.
  • Test slices: @WebMvcTest, @DataJpaTest, Testcontainers.

Inputs

  • The service, its entities, and the slow endpoint if there is one.
  • Database engine and connection pool configuration.

Outputs

  • Services with explicit transaction boundaries.
  • Repositories that fetch exactly what the caller needs.
  • Tests that load the narrowest context that proves the behavior.

Workflow

  1. Use constructor injection — Field injection with @Autowired hides dependencies and makes the class untestable without a container.
  2. Place @Transactional at the service layer — Not on the repository (too narrow, one transaction per call) and not on the controller (too wide, the transaction spans view rendering).
  3. Fetch deliberately — Every association is LAZY. Then use an entity graph or a fetch join for the specific query that needs it, and a DTO projection for read-only views.
  4. Validate configuration at startup — @ConfigurationProperties with @Validated. A missing property should prevent boot, not surface as a null at runtime.
  5. Test in slices — @DataJpaTest for repositories against Testcontainers, @WebMvcTest for controllers with mocked services, @SpringBootTest only for the handful of genuine end-to-end paths.

Best Practices

  • @Transactional on a private or self-invoked method does nothing. Spring proxies the bean; an internal call bypasses the proxy entirely. This is the most common silent transaction bug in Spring.
  • @Transactional rolls back on unchecked exceptions only, by default. A checked exception commits. Set rollbackFor deliberately.
  • FetchType.EAGER on an association is a decision made once and paid for on every query. Default to LAZY and fetch on demand.
  • Never return entities from a controller. A DTO projection avoids lazy-loading surprises and stops you leaking every column.
  • Keep the transaction short. Never make an HTTP call inside one — you are holding a database connection for the duration of someone else's outage.
  • Set connection-pool size deliberately. The default is often larger than the database can serve.

Examples

Fetch join with a projection, avoiding both N+1 and over-fetching:

public interface OrderRepository extends JpaRepository<Order, UUID> {

    @Query("""
        select new com.example.orders.OrderSummary(
            o.id, c.name, size(o.lines), sum(l.priceCents * l.quantity))
        from Order o
          join o.customer c
          join o.lines l
        where o.status = :status
        group by o.id, c.name
        """)
    List<OrderSummary> findSummaries(@Param("status") OrderStatus status);
}

Transaction boundary at the service, HTTP call outside it:

@Service
@RequiredArgsConstructor
public class RefundService {

    private final OrderRepository orders;
    private final PaymentGateway gateway;

    @Transactional(rollbackFor = Exception.class)
    public Refund record(UUID orderId, long amountCents, String gatewayRefundId) {
        Order order = orders.findById(orderId).orElseThrow(OrderNotFound::new);
        order.applyRefund(amountCents, gatewayRefundId);   // invariants live in the entity
        return order.latestRefund();
    }

    // The network call happens outside any transaction.
    public Refund refund(UUID orderId, long amountCents) {
        String gatewayRefundId = gateway.refund(orderId, amountCents);
        return record(orderId, amountCents, gatewayRefundId);
    }
}

Notes

  • spring.jpa.open-in-view defaults to true and keeps a database connection open for the entire request, including view rendering. Turn it off; the lazy-loading exceptions it then reveals are real bugs it was hiding.
  • Hibernate's @BatchSize mitigates N+1 on collections without changing the query — a useful blunt instrument when a fetch join is impractical.
  • @SpringBootTest loads the entire context. A suite of a hundred such tests is a suite that nobody runs locally.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.