spatie-laravel-php
Apply Spatie's Laravel and PHP coding standards for any task that creates, edits, reviews, refactors, or formats Laravel/PHP code or Blade templates; use for controllers, Eloquent models, routes, config, validation, migrations, tests, and related files to align with Laravel conventions and PSR-12.
Install
npx skills add https://github.com/spatie/guidelines-skills --skill spatie-laravel-phpSKILL.md
Spatie Laravel & PHP Guidelines
Overview
Apply Spatie's Laravel and PHP guidelines to keep code style consistent and Laravel-native.
When to Activate
- Activate this skill for any Laravel or PHP coding work, even if the user does not explicitly mention Spatie.
- Activate this skill when asked to generate, edit, format, refactor, review, or align Laravel/PHP code.
- Activate this skill when working on
.phpor.blade.phpfiles, routes, controllers, models, config, validation, migrations, or tests.
Scope
- In scope:
.php,.blade.php, Laravel conventions (routes, controllers, config, validation, migrations, tests). - Out of scope: JS/TS, CSS, infrastructure, database schema design, non-Laravel frameworks.
Workflow
- Identify the artifact (controller, route, config, model, Blade, test, etc.).
- Read
references/spatie-laravel-php-guidelines.mdand focus on the relevant sections. - Apply the core Laravel principle first, then PHP standards, then section-specific rules.
- If a rule conflicts with existing project conventions, follow Laravel conventions and keep changes consistent.
Core Rules (Summary)
- Follow Laravel conventions first.
- Follow PSR-1, PSR-2, and PSR-12.
- Prefer typed properties and explicit return types (including
void). - Use short nullable syntax like
?string. - Use constructor property promotion when all properties can be promoted.
- One trait per line with separate
usestatements. - Once a method chain breaks across lines, put every subsequent
->on a new line; never mix single-line and multi-line chaining. - Prefer early returns and avoid
elsewhen possible. - Always use curly braces for control structures.
- Use string interpolation over concatenation.
- Happy path last: handle error conditions first.
Do and Don't
Do:
- Use kebab-case URLs, camelCase route names, and camelCase route parameters.
- Use tuple notation for routes:
[Controller::class, 'method']. - Use plural resource names for controllers (
PostsController). - Use array notation for validation rules.
- Use
config()helper and avoidenv()outside config files. - Add service configs to
config/services.php, not new files. - Use
__()for translations instead of@lang. - Use PascalCase for enum values and class constants.
Don't:
- Add docblocks when full type hints already exist.
- Use fully qualified classnames in docblocks.
- Use
finalorreadonlyby default. - Use
elsewhen early returns work. - Add spaces after Blade control structures.
Examples
// Happy path last with early returns
if (! $user) {
return null;
}
if (! $user->isActive()) {
return null;
}
// Process active user...
// Short ternary
$name = $isFoo ? 'foo' : 'bar';
// Constructor property promotion
class MyClass {
public function __construct(
protected string $firstArgument,
protected string $secondArgument,
) {}
}
@if($condition)
Something
@endif
References
references/spatie-laravel-php-guidelines.md
Related skills
improve-codebase-architecturemattpocock1MScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.codebase-designmattpocock691KShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.web-design-guidelinesvercel-labs676KReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".code-reviewmattpocock631KReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".
