Skeleton Laravel Package

Product Decisions This Supports

• Build vs. buy on project scaffolding. qh-8/skeleton reads as a starter/skeleton package — the kind of thing that standardizes how new Laravel services are bootstrapped (directory layout, base service providers, CI config, linting, auth stubs). The decision it informs is not "which feature do we ship" but "do we standardize our bootstrap or let each team roll its own." That is a platform-velocity decision, and it compounds across every service you start.
• Roadmap sequencing for internal platform work. If we adopt, the v4 line becomes a dependency of every new service's day-one baseline. That means upgrades to it become planned platform work, not incidental maintenance — worth a line item in the platform roadmap.
• Greenfield vs. brownfield scoping. Skeletons deliver value at t=0 of a project and decline sharply afterward. Adopting is a bet that we will keep starting new Laravel services; if the next 12 months are mostly feature work inside one or two existing apps, the payoff is thin.
• Use cases it fits: internal tools, admin backends, proof-of-concepts promoted to production, service templates for a small platform team. Use cases it does not fit: long-lived products with unusual domain modeling, or anything where our conventions have already diverged from the upstream's opinions.

When to Consider This Package

Consider it when:

• We are standing up multiple new Laravel services and want a consistent baseline (auth, config, testing, CI) rather than re-deriving it per team.
• The team is small and opinion-tolerant — skeletons encode someone else's taste, and a small team can adopt that taste wholesale without negotiating.
• We are comfortable tracking upstream closely. Skeleton packages are consumed by copy/fork as often as by Composer, which makes drift a real cost.
• The maintainer cadence and license check out, and the package is small enough to audit in an afternoon if we fork it.

Look elsewhere (or vendor it in-house) when:

• The package is on a fast major-version cadence. This release moves v3.0.0 → v4.0.2, which by semver is a major, breaking change with no described migration path in the notes. Two patch releases on top of a major bump in the same window suggests active churn. Until we can read the actual diff, treat v4 as an unquantified migration cost, especially if we already have services generated from v3.
• Our conventions have already diverged — at that point a fork is honest and a dependency is a fiction.
• We need fine-grained control over the baseline for compliance, security hardening, or multi-tenant concerns.
• Release hygiene matters to us. The v4.0.2 notes contain only a compare link — no narrative, no breaking-change list, no migration guide. That alone is a yellow flag for a package we would put at the root of every new service. If this is representative of how the project communicates, budget for reading source diffs on every upgrade.

Immediate action before any adoption decision: read the v3.0.0...v4.0.2 diff and confirm (a) whether the major bump is a real break or a version-number reset, (b) whether the skeleton's assumptions still match our Laravel/PHP baseline, and (c) whether a v3→v4 migration path exists for any service already generated from v3.

How to Pitch It (Stakeholders)

To executives: This is a project-bootstrap template, not a product feature. It does not add customer-facing capability; it reduces the time and inconsistency cost of starting each new Laravel service. The value is real but indirect, and it only materializes if we actually start several new services in the coming year. My recommendation is to treat it as an internal platform decision with a small, time-boxed evaluation — read the v4 changelog, run one throwaway service through it, and compare against what the team would build by hand in a day. Do not commit to it as a standard until we have seen the v3→v4 diff; the release notes for v4.0.2 are a bare changelog link, so we currently have no stated migration path for a major version bump.

To engineering: The v4 line is a breaking change by semver and the upstream has not documented it. Before we standardize on it, someone needs to own reading the diff and writing down what changed. If we adopt, I want a named owner for upstream upgrades and a decision on fork-vs-depend — because a skeleton we depend on is a baseline we inherit on every future service, and inheriting an undocumented major bump once is a lesson, twice is a process failure. Also worth a sanity check on whether the package's opinions still match how we actually write Laravel today.