A coding agent already knows what idiomatic Django, Spring Boot and Laravel look like. That is exactly the problem. Ask it to model a domain object in Kotlin and it will reach for a data class, because that is what idiomatic Kotlin says — kotlin-idioms states the rule plainly, "data class for DTOs and domain objects", and never mentions JPA or Hibernate anywhere. Attach that object to Hibernate and the generated all-field equals/hashCode corrupts Set membership the moment a field changes, and copy() starts minting detached duplicates of managed entities. The convention was right. It was right about the wrong layer, and nothing in a conventions document knows which layer you are in.
Which makes a promise of best practices the cheapest thing a document like this can offer, and a poor way to choose between them. A far better test: does the document force the agent to establish a fact — the project's language version, the actual query count, a green build, a reproduction — before it writes or asserts anything? Sorted that way, the field thins out fast.
Top picks
| skill | publisher | license | verdict | updated |
|---|---|---|---|---|
| django-perf-review | getsentry | Apache-2.0 | Gate: proof before it reports a finding | 2026-07-27 |
| laravel-11-12-app-guidelines | thienanblog | Apache-2.0 | Gate: stack detection before it edits | 2026-07-15 |
| laravel-systematic-debugging | iSerter | MIT | Gate: root cause before it fixes | 2026-04-19 |
| kotlin-backend-jpa-entity-mapping | Kotlin | Apache-2.0 | Gate: SQL logs before it blames | 2026-07-21 |
| spring-boot-project-creator | giuseppe-trisciuoglio | MIT | Gate: green build before it hands over | 2026-06-22 |
| php-best-practices | AsyrafHussin | MIT | Gate: version check before it advises | 2026-05-16 |
Django performance: the reviewer that is allowed to find nothing
django-perf-review ranks issues by impact — N+1 queries and unbounded querysets as CRITICAL, missing indexes and write loops as HIGH, style-level inefficiency as LOW and "Rarely worth reporting" — then makes each one earn its place. Before reporting anything it must trace the queryset from view to template or serializer, grep the codebase for existing select_related/prefetch_related, confirm the table is actually large, confirm the path is hot, and rule out caching. "If you cannot validate all steps, do not report."
The payoff is the section that follows the rules: named false positives. A single list() call is not an N+1. A one-object fetch that costs two queries is not CRITICAL. "Pattern matching is not validation", and "Zero findings is acceptable". A generalist like Jeffallan's django-expert lists select_related/prefetch_related among its MUST-DO items and signs off with a brief note on query optimization; the reason to reach for django-perf-review instead is that gate — it has to trace the queryset and confirm the table is hot before it may report, where the generalist only recommends. Caveat: its allowed-tools are Read, Grep, Glob, Bash, Task — no Write or Edit — so it proposes a fix but never applies one.
Laravel: read the repo before you touch it
laravel-11-12-app-guidelines opens on instructions rather than conventions. Its first Quick Start bullet reads "Read repository instructions first: AGENTS.md"; its second, "Detect the stack and command locations; do not guess." It inspects composer.json, package.json, docker-compose.* and config/* to settle four questions before editing — Sail or host commands, API-only or full-stack, which frontend framework, which auth stack — then targets the Laravel 11/12 layout specifically: middleware, exceptions and routes in bootstrap/app.php, providers in bootstrap/providers.php. Pixel-Process's laravel-specialist also opens with a discovery phase, but it catalogues installed packages and the Laravel version and then assumes commands run on the host; this one settles Sail-vs-host and the exact 11/12 file layout before it touches anything.
It also carries a warning that costs real data if you miss it: "When altering columns, include all existing attributes in the migration to avoid dropping them." Caveat: several steps lean on Laravel Boost's MCP tools, with Context7 named as the fallback.
Laravel debugging: a stop rule, not a style guide
laravel-systematic-debugging is four phases with a hard gate on the first: "NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST". Phase 1 is concrete work, not attitude — tail storage/logs/laravel.log, run php artisan migrate:status and php artisan config:show to catch stale config, reproduce in tinker, and hang a DB::listen callback to log SQL, bindings and timing. Phase 3 forces one hypothesis and one changed variable.
What makes it worth installing is Phase 4's escape hatch. Count your failed fixes; at three, stop changing code and question whether the pattern itself is wrong. Its sibling laravel-tdd from the same publisher drives new code test-first — RED, verify RED, GREEN — but carries no root-cause gate and no such stop rule; systematic-debugging is the one to reach for on an existing failure. Caveat: it hands off by name to sibling agents — laravel-debugger, laravel-testing-expert, eloquent-specialist, laravel-performance-optimizer — you may not have installed.
Kotlin and JPA: the trap general Kotlin advice walks into
kotlin-backend-jpa-entity-mapping is the corrective to the opening problem, and it is specific about the fix rather than the ban. Use a regular class; compare by ID only; return a class-based constant from hashCode so Set membership survives a persist; keep lazy relations out of toString so debug logging cannot trigger LazyInitializationException; model the unsaved row as var id: Long? = null with a protected set rather than a 0L sentinel; and check that the project actually enables the JPA no-arg compiler plugin.
Its diagnostic rule is the reason it belongs here: "Diagnose N+1 by looking at actual query count or SQL logs, not by guessing from annotations." Caveat: Kotlin plus Spring Data JPA only — for Java, jpa-patterns covers the same ground with JOIN FETCH, @EntityGraph and @BatchSize.
Spring Boot: scaffolding that ends in a passing build
spring-boot-project-creator is a runnable procedure, not a pattern essay. It asks for group, artifact, boot version, Java version and data stores, then curls a real starter zip from start.spring.io with an explicit dependency list, adds SpringDoc OpenAPI and ArchUnit to the POM, lays out either Layered or DDD packages, writes application.properties per selected store, generates a docker-compose.yaml with pinned images, and appends .env to .gitignore.
Step 9 is the one that matters: run ./mvnw clean verify and fix the failure before handing over. It is also honest about its own limits — "Spring Initializr requires internet access — this skill cannot work offline." Jeffallan's spring-boot-engineer hands you a copy-paste skeleton — entity, repository, service, controller, record DTO, exception handler — bounded by MUST DO / MUST NOT DO rules; project-creator does the heavier thing, generating a real project from start.spring.io and refusing to hand it over until that ./mvnw clean verify passes. Caveat: the pinned dependency versions and the dev-only ddl-auto=update setting will age.
PHP: detect the version, then advise
php-best-practices puts the check ahead of everything else. Step one reads the required PHP version out of composer.json, confirms it against php -v, and maps features to versions — enums and readonly properties at 8.1, readonly classes at 8.2, typed class constants and #[\Override] at 8.3, property hooks and asymmetric visibility at 8.4, the pipe operator at 8.5. "Never suggest syntax that doesn't exist in the project's version."
That table checks out against an independently written source: on the nine features where php also states a version, the two agree on all nine. That same xobotyi skill is also the alternative you would pass over here: it fixes a flat PHP 8.5+ baseline and tells the agent to modernize unconditionally, never reading composer.json — so on any project not already on the latest PHP, php-best-practices' version gate is the reason to prefer it. Caveat: this file is an index whose 51 rules are one line each; the worked examples live in the rules/*.md files it points at.
How do you tell two skills with the same name apart?
Skill names are community-chosen and nothing namespaces them, so a name tells you the topic and nothing else. The publisher and the body are the identity. Two worked examples from this area:
A skill called php can be any of several unrelated documents; the only way to know which one you are holding is to read it. xobotyi's sets PHP 8.5+ as the baseline and tells the agent to use modern syntax unconditionally, formats to PER-CS, and routes code navigation to an Intelephense LSP rather than grep. The identically named php from miles990 is a worked-example catalogue for 7.4+/8.x — attributes, traits, a hand-rolled DI container. xobotyi's does carry escape clauses — follow the codebase where it contradicts a convention, keep older-version support where the project requires it — but nothing in it sends the agent to read composer.json first, so pointed at a codebase pinned to PHP 8.1 it can reach for syntax the runtime cannot parse.
A skill called django-patterns can be the same document twice. django-patterns declares origin: ECC in its front matter, and so does django-patterns; their outlines run 28 headings each, in the same order and at the same levels, with the second rendered bilingually in Chinese and English. Pick by the language your team reads, not by the name. django-patterns shares the name and is a genuinely different document — 8 headings, closing on an anti-pattern list and a checklist the other two do not carry.
So: open the body, read the first screen, and check the version baseline and the outline before you decide you have the skill you wanted.
What to check before you install
Three fields lie more often than they help.
License. What a directory shows you is usually the repository's license, not the file's. django-perf-review carries license: LICENSE in its own front matter — a pointer to a file, not an identifier — while its record reads Apache-2.0 from the repo. Plenty of files carry no license line at all. If you plan to vendor a skill, read the repository's LICENSE.
Author. The author key in front matter is a self-declared string with nothing verifying it. php-best-practices declares author: php-community; kotlin-backend-jpa-entity-mapping declares author: JetBrains. Both are claims made by the file about itself. Treat them as a hint that points at a repository to check, never as attribution.
Date. A skill's last-updated date generally tracks its repository, not its text — which is why one publisher's skills tend to show the same date as each other. A fresh date can mean someone edited a completely different file. It is a weaker signal than the version numbers written inside the body.
And one thing worth knowing about review skills specifically: django-reviewer is explicit about an authorization boundary. It treats a review request as report-only unless you say otherwise, and it refuses to infer permission to write files from the mere fact that it was invoked. If you hand a reviewer to an agent with edit tools, that distinction is the one you want.
What you have now avoided
The opening problem was that an agent's general knowledge of a framework is confident, fluent, and blind to your project — it will write idiomatic Kotlin into a JPA entity, suggest PHP syntax your runtime cannot parse, report an N+1 that is one query, or patch a symptom three times without ever reading the log.
Each of the six above closes one of those. django-perf-review will not report a finding it cannot trace. laravel-11-12-app-guidelines reads your repo's stack before it edits, and knows that an altered column drops the attributes you left out. laravel-systematic-debugging refuses to propose a fix before Phase 1, and stops after three. kotlin-backend-jpa-entity-mapping reaches for the SQL log instead of the annotation. spring-boot-project-creator does not hand over a project until ./mvnw clean verify passes. php-best-practices reads composer.json before it opens its mouth.
That is what separates a useful conventions document from a personality: whether it makes your agent go and look.
More skills worth a look
Implement stateless JWT authentication in Spring Boot 3.5 applications with Spring Security 6.x and JJWT 0.12.6. This skill covers token generation and validation, Bearer and HttpOnly cookie strategies, refresh token rotation, role and permission-based access control, and OAuth2 provider integration. Use it to secure REST APIs with method-level authorization rules and token revocation patterns.
laravel-middleware-patternsThis skill teaches Laravel middleware architecture through practical patterns for request handling. Learn to build before and after middleware, implement terminable patterns for post-response tasks, organize middleware into groups, pass parameters to middleware, and apply common patterns like rate limiting, locale handling, and tenant scoping.
laravel-database-optimizationThis skill provides 33 optimization rules across 9 categories for Laravel 13 applications, covering eager loading, indexing strategies, Redis caching, pagination, and transaction handling. Use it when writing Eloquent queries, diagnosing N+1 issues, configuring indexes, or debugging slow queries with Laravel Debugbar.
api-contract-reviewAudit your REST API design against best practices for HTTP verb selection, versioning strategies, and status code correctness. Catches common mistakes like wrong HTTP methods, missing API versions, entity leaks, and improper error handling that break client compatibility.
clean-architectureThis skill guides you through building Spring Boot applications with clean architecture principles, ensuring domain logic stays independent of frameworks and infrastructure. Learn to structure layered packages, implement ports and adapters, apply domain-driven design tactical patterns, and maintain strict dependency rules that keep your codebase testable and maintainable.
laravel-specialistLaravel Specialist guides you through designing and maintaining Laravel applications at production scale. It covers the full ecosystem—Eloquent relationships and query optimization, Blade and Livewire components, queue systems, middleware pipelines, and Pest testing—with a structured five-phase process from context discovery through optimization.
laravel-apiLaravel API guides you through building REST APIs using stateless, resource-scoped architecture with explicit boundaries between HTTP, business logic, and data layers. It enforces PSR-12 code quality, JWT authentication, versioned endpoints, and invokable controllers to establish maintainable patterns from your first resource.
pestPest is a testing framework built on PHPUnit that replaces test classes with closures and assertion methods with a fluent expect() API. This skill covers test structure using test()/it()/describe(), the full expect() chain including modifiers and custom expectations, hooks for setup and teardown, datasets for parameterized testing, and advanced features like architecture rules and mutation testing.
laravel-securityThis skill guides you through hardening Laravel applications against common vulnerabilities. Learn to configure Sanctum and Passport for secure authentication, implement role-based access control with gates and policies, enforce HTTPS, manage sessions safely, and validate passwords against compromised databases.
spring-boot-actuatorSet up production-ready observability for Spring Boot services using Actuator endpoints, health probes, and Micrometer integration. This skill covers dependency setup, endpoint exposure, security policies, custom health indicators, and metrics export to systems like Prometheus. Follow step-by-step instructions to bootstrap monitoring, secure management traffic, and enable diagnostics tooling for incident response.
laravel-authorization-patternsLearn to implement authorization in Laravel using Gates for general ability checks and Policies for model-specific access rules. This skill covers middleware integration, Blade directives for conditional rendering, and Response objects for detailed permission messages. Includes testing strategies and best practices for securing controllers and form requests.
spring-boot-engineerSpring Boot Engineer scaffolds production-grade Spring Boot 3.x applications with REST controllers, service layers, Spring Data JPA repositories, and Spring Security 6 authentication. It guides you through architecture design, layered implementation with constructor injection, security hardening, and test-driven validation before deployment.
java-rulesJava Rules enforces coding standards across style conventions, framework usage, design patterns, and security practices. It covers Spring Boot, Spring Data JPA, Hibernate, build tools, and modern Java features like records and pattern matching. Apply these rules when writing or reviewing Java code to maintain consistency and best practices.
aws-rds-spring-boot-integrationConnect Aurora, MySQL, or PostgreSQL databases to Spring Boot applications with production-ready patterns for datasource configuration, HikariCP pooling, SSL encryption, and credential management via AWS Secrets Manager. Includes read/write split setup for Aurora replicas, environment-specific profiles, and Flyway migration support.