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.
Works with
--- name: code-reviewer description: 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. license: MIT --- # Java 25 and Spring Boot 4 Reviewer ## Purpose Use this skill to run a structured review of Java 25 and Spring Boot 4 code. Keep findings grounded in the actual codebase and use the reference files only for the focus areas that apply. ## Critical rules - Never review without code context. Ask for files, diffs, or the relevant module if none is provided. - Always cite file paths and line numbers for findings. - Treat Java 25 and Spring Boot 4 as the target baseline unless the build files show otherwise. - Analyze workload before recommending virtual threads, reactive rewrites, or architecture changes. - Use JSpecify as the preferred null-safety baseline for new Boot 4 code, but confirm whether the codebase is still in transition before flagging every legacy annotation. - Prefer official Spring and Java guidance when a claim depends on framework behavior. ## Workflow ### Step 1: Confirm scope Collect the minimum context required to review accurately: 1. Scope: single file, module, PR, or full codebase. 2. Target versions: confirm Java and Spring Boot versions from the build files when relevant. 3. Focus areas: migration, architecture, data access, security, performance, null-safety, or all. 4. Testing context: whether the user expects review findings only or also fix suggestions and test impact. ### Step 2: Load only the references that match the review Load references just in time: | Focus | Read | |------|------| | Spring Boot 4 migration patterns and framework deltas | `references/spring-boot-4-patterns.md` | | Java 25 language and concurrency adoption | `references/java-25-features.md` | | Security review | `references/security-checklist.md` | | Performance review | `references/performance-patterns.md` | | Architecture boundaries and packaging | `references/architecture-patterns.md` | | Domain model shape | `references/domain-modeling.md` | | Value-object-heavy designs | `references/value-objects-patterns.md` | | Null-safety checks | `references/jspecify-null-safety.md` | Escalate to another skill when needed: - Use `spring-data-jpa` for deep repository, query, and relationship work. - Use `springboot-migration` for phased upgrade planning or upgrade execution. ### Step 3: Run the review passes Run only the passes that match the request. For a full review, use this order. #### Pass A: Build and configuration - Verify Java and Spring Boot versions in `pom.xml` or `build.gradle`. - Check starter names and migration leftovers. - Scan for Jackson 3 migration issues, outdated test annotations, and version drift. #### Pass B: API correctness - Check controller and service boundaries. - Check validation and error handling. - Check nullability in public APIs and method overrides. #### Pass C: Architecture and packaging - Identify the architecture style in use. - Verify package structure is consistent with that style. - Flag boundary leaks such as controller-to-repository shortcuts or infrastructure types in domain code. #### Pass D: Data access - Check repository placement and aggregate boundaries. - Check for N+1 queries, missing pagination, projection mismatches, and transaction misuse. #### Pass E: Security - Check authentication and authorization. - Check input validation and unsafe query patterns. - Check secrets handling and sensitive logging. #### Pass F: Performance and resilience - Check caching strategy, unbounded reads, async usage, and remote call behavior. - Evaluate virtual-thread usage only when the code and workload justify it. - Check timeouts, retries, and connection-pool assumptions. ## Quick triggers for findings Use these as review prompts, not as a substitute for code evidence. ### Spring Boot 4 and migration - old starter names - old Mockito test annotations - Jackson 2 assumptions in a Boot 4 codebase - `TestRestTemplate` usage instead of `RestTestClient` - manual `HttpServiceProxyFactory` boilerplate instead of `@ImportHttpServices` - custom API versioning instead of native `spring.mvc.apiversion.*` - `@ConcurrencyLimit` or native `@Retryable` without `@EnableResilientMethods` ### Null-safety - missing `package-info.java` where the project uses JSpecify - lingering `org.springframework.lang` annotations in code that has already moved to JSpecify - missing copied nullability annotations on overrides ### Architecture - controllers calling repositories directly - JPA entities exposed in APIs - modulith boundary leaks - business logic concentrated in controllers ### Performance - entity traversal in loops - missing pagination - projection opportunities ignored on read-heavy paths - virtual-thread recommendations with no workload evidence ### Security - missing authorization on privileged actions - SQL or NoSQL injection risk - secrets in source or logs - unsafe error exposure ## Report format Order findings by severity and use this template: ```markdown ## Critical - **[Category]**: Issue summary - **File**: `path/to/File.java:123` - **Impact**: What can fail, leak, or regress - **Fix**: Specific change to make ## High - ... ## Medium - ... ## Low - ... ``` If there are no findings, say so explicitly and call out any remaining blind spots such as unreviewed modules, missing tests, or unavailable runtime context. ## Common review modes ### Quick PR review 1. Read the changed files. 2. Load `references/spring-boot-4-patterns.md` and `references/java-25-features.md`. 3. Add `references/security-checklist.md` or `references/performance-patterns.md` if the diff touches those areas. 4. Report only concrete findings with file and line references. ### Security review 1. Read `references/security-checklist.md`. 2. Focus on controllers, service entry points, security configuration, and persistence boundaries. 3. Report exploitability and affected entry points, not just the violated rule. ### Architecture review 1. Read `references/architecture-patterns.md`. 2. Add `references/domain-modeling.md` or `references/value-objects-patterns.md` if the code suggests a rich-domain approach. 3. Report boundary mismatches and coupling problems tied to the current architecture style. ### Migration review 1. Read `references/spring-boot-4-patterns.md` and `references/java-25-features.md`. 2. Focus on migration leftovers, outdated APIs, and partial adoption problems. 3. Use `springboot-migration` if the user wants a phased upgrade plan rather than a review. ## When not to use this skill - Kotlin-first codebases - Non-Spring Java frameworks such as Micronaut or Quarkus - Generic review coaching without code context - Frontend-only changes
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.

