Laravel Verification
Run the full Laravel pre-PR and pre-deploy gate: environment, Composer, lint, static analysis, tests with coverage, security, and release readiness.
Overview
laravel-verification is an agent skill most often used in Ship (also security and launch subphases) that runs an ordered Laravel verification loop from env checks through tests, security scans, and deployment readiness.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill laravel-verificationWhat is this skill?
- Sequential phases from environment and Composer validation through deployment readiness
- Hard gate: stop immediately if PHP, Artisan, or .env checks fail
- Lint and static analysis must be clean before full tests and coverage run
- Security and migration reviews after tests; build and queue/scheduler checks as final release gates
- Laravel Sail variants documented for local PHP and Artisan version checks
- Phase 1 environment checks gate all later phases
- Phase 1.5 adds Composer validate and dump-autoload steps
Adoption & trust: 3.5k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to merge or deploy a Laravel app without confidence that env, quality, security, and queue readiness were checked in a sane order.
Who is it for?
Indie Laravel maintainers who want a repeatable pre-PR and pre-deploy ritual without assembling commands from scratch each time.
Skip if: Non-PHP projects, greenfield repos with no Laravel bootstrap yet, or exploratory spikes where formal gates are intentionally skipped.
When should I use this skill?
Before opening a pull request for a Laravel project, after major refactors or dependency upgrades, or pre-deployment verification for staging or production.
What do I get? / Deliverables
You complete a gated pipeline—environment, lint, tests, security, migrations, and deploy readiness—with explicit stop points before PR or production.
- Green sequential phase report
- Deploy-blocker list when any gate fails
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Verification loops belong in Ship when behavior, security, and deploy gates must pass before users see changes. Testing is the canonical shelf because lint and analysis are explicitly sequenced before the full test and coverage tranche.
Where it fits
Run lint and the full test suite with coverage after a dependency bump before requesting review.
Execute security scans only after tests pass so behavior is validated before release hardening.
Confirm migration review, build artifacts, and queue or scheduler health as final deploy gates.
Re-run environment and Sail version checks after moving workers to a new host.
How it compares
A Laravel-specific phased checker—not a generic ADR writer or ports-and-adapters design guide.
Common Questions / FAQ
Who is laravel-verification for?
Solo builders and tiny teams running Laravel who need structured gates before PRs and production pushes.
When should I use laravel-verification?
Before opening a pull request, after major refactors or Composer upgrades, and immediately pre-deploy to staging or production—including when validating APP_DEBUG and APP_ENV.
Is laravel-verification safe to install?
It instructs shell, Composer, and test execution in your repo; review the Security Audits panel on this page and run only in trusted environments.
SKILL.md
READMESKILL.md - Laravel Verification
# 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 ```bash 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: ```bash ./vendor/bin/sail php -v ./vendor/bin/sail artisan --version ``` ## Phase 1.5: Composer and Autoload ```bash composer validate composer dump-autoload -o ``` ## Phase 2: Linting and Static Analysis ```bash vendor/bin/pint --test vendor/bin/phpstan analyse ``` If your project uses Psalm instead of PHPStan: ```bash vendor/bin/psalm ``` ## Phase 3: Tests and Coverage ```bash php artisan test ``` Coverage (CI): ```bash XDEBUG_MODE=coverage php artisan test --coverage ``` CI example (format -> static analysis -> tests): ```bash vendor/bin/pint --test vendor/bin/phpstan analyse XDEBUG_MODE=coverage php artisan test --coverage ``` ## Phase 4: Security and Dependency Checks ```bash composer audit ``` ## Phase 5: Database and Migrations ```bash 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 ```bash 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 ```bash php artisan schedule:list php artisan queue:failed ``` If Horizon is used: ```bash php artisan horizon:status ``` If `queue:monitor` is available, use it to check backlog without processing jobs: ```bash 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). ```bash 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: ```bash 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: ```bash composer validate composer dump-autoload -o vendor/bin/pint --test