agentleFS
RojiosRojios/everything-claude-code/skills/laravel-verification/SKILL.md

laravel-verification

Skill1 starsChanged 7 months agoMITView on GitHub

Verification loop for Laravel projects: env checks, linting, static analysis, tests with coverage, security scans, and deployment readiness.

  • Reads credentials

11 other projects use a version of this, 8 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 12 are common, 0 are distinctive, and 4 are very specific to this project.

  • 12

    Common

    Most of the 8 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Run before PRs, after major changes, and pre-deploy.

    line 9
  2. Common:

    Before opening a pull request for a Laravel project

    line 13
  3. Common:

    After major refactors or dependency upgrades

    line 14
  4. Common:

    Run phases sequentially from environment checks through deployment readiness so each layer builds on the last.

    line 20
  5. Very specific:

    Verify .env is present and required keys exist

    line 34
  6. Common:

    If using Laravel Sail locally:

    line 38
  7. Common:

    If your project uses Psalm instead of PHPStan:

    line 59
  8. Very specific:

    Ensure migration filenames follow Y_m_d_His_* (e.g., 2025_03_14_154210_create_orders_table.php) and describe the change clearly

    line 99
  9. Common:

    Ensure rollbacks are possible

    line 100
  10. Very specific:

    Verify down() methods and avoid irreversible data loss without explicit backups

    line 101
  11. Common:

    Ensure cache warmups succeed in production configuration

    line 112
  12. Common:

    Verify queue workers and scheduler are configured

    line 113
  13. Common:

    If Horizon is used:

    line 123
  14. Very specific:

    If queue:monitor is available, use it to check backlog without processing jobs:

    line 129
  15. Common:

    Verify the job produced the expected side effect (log entry, healthcheck table row, or metric).

    line 142
  16. Common:

    Only run this on non-production environments where processing a test job is safe.

    line 144

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Laravel Verification Loop

Run before PRs, after major changes, and pre-deploy.

When to Use

  • Before opening a pull request for a Laravel project
  • After major refactors or dependency upgrades
  • Pre-deployment verification for staging or production
  • Running full lint -> test -> security -> deploy readiness pipeline

How It Works

  • Run phases sequentially from environment checks through deployment readiness so each layer builds on the last.
  • Environment and Composer checks gate everything else; stop immediately if they fail.
  • Linting/static analysis should be clean before running full tests and coverage.
  • Security and migration reviews happen after tests so you verify behavior before data or release steps.
  • Build/deploy readiness and queue/scheduler checks are final gates; any failure blocks release.

Phase 1: Environment Checks

php -v
composer --version
php artisan --version
  • Verify .env is present and required keys exist
  • Confirm APP_DEBUG=false for production environments
  • Confirm APP_ENV matches the target deployment (production, staging)

If using Laravel Sail locally:

./vendor/bin/sail php -v
./vendor/bin/sail artisan --version

Phase 1.5: Composer and Autoload

composer validate
composer dump-autoload -o

Phase 2: Linting and Static Analysis

vendor/bin/pint --test
vendor/bin/phpstan analyse

If your project uses Psalm instead of PHPStan:

vendor/bin/psalm

Phase 3: Tests and Coverage

php artisan test

Coverage (CI):

XDEBUG_MODE=coverage php artisan test --coverage

CI example (format -> static analysis -> tests):

vendor/bin/pint --test
vendor/bin/phpstan analyse
XDEBUG_MODE=coverage php artisan test --coverage

Phase 4: Security and Dependency Checks

composer audit

Phase 5: Database and Migrations

php artisan migrate --pretend
php artisan migrate:status
  • Review destructive migrations carefully
  • Ensure migration filenames follow Y_m_d_His_* (e.g., 2025_03_14_154210_create_orders_table.php) and describe the change clearly
  • Ensure rollbacks are possible
  • Verify down() methods and avoid irreversible data loss without explicit backups

Phase 6: Build and Deployment Readiness

php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:cache
  • Ensure cache warmups succeed in production configuration
  • Verify queue workers and scheduler are configured
  • Confirm storage/ and bootstrap/cache/ are writable in the target environment

Phase 7: Queue and Scheduler Checks

php artisan schedule:list
php artisan queue:failed

If Horizon is used:

php artisan horizon:status

If queue:monitor is available, use it to check backlog without processing jobs:

php artisan queue:monitor default --max=100

Active verification (staging only): dispatch a no-op job to a dedicated queue and run a single worker to process it (ensure a non-sync queue connection is configured).

php artisan tinker --execute="dispatch((new App\\Jobs\\QueueHealthcheck())->onQueue('healthcheck'))"
php artisan queue:work --once --queue=healthcheck

Verify the job produced the expected side effect (log entry, healthcheck table row, or metric).

Only run this on non-production environments where processing a test job is safe.

Examples

Minimal flow:

php -v
composer --version
php artisan --version
composer validate
vendor/bin/pint --test
vendor/bin/phpstan analyse
php artisan test
composer audit
php artisan migrate --pretend
php artisan config:cache
php artisan queue:failed

CI-style pipeline:

composer validate
composer dump-autoload -o
vendor/bin/pint --test
vendor/bin/phpstan analyse
XDEBUG_MODE=coverage php artisan test --coverage
composer audit
php artisan migrate --pretend
php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan schedule:list

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.