php-guidelines-from-spatie_skill

This skill enforces Spatie-based PHP and Laravel guidelines for readable, maintainable code with proper typing, structure, and documentation.

697

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill freekmurze/dotfiles --skill php-guidelines-from-spatie

  • SKILL.md7.3 KB

Overview

This skill describes practical PHP and Laravel coding guidelines inspired by Spatie to make code more maintainable and readable. It summarizes naming, type usage, control flow, Laravel conventions, testing, and formatting rules so teams can apply consistent practices. Use it as a quick reference to align projects with proven conventions.

How this skill works

The skill inspects and explains key conventions: PSR standards, typed properties, docblock usage, control-flow patterns, and Laravel-specific patterns for routes, controllers, configuration, and artisan commands. It highlights specific dos and don'ts, concrete examples, and formatting rules so you can apply them directly in code reviews and new code. It surfaces actionable rules for validation, Blade templates, enums, and testing.

When to use it

  • Onboard new team members to consistent PHP/Laravel practices
  • During code reviews to spot deviations from conventions
  • When setting up a project style guide or linting rules
  • Refactoring older code to improve readability and typesafety
  • Writing tests, migrations, or Blade templates to follow project norms

Best practices

  • Follow Laravel conventions first; only deviate with clear justification
  • Prefer typed properties, short nullable notation (?Type), and explicit return types including void
  • Use early returns and avoid else to keep the happy path last
  • Keep docblocks only when they add non-redundant information; import classnames in docblocks
  • Name routes/config/files with kebab-case and methods/variables with camelCase
  • Write descriptive variable and function names so comments are rarely needed

Example use cases

  • Converting docblock-heavy classes to typed properties and return types
  • Standardizing route naming and controller actions for a Laravel app
  • Refactoring complex conditionals into early returns and separated if statements
  • Creating consistent validation arrays and custom rule names in snake_case
  • Formatting Blade templates with 4-space indentation and no extra spacing

FAQ

Keep a docblock when it documents why something is done, provides generics for iterables, or supplies type info not expressible in PHP types; avoid docblocks that duplicate fully type-hinted signatures.

Why prefer early returns over else?

Early returns reduce nesting, make error handling explicit, and keep the main (happy) path clear and easier to follow.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational