Skeleton Php Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for internal scaffolding. This is not a runtime dependency (0 dependents, MIT, template-style repo) — it's a golden path artifact. Adopting it is a decision to standardize how new PHP packages are born rather than letting each team hand-roll composer.json, CI, and lint config.
• Time-to-first-commit as a roadmap metric. The package front-loads the boring 80%: PSR-4 autoloading, PHPUnit/Pest wiring, static analysis, code-style enforcement, GitHub Actions workflows, .editorconfig/.gitattributes, license and README/CONTRIBUTING templates. That lets you commit to a lead-time target ("a new package is publishable in under a day") instead of an aspirational one.
• Quality-gate policy enforcement. Because standards live in the skeleton, adopting it turns "we should run static analysis" from a review comment into a default. This is the cheapest lever a PM has for shifting defect-escape metrics without a mandate.
• Open-source packaging strategy. If your roadmap includes publishing libraries (SDKs, Laravel packages, internal tools going public), this defines the shape of a publishable package: license, funding metadata, contribution docs, CI badges.
• Developer-platform investment sizing. Use it as a reference implementation when scoping an internal "package generator" (composer create-project template, Cookiecutter, or a CLI). Forking this is a days-not-quarters starting point; that comparison anchors the business case either way.

When to Consider This Package

Adopt (or fork) when:

• Your team ships two or more Composer libraries/packages, not applications — the payoff scales with repetition.
• You want opinionated, modern PHP defaults (strict types, static analysis, CI on day one) and are willing to inherit someone else's opinions.
• You're on GitHub Actions and can live with the workflow files as shipped.
• You need a low-risk pilot: MIT, no runtime coupling, nothing to uninstall if it doesn't fit.

Look elsewhere when:

• You're building a Laravel application — use laravel/laravel or a starter kit; this skeleton is for packages, not apps.
• Your CI is GitLab/CircleCI/Jenkins — you'll be rewriting the workflow layer, which is a large share of the value.
• You need monorepo or multi-package tooling (Composer path repositories, splitsh, release automation); the skeleton stops short of release/publishing pipelines.
• Maintainability matters more than speed. It's a single-maintainer personal skeleton with modest adoption; there's no upgrade path once forked, no template-sync mechanism, and no semver contract. Budget an owner for the fork or treat it as one-time inspiration.
• You need governance artifacts (security policy, CODEOWNERS, compliance headers, SBOM) — you'll be adding these yourself.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed starter kit for new PHP libraries. It doesn't add a dependency or a vendor relationship — it's a template we copy once and own outright. The value is velocity and consistency: instead of every new package spending days on boilerplate and CI, we start from a vetted baseline that already enforces code quality checks on every pull request. Cost is effectively zero; the only real investment is naming an internal owner to maintain our fork.

To engineering: Clone it, composer install, and you have autoloading, tests, static analysis, and Actions wired up — no yak-shaving. It encodes sensible modern PHP defaults, so reviews shift from "add a linter" to actual design. Caveats stated plainly: single maintainer, GitHub Actions assumption, and once you fork, you're your own upstream — so we'd snapshot it, strip what we don't use, and treat the snapshot as the standard, not track it as a dependency.

Recommendation: Pilot on the next two packages. If setup time drops as expected, promote the fork to the official internal template and assign an owner; if we hit CI or governance friction early, fall back to cherry-picking the config files and move on.