Fresh Package Laravel Package

Product Decisions This Supports

• Build vs. buy vs. copy for package standardization. The framing that matters is not "should we add a dependency" — this is a template, not something you composer require. The real fork is: fund an internal generator, keep hand-rolling composer init + Testbench per repo, or adopt an existing opinionated skeleton. Because nothing ships into production and there is effectively no runtime switching cost, this is a cheap-to-trial, cheap-to-abandon decision. That asymmetry is the entire business case.
• Marginal cost of the nth package. If the roadmap includes extracting domain modules, SDKs, or shared libraries out of a monolith, the target is for package #5 to cost roughly what package #1 cost. Pre-decided namespaces, service provider wiring, config publishing, test harness, and static analysis remove both the repeated setup tax and the repeated code-review debate about layout.
• Deferring the backend-only vs. full-stack call. Both surfaces are supported from one starting point, so we don't have to lock the package's delivery shape (API-only vs. Blade/Livewire/asset surface) before we know what it actually needs to be. That's a real option value — defer a decision that would otherwise be forced on day one.
• Quality gates as inherited default rather than per-repo negotiation. PHPStan, Rector, a runnable test harness, and a workbench/sandbox are baked in; v0.4.0 fixed parallel sandbox runs. "Does every package get static analysis and an integration harness?" becomes a decided question instead of a recurring argument in every new repo's first PR.
• Whether consumer-facing integration guidance is part of definition of done. The shipped SKILL.md template is written for adopters and their coding agents, deliberately scoped to public API only. That's a product decision we get to trial nearly for free: do we treat machine-readable integration docs as a deliverable, not an afterthought?
• Extensibility posture toward our own tooling. The "safe mode for chisel-extended" feature signals the skeleton is designed to be layered on by generators. Directly relevant if we already have scaffolding tooling or plan to build one — it tells us upstream expects non-destructive, idempotent downstream generators.
• Roadmap slotting and commitment level. v0.4.0 bundles features, fixes, refactors, and maintenance in one cut, which reads as an actively dogfooded tool. That supports "pilot now, reassess at 1.0" rather than a hard standardization mandate. Verify the release timestamp against the repo before citing momentum — it appears future-dated.
• Concrete use cases to scope a pilot around: greenfield internal Laravel packages, extracted domain modules, shared client SDKs for internal services, and back-end-only packages that mainly merge config and bind a service. Not a fit for migrating mature, stable packages into a new layout.

When to Consider This Package

Adopt or pilot when:

• We expect to author more than one Laravel package in the next two quarters. A single one-off rarely repays the cost of learning someone else's layout.
• Cross-repo consistency — naming, namespaces, provider/config wiring, test harness, static analysis — is a stated goal and we don't want to own a bespoke generator to get there.
• The team already lives in the implied toolchain: modern PHP, PHPStan, Rector, a Testbench-style sandbox, and is willing to accept an external folder convention.
• We need backend-only and full-stack packages from one starting point.
• We can name an internal owner, pin a version, and hold a small upstream diff — fork-and-pin, not track-loose.
• We want adopter-facing guidance, including for coding agents, as part of the deliverable.

Look elsewhere or wait when:

• We need vendor support, an SLA, or a deprecation policy. Pre-1.0, single maintainer, ~33 stars, no declared dependents. Assume we own our fork; the downside is bounded, but don't plan around upstream responsiveness.
• The team has no appetite for opinionated structure. The value proposition collapses the moment every generated repo immediately diverges. This is a conventions decision, not a tooling decision — get buy-in before package #1, not after package #3.
• We need framework-agnostic PHP or a non-Laravel layout.
• We already have an established monorepo, path-repository, or custom release pipeline whose conventions this skeleton would fight.
• The artifact is a one-line utility — scaffolding overhead exceeds the payoff.
• We require mature documentation before adoption. The README is intentionally decluttered (further in v0.4.0); budget time to read source and commit history.
• We need a supported upgrade path from upstream to already-generated packages. There isn't one. The practical path is manual diff, selective cherry-pick, or regenerate — so Laravel major upgrades become a scheduled review activity rather than something CI discovers.
• We'd be rewriting a stable existing package into this layout. Pure churn; selectively adopt the structure, Composer scripts, and sandbox pattern instead.

How to Pitch It (Stakeholders)

For executives — the one-liner: it's a starter kit, not a dependency. We clone it once, own the code from commit one, and get consistent, quality-gated Laravel packages at lower marginal cost — with no runtime exposure and no lock-in.

• Risk profile is unusually favorable. Nothing ships to production; the template is not a runtime surface. The genuine risk isn't runtime failure, it's template drift — teams fork, customize, and diverge until the standardization benefit evaporates. Mitigate with a named internal owner, a pinned version, and a deliberately small upstream diff. Record the pinned version and the adoption rationale in the generated repo, not in someone's head.
• Cost of failure is a sprint, not a migration. Pilot, measure time-to-first-green-test, and walk away if it doesn't beat hand-rolling.
• Quality becomes the default, not a negotiation. Static analysis, automated refactors, and an integration sandbox come pre-wired.
• Don't quote the zero-dependents figure. Scaffolding repos are cloned, not required, so dependent counts structurally understate usage. Treat low visibility as a bus-factor input, not a quality verdict in either direction.

For engineering — the operating model:

• Scaffold → rename → green → feature. Never feature-first. Do the placeholder sweep (:package_name, :vendor_slug, :package_slug) as one atomic pass across composer.json, namespaces, class names, config keys, publish tags, README, and SKILL.md, then run composer dump-autoload plus the full suite. A half-renamed skeleton is the most common way to lose an afternoon — and v0.4.0's "broken structure after marker cleanup" fix is exactly that failure mode.
• Maintain an internal golden template. Upstream is a source of ideas; the thing we actually scaffold from carries our CI config, license headers, coding standards, and registry settings. Periodically diff against a pinned upstream tag and cherry-pick.
• Keep the service provider thin and single-seam. Discovery, config merging, publish tags, and bindings live there; behavior lives in dedicated classes. It makes "what does installing this package do to my app?" answerable by reading one file.
• Make the workbench/sandbox the default dev loop and the source of integration tests; v0.4.0 explicitly enabled parallel sandbox runs.
• Extension points in order of safety: Composer scripts (customize freely), config and publish tags (safe to reshape), service provider (additive only), directory structure (last resort — deep forks make future rebases expensive).
• Definition of done includes SKILL.md. Update it in the same PR that changes the public API, and keep it scoped to adoption in a Laravel app — not package internals.

Ask: approve a scoped pilot on the next two greenfield packages, with a named owner, a pinned tag, and a reassessment checkpoint at upstream 1.0.