/SKILL.md
Creates Java + Spring Boot projects: Web applications, full-stack apps with Vue.js or Angular or React or vanilla JS, PostgreSQL, REST APIs, and Docker. Use when creating Spring Boot projects, setting up Java microservices, or building enterprise applications with the Spring Framework.
npx skillsauth add jdubois/dr-jskill dr-jskillInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This agent skill helps you create Spring Boot projects following Julien Dubois' best practices. It provides tools and scripts to quickly bootstrap Spring Boot applications using https://start.spring.io.
Recommended model: Dr JSkill works best with GPT-5.5.
Centralized versions live in versions.json. All scripts read from it via scripts/lib/versions.mjs (JavaScript). Update this file to bump Java, Spring Boot fallback, Postgres, Node/npm, Testcontainers, etc.
This skill includes cross-platform JavaScript (Node.js) scripts in the scripts/ directory that can be used to download pre-configured Spring Boot projects from start.spring.io. They work on Linux, macOS, and Windows.
Unified launcher (cross-platform):
node scripts/create-project my-app com.myco my-app com.myco.myapp 21 fullstack --output-dir /absolute/path/to/user/workspace
Direct invocation:
node scripts/create-project-latest.mjs my-app com.myco my-app com.myco.myapp 21 fullstack --output-dir /absolute/path/to/user/workspace
Flags supported:
--boot-version <x.y.z> / -BootVersion: override Spring Boot version--project-type basic|web|fullstack / -ProjectType--output-dir <absolute-path>: create the generated project folder under this directoryOutput directory rule (important for Agent Skills): bundled scripts are run from the skill directory root. When the user asks to create an app, pass --output-dir with the user's current working directory from the agent session so the generated project folder is created in the user's workspace, not inside the dr-jskill skill folder. Only omit --output-dir when running Dr JSkill's own tests, where generating inside the skill checkout is intentional.
Tip: The
create-project-latestscript auto-resolves preferred Boot 4.x and falls back to the configuredspringBootFallbackif 4.x is not yet available. Override with--boot-versionif needed.
Use the create-project-latest.mjs script to create a project with the latest Spring Boot version (automatically fetched):
node scripts/create-project-latest.mjs my-app com.mycompany my-app com.mycompany.myapp 21 web
Project types available:
basic - Minimal Spring Boot projectweb - Web application with REST API capabilitiesfullstack - Complete application with database and securityUse the create-basic-project.mjs script to create a basic Spring Boot project with essential dependencies:
node scripts/create-basic-project.mjs
Use the create-web-project.mjs script to create a Spring Boot web application with web dependencies:
node scripts/create-web-project.mjs
Use the create-fullstack-project.mjs script to create a comprehensive Spring Boot application with database, security, and web dependencies:
node scripts/create-fullstack-project.mjs
When creating Spring Boot projects:
create-project-latest.mjs script automatically fetches it.gitignore, .env.sample, .editorconfig, .gitattributes, .dockerignore, optional .vscode/, .devcontainer/ - see Project Setup & Dotfiles
.env file is the canonical location for local secrets; instruct users to copy .env.sample → .env and fill in real values.env: it contains real secrets — do not cat, view, or print its contents; only .env.sample (placeholder values) may be read or displayedspring-boot-docker-compose for automatic database startup during development - see Docker GuideGenerated projects integrate with the Eclipse JDT Language Server (JDTLS) so AI agents can navigate, refactor, and diagnose Java code semantically rather than with text search. The scripts ship a .github/lsp.json that wires JDTLS into GitHub Copilot CLI automatically.
For the AI agent: when working on Java files, prefer the lsp tool over grep/view/sed. It understands imports, generics, inheritance, and Javadoc.
| Task | Use |
|------|-----|
| Find where a class/method is defined | lsp goToDefinition |
| Find callers before changing a signature | lsp findReferences or incomingCalls |
| Look up types, parameters, Javadoc | lsp hover |
| List symbols in a file | lsp documentSymbol |
| Search a class/method across the project | lsp workspaceSymbol |
| Rename safely across files | lsp rename (never sed) |
| Check compile errors before ./mvnw verify | ide-get_diagnostics |
Preference order for Java work: lsp → grep with .java glob → view.
Install JDTLS once: brew install jdtls (or see JDTLS guide for other platforms). Full setup, gotchas, and editor integrations live in references/JDTLS.md.
The service layer is only included if it adds value (e.g. complex business logic). For simple CRUD applications, the controller can directly call the repository.
Generated projects follow the following recommended structure:
my-spring-boot-app/
├── .gitignore # Java + front-end + secrets (see references/PROJECT-SETUP.md)
├── .env.sample # Template for local env vars; .env is gitignored
├── .editorconfig # Consistent formatting across IDEs
├── .gitattributes # Normalize line endings, better diffs
├── .dockerignore # Slim Docker build contexts
├── .vscode/ # Optional editor recommendations
│ ├── extensions.json
│ └── settings.json
├── .devcontainer/ # Optional Dev Container (Java 25 + Node 24 + PostgreSQL)
│ ├── devcontainer.json
│ └── docker-compose.yml
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/example/app/
│ │ │ ├── Application.java
│ │ │ ├── config/
│ │ │ ├── controller/
│ │ │ ├── service/ # Only included if needed
│ │ │ ├── repository/
│ │ │ └── domain/
│ │ └── resources/
│ │ ├── static/ # Front-end web assets (HTML, CSS, JS)
│ │ │ ├── index.html
│ │ │ ├── css/
│ │ │ │ └── styles.css
│ │ │ ├── js/
│ │ │ │ └── app.js
│ │ │ └── images/
│ │ └── application.properties
│ └── test/
│ └── java/
│ └── com/example/app/
│ ├── config/
│ ├── controller/
│ ├── service/ # Only included if needed
│ ├── repository/
│ └── domain/
├── Dockerfile # Standard JVM Docker build
├── Dockerfile-native # GraalVM native image build
├── compose.yaml # Dev database (spring-boot-docker-compose)
├── docker-compose.yml # Full stack with PostgreSQL
├── docker-compose-native.yml # Native image with PostgreSQL
├── pom.xml
└── README.md
Generated projects include: Spring Web, Spring Data JPA, Spring Boot Actuator, DevTools, PostgreSQL, Validation, Docker Compose support, Test Starter with JUnit 5, and TestContainers.
Use .properties files (not YAML), externalize secrets via environment variables, and leverage @ConfigurationProperties for type safety. See the Configuration Guide for profiles, secrets management, and common patterns.
The .env file is the single local secret store — never read or print it; only .env.sample (placeholder values) may be shown.
For database optimization, see the Database Best Practices Guide.
Spring Security is optional - only add it when you need authentication or authorization. See the Security Guide for JWT, OAuth2, role-based access, and CORS configuration.
See the Testing Guide for unit tests (Mockito, @WebMvcTest), integration tests (TestContainers + @ServiceConnection), and Given-When-Then patterns with AssertJ.
Choose a front-end framework:
All options include: Vite/CLI dev server with hot reload, Bootstrap 5.3+, SPA routing, and automatic build into the Spring Boot JAR.
When wiring the frontend-maven-plugin, bind the Node install, npm install, and npm run build executions to the generate-resources phase. This makes ./mvnw spring-boot:run build the frontend before Spring Boot starts, instead of only building it during explicit package-oriented commands.
Non-interactive scaffolding (important for CI and AI agents). Two separate prompts must be silenced:
- npm's own "Ok to proceed?" install prompt — silence by placing
-ybefore the package name (flags after--go to the scaffolder, not to npm). Usenpm create -y vite@latest …ornpx --yes create-vite@latest ….- The scaffolder's own prompts — create-vite 9.x and Angular CLI 22 still pose interactive questions (e.g. "Use rolldown-vite?", analytics opt-in) that
-y/--yesdo not silence. The reliable fix is to close stdin: pipeecho |into the command so the scaffolder immediately sees EOF and accepts defaults.Canonical recipes:
- React / Vanilla:
echo | npx --yes create-vite@latest frontend --template react(or--template vanilla)- Vue:
npm create -y vue@latest frontend -- --router --pinia --vitest --eslint --prettier(create-vue does not pose extra prompts)- Angular:
echo | npx --yes @angular/cli@22 new frontend --style=css --ssr=false --skip-git --defaults --skip-install, thennpm installVitest + callback Vite config. If
vite.config.jsexportsdefineConfig(({ mode }) => ...), do not let the generatedvitest.config.jscallmergeConfig(viteConfig, ...). Resolve the callback first withviteConfig({ mode: 'test', command: 'serve' }); otherwise Vitest fails withCannot merge config in form of callback. See Vue.js Guide.
Spring Boot automatically manages Docker containers during development via spring-boot-docker-compose. For production, use the provided Dockerfile (JVM) or Dockerfile-native (GraalVM). See the Docker Guide for full setup, health checks, and deployment patterns.
Build native images via Docker (no local GraalVM needed) or locally with ./mvnw -Pnative -DskipTests package native:compile. See the GraalVM Guide for configuration, runtime hints, testing, and CI/CD integration.
Deploy to Azure Container Apps with an optional VNET-injected Azure Database for PostgreSQL Flexible Server. Uses GitHub Container Registry (GHCR) for image storage (pushed via GITHUB_TOKEN in CI, pulled by Container Apps using a stored PAT) and Container Apps secrets for the DB password — no secrets in source, env dumps, or shell history. Includes a GitHub Actions OIDC workflow, and supports both the JVM and GraalVM native image variants. See the Azure Deployment Guide.
| # | What | Command |
|---|------|---------|
| 1 | Build backend | ./mvnw clean install |
| 2 | Unit tests | ./mvnw test |
| 3 | Integration tests | ./mvnw verify (uses Testcontainers 2 + @ServiceConnection) |
| 4 | Front-end dev server | cd frontend && npm run dev |
Run validation steps first. If anything fails, fix before proceeding.
Once the project is generated, go through the steps above to ensure that the generated project is fully functional and follows best practices. If any validation step fails, try to identify the issue and fix it before proceeding. This ensures that the generated project is of high quality and ready for development.
Core Spring Boot:
Data and Persistence:
Security (Optional):
Testing:
Front-End Development:
Project Setup:
.gitignore, .env.sample, .editorconfig, .gitattributes, .dockerignore, .devcontainer/Deployment:
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
development
Run, watch, debug, and extend OpenClaw QA testing with qa-lab and qa-channel. Use when Codex needs to execute the repo-backed QA suite, inspect live QA artifacts, debug failing scenarios, add new QA scenarios, or explain the OpenClaw QA workflow. Prefer the live OpenAI lane with regular openai/gpt-5.4 in fast mode; do not use gpt-5.4-pro or gpt-5.4-mini unless the user explicitly overrides that policy.
development
End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip verification under Parallels.