laravel-verification
Verification loop for Laravel projects: env checks, linting, static analysis, tests with coverage, security scans, and deployment readiness. Use when verifying a Laravel project before merge or deploy — lint, static analysis, tests, coverage, security.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- laravel-verification
- metadata
- { "origin": "ECC" }
- description
- Verification loop for Laravel projects: env checks, linting, static analysis, tests with coverage, security scans, and deployment readiness. Use when verifying a Laravel project before merge or deploy — lint, static analysis, tests, coverage, security.
03 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
.envis present and required keys exist - Confirm
APP_DEBUG=falsefor production environments - Confirm
APP_ENVmatches 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/andbootstrap/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
04 同仓库更多 Skills
higgsfield-websites
Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1/R2/KV/DO/Containers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references/website-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references/app-flow.md), `game` (realtime multiplayer rooms — references/game-flow.md). Routes to the right flow; each carries its own rules and deploy/publish gates. Use when: "build me a website", "make a landing page", "create a web app", "build a SaaS dashboard / portfolio", "make me a game", "deploy this site", "publish". Also owns GAME ART: "make a spritesheet", "tileable texture", "animate a 3D character", game music/SFX — see the game-* references. NOT for: single image/video/audio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
using-superpowers
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions
using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback