Mcp-sub-skills

Java Spring Boot Backend Foundation

[Rule 1] Security and Environment Variables — Highest Priority

• Never directly read (Read) or modify (Write) local config files containing passwords or API tokens, such as .env, application.yml, or application.properties.
• If external environment variables are required for the project (DB URL, username, password, API keys, etc.), only request the list of required variable names in text. The actual values will be set manually by the user.
• Never hardcode actual passwords, tokens, or key values inside source code. All sensitive values must be referenced exclusively through environment variable form (process.env or @Value("${...}")).
• When creating a new project, immediately create or update .gitignore to rigorously exclude .env and related build hidden files from Git tracking.

[Rule 2] Spring Boot Architecture and Package Structure

Build system: All Java/Spring projects must use Gradle (Kotlin or Groovy DSL) as the build architecture — not Maven.

Package structure: When creating a project, never dump files into a single folder. Always separate into global (shared/common) and domain (business) structures:

src/main/java/com/example/project/
├── global/                  # Common modules shared across the entire project
│   ├── config/              # Security, Swagger, DB, WebMvc config files
│   ├── interceptor/         # Logging, auth/authorization, API call tracking interceptors/filters
│   ├── exception/           # GlobalExceptionHandler and common error response DTOs
│   └── util/                # Pure utility classes: date conversion, encryption, string processing
└── domain/                  # Core business domains (isolated by feature)
    ├── member/              # Example: member domain
    │   ├── controller/      # RestController only
    │   ├── service/         # Business logic and transaction management
    │   ├── repository/      # Spring Data JPA interfaces
    │   └── dto/             # Request / Response dedicated DTOs
    └── (other domains)/

Layered architecture separation — never violate these layer responsibilities:

• RestController: Receives client requests, validates DTOs (@Valid), returns HTTP responses. No business logic allowed.
• Service: Handles pure business transactions (@Transactional) and coordinates domain logic.
• Repository: Dedicated to database access and query mapping only.
• DTO (Data Transfer Object): Never expose Entity objects directly outside their layer. Strictly separate into request (RequestDTO) and response (ResponseDTO) classes by purpose.

Global exception handling: Define custom exceptions per domain (e.g., OrderNotFoundException) and implement global error handling using @RestControllerAdvice in the global/exception package, so internal system error logs are never exposed to users. Error responses must be unified into a consistent common JSON object format containing a code and message.

[Rule 3] Database Performance Optimization and Concurrency/Infrastructure Management

Preventing JPA N+1 problems upfront: When querying entities with associations (@ManyToOne, @OneToMany), always write JPQL/Querydsl code that considers Fetch Join or EntityGraph to prevent the N+1 problem — the primary cause of performance failures. (Global fetch strategy must use FetchType.LAZY.)

Handling large data volumes: When loading large amounts of dummy data into Supabase (PostgreSQL), never loop individual save() calls. Instead, activate JDBC batch_size settings or use dedicated Bulk Insert SQL queries.

Connection pool and resource management: When writing concurrency control logic, explicitly manage HikariCP connection pool timeouts and transaction isolation levels according to business requirements to prevent resource deadlocks. Also include the Spring Boot Actuator dependency in the base provisioning for operational metric management.

[Rule 4] README.md Automation and Storage Practice

Whenever a major stage completes (environment setup, core feature development, etc.), create or update a README.md file at the top-level root path of that project.

This README file will become the main showcase of the GitHub portfolio, so write it using Markdown syntax in a visually clean, highly readable format.

[Prompt Skill 1] Code Readability and Code Smell First-Pass Inspection

Immediately after completing Java coding, always activate self-inspection mode.

If a method exceeds 30 lines or violates the Single Responsibility Principle (SRP) by doing too many things, automatically perform refactoring by splitting it into smaller methods (Extract Method).

Find and clean up unused import statements, magic numbers (numeric constants without clear meaning), and unnecessarily duplicated ternary operators into clean code.

[Prompt Skill 2] Proactive Automation and Progress Reporting

To avoid the user having to manually type commands or handle file modifications mid-session, proactively run required tool installations, npm/Gradle builds, test executions, and similar tasks by issuing the commands directly.

However, immediately before executing a tool or applying a significant architectural change, clearly report the current action in a single-line summary (e.g., [Notice] Starting TypeScript build for the Step 1 guardrail server).

[Prompt Skill 3] Task History and Next Action Plan

Always keep the following two sections updated at the bottom of the README.md file:

Completed Work History

List the files created and core logic implemented in this stage.

Next Action Plan

Guide the user on what development tasks to continue next, and what the user needs to manually verify or configure, so they can transition smoothly to the next stage.