When should I use the Laravel Development Workflow skill?

Use this skill when implementing a feature in an existing Laravel application, diagnosing and fixing a Laravel bug at its root cause, ensuring a change has regression coverage, or when the project has architectural or testing conventions that must be preserved.

What should I NOT use this skill for?

Do not use this skill when you need to scaffold a new Laravel project from scratch or when you want to impose a complete project structure—it adapts to an existing repository's architecture rather than creating one.

What does the workflow output include?

The workflow provides an implementation that reuses the application's established patterns, covers critical observable behavior, and reports what changed and why, the scenarios and edge cases covered, the exact checks run and their results, and any checks that could not run with concrete reasons and remaining risk.

What testing and analysis tools does this skill use?

The skill discovers and uses the project's configured commands, including `php artisan test`, Pest, PHPStan for static analysis, and Pint for formatting, along with Laravel patterns like Eloquent relationships, form requests, policies, actions, services, events, jobs, factories, and migrations.

Skill

Build and Fix Laravel Features with Test Coverage

Name: Laravel Development Workflow
Availability: OnlineOnly
Author: Junaid-PK

A Laravel dev workflow: trace to root cause before fixing, build features in the app's existing shape, then verify proportionately.

Get skill

Works with laravelphpstanpest

Junaid-PK

Own this? Claim it

Spark score

out of 100

Updated 15 days ago

Source checked Sep 5, 2026

Version 16.8.0

Add to Favorites

Why it matters

Implement maintainable Laravel features and fix bugs at their root cause while preserving existing architectural conventions and providing proportionate test coverage that matches the change's risk level.

Outcomes

What it gets done

Trace routes, models, and controllers to identify change boundaries and existing conventions

Reproduce bugs through the narrowest path and add regression tests before fixing

Implement features using established patterns for policies, form requests, and Eloquent relationships

Run targeted tests, static analysis, and linting to verify critical behavior without over-testing

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-laravel-development-workflow | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Laravel Development Workflow

A three-phase Laravel workflow: trace the app's existing conventions before editing, fix bugs at their actionable root cause with a regression test rather than suppressing the symptom, and build features reusing the codebase's established patterns instead of imposing new ceremony. Use it for feature work or bug fixes inside an existing Laravel application that already has architectural or testing conventions worth preserving, with verification scaled to the change's actual risk.

What it does

This skill structures feature work and bug fixes inside an existing Laravel application around three phases. First, it establishes the contract: read repository instructions, trace routes/models/controllers/actions/services/requests/policies/jobs/events/tests/schema far enough to find the real change boundary and existing conventions, then compress the request into scenarios, edge cases, and verifiable acceptance criteria - scaled to the task, so a focused validation fix doesn't get the ceremony of a new multi-role workflow. Second, for bugs it enforces a root-cause discipline: reproduce the failure through the narrowest reliable path, trace data and control flow to the actionable cause, add a regression test that fails for that cause when practical, implement the smallest fix that restores the intended invariant, and demonstrate the regression test now passes alongside nearby behavior - explicitly rejecting retries, broad exception handling, disabled validation, extra timeouts, or error suppression as substitutes for an actual fix. For features, it reuses the application's established patterns rather than imposing new ones: Eloquent relationships, form requests, policies, actions, services, events, or jobs are used when they fit local convention, not as mandatory ceremony, migrations stay reversible and compatible with the app's supported database engines, and factories/seeders/fixtures are created only when real coverage or development data needs them - not left behind as one-off scaffolding.

When to use - and when NOT to

Use it when implementing a feature in an existing Laravel application, diagnosing and fixing a Laravel bug at its actionable root cause, adding regression coverage proportionate to a change's risk, or working in a project that already has architectural or testing conventions that need to be preserved rather than overridden. It requires an existing Laravel application to adapt to - it does not impose a complete project structure on a greenfield build, and it does not authorize destructive database operations, production commands, deployments, credential changes, or external account actions unless the user or repository instructions explicitly place them in scope.

Inputs and outputs

Input: a feature request or bug report against an existing Laravel codebase, plus that repository's own conventions, test tooling, and documented commands.
Output: a change that reuses the codebase's existing architectural patterns, a regression test for any bug fix, and a completion report naming what changed and why, the scenarios and edge cases covered, the exact checks run and their results, and any check that could not run along with the concrete reason and remaining risk.

php artisan test --filter=RelevantTest
vendor/bin/pest --filter=RelevantTest
vendor/bin/phpstan analyse
vendor/bin/pint --dirty

Who it's for

Developers and agents working inside an established Laravel codebase who need bug fixes to land at the actual root cause and features to land in the application's existing shape, backed by verification proportionate to the change's risk rather than either skipped or over-applied.

FAQ

Common questions

Discussion