How to contribute

This skeleton is the seed of millions of Laravel applications. Changes here ripple out to every composer create-project laravel/laravel from the day they're released. That weight makes the contribution bar high.

Where contributions are welcome

The repo's README defers to the official Laravel contribution guide for the full process. The relevant rules of thumb for this skeleton specifically:

• Bug fixes in defaults (config files, migrations, env-var handling) are welcome anytime.
• New defaults (a new env var, a new config block, a new migration column) need a clear rationale. Many such PRs are closed in favour of doing the work in laravel/framework and exposing a hook.
• Stylistic changes (rewriting comments, moving things around, switching to a different convention) usually aren't merged. The skeleton is opinionated by intention.
• Security fixes should be reported privately to taylor@laravel.com per the README's Security Vulnerabilities section, not opened as public issues or PRs.

What ends up where

The repo's read-the-source rules:

Location	What lives there
app/	Application code (PSR-4: App\)
bootstrap/	Framework wiring
config/	One file per concern
database/migrations/	Schema changes — anonymous-class migrations only
database/factories/, seeders/	Test fixtures
routes/	Web + console route definitions
resources/	Blade views and Vite source files
tests/	PHPUnit tests (Feature + Unit)
.github/workflows/	CI

Read Patterns and conventions for the style and structure rules visible across the codebase.

Workflow

A typical contribution cycle:

1. Fork the repo (you'll be working against 13.x for now — or whatever branch is current).
2. Clone, install, and verify tests pass on a clean checkout (see Development workflow).
3. Make the change. Keep it scoped: one logical change per PR.
4. Run php artisan test and vendor/bin/pint.
5. Open a PR against the current branch (13.x, 12.x, etc., not master directly).
6. The CI matrix in .github/workflows/tests.yml runs PHP 8.3, 8.4, and 8.5. All three must pass.

Definition of done

A PR is mergeable when:

• php artisan test passes locally on PHP 8.3 (the minimum).
• CI is green across PHP 8.3, 8.4, 8.5.
• vendor/bin/pint finds no style violations.
• Any new env var is documented in .env.example.
• Any new config option is documented in the relevant config/*.php comment block.
• Migrations have symmetric up() and down() methods.
• No new dependency is added unless absolutely necessary.

Sub-pages

Topic	Why
Development workflow	Branch, code, test, PR, merge cycle
Testing	PHPUnit setup, base classes, fakes
Debugging	Logs, exceptions, common errors
Patterns and conventions	Coding style, structural rules, opinionated defaults
Tooling	Pint, Pail, Vite, Composer scripts

A note on issues vs. PRs

The repo uses .github/workflows/issues.yml to apply a "help wanted" workflow when issues are labeled appropriately, and .github/workflows/pull-requests.yml to mark PRs as uneditable on open. Both of those workflows delegate to laravel/.github reusable workflows — so the actual policy lives in the org-wide repo and isn't visible here.