Repo Init Laravel Package

Product Decisions This Supports

Scaffolding standardisation as a platform decision, not a per-repo decision. repo-init is the opinionated baseline for new Laravel repos: it generates the repo skeleton and the AI-agent configuration (laravel/boost agents, skill tags, remote skills). For a PM, this is the artifact that determines whether "new service" means thirty minutes or three days, and whether every repo starts with the same agent context or a bespoke one.

Supply-chain posture for AI tooling — now with a security default. 1.20.0 makes Cloudflare's security-audit skill a declared remote skill in withRemoteSkills(), pinned to a commit SHA, and adds a MEDIUM-severity audit check for missing entries. This converts "do our repos have security review in the agent loop?" from an aspiration into a verifiable, checkable property of every scaffold. It is a policy feature more than a code feature — the kind of thing that shows up in a security questionnaire and in a platform team's quarterly compliance narrative.

Reproducibility vs. currency trade-off. SHA pinning gives deterministic scaffolds and a clear upgrade ritual (audit flags it, upgrade adds it). The cost is an ongoing SHA-rotation chore with no automation described. Roadmap question worth asking: is pin-bumping a manual quarterly task, or does the tool take a "latest verified" policy? This is the single biggest long-term operational cost the release introduces.

Third-party dependency expansion — a buy-vs-build signal. laravel-project now pulls sandermuller/project-boost-laravel (with its own .config/boost.php stub) alongside laravel/boost, plus sandermuller/boost-skills and the always-on voice tag. That is the maintainer consuming their own adjacent packages — coherent, but it means adoption of repo-init is adoption of a small ecosystem. Worth an explicit roadmap line on support matrix, release cadence, and bus factor for those three packages before they appear in every repo a team creates.

Upgrade experience as a product surface. The upgrade path "asks before it adds the wrapper, runs project-boost:reconcile first, and keeps the existing agents, tags, and vendor skills" is a deliberate non-destructive merge. That is the right default for teams with customised repos, but interactive confirmation is a friction point for any scripted or CI-driven scaffolding. If repo-init is ever invoked non-interactively, this needs a --yes/config-file equivalent.

Drift risk with upstream. The boost.json stub fix (current laravel/boost agent names copilot, codex) shows the tool is tightly coupled to an upstream package's internal naming. Every laravel/boost rename becomes a repo-init patch release. PM takeaway: pin the supported laravel/boost range and publish it, or the tool breaks silently against newer upstreams.

Concrete use cases it unlocks: greenfield service bootstrap; retrofitting AI-agent config onto existing repos via the upgrade command; standardising a large fleet before an agent-assisted migration; and satisfying "all new repos pass security audit" as an enforceable team policy via withExcludedSkills() as the documented escape hatch (useful for teams that must justify deviations rather than silently skip).

When to Consider This Package

Adopt when:

• You are creating Laravel repos regularly (≥ a few per quarter) and the variance between them is causing review friction, onboarding cost, or inconsistent tooling.
• You have standardised — or are standardising — on laravel/boost and agent-assisted development, and want agent config, skill tags, and vendor skills generated rather than hand-copied.
• A security review, customer questionnaire, or internal platform policy requires demonstrable, reproducible controls in new repos. The pinned security-audit skill and the MEDIUM audit check give you something concrete to point at.
• You want a governed upgrade path for existing repos: reconcile, prompt-before-mutate, and preservation of existing agents/tags/vendor skills mean adoption is not all-or-nothing.
• You are comfortable with a maintainer-led, single-vendor ecosystem (see caveats).

Look elsewhere or defer when:

• You run non-interactive/CI scaffolding today. The confirm-before-adding-wrapper behaviour and prompt-driven upgrade flow will block automation until a flag exists.
• You do not use laravel/boost. The 1.20.0 features are almost entirely boost-ecosystem plumbing; the scaffolding value is real but the release adds little for non-boost shops.
• Policy forbids third-party or self-published dependencies in the build path. Adding sandermuller/project-boost-laravel and sandermuller/boost-skills to every repo needs a procurement/ownership review (maintenance commitment, security response, versioning discipline) that a PM should own, not delegate to engineering.
• You need a stable, slow-moving scaffold. This release is fast-moving and coupled to upstream naming; teams that cannot take a patch per upstream rename should wait for a pinned support matrix.
• You already have an internal template repo with strong ownership. Migrating may cost more than it saves unless you are also changing your agent tooling.
• You have a small number of long-lived monoliths and no greenfield pipeline — the return is per-repo, so it scales with repo churn.

How to Pitch It (Stakeholders)

To executives (one paragraph): repo-init 1.20.0 makes our Laravel project setup repeatable instead of artisanal. Every new repo now ships with a pinned security-review capability built into the AI-agent workflow, so "new services get a security pass" becomes a property of the template rather than a promise. The commercial argument is speed-to-first-commit and lower audit cost, not licence savings — the tool itself is cheap; the value is in eliminated variance and a shorter security questionnaire.

To engineering leadership: This is a standardisation play with a controlled blast radius. Adopt for greenfield repos first; the upgrade path reconciles rather than overwrites, so existing customisation survives. Two costs to fund explicitly: (1) SHA pin rotation — someone must own bumping the pinned security-audit commit, otherwise we drift stale; (2) dependency governance — 1.20.0 brings project-boost-laravel and boost-skills into the default path, so we should agree a support/ownership expectation before they land in every repo. Also budget a small automation task: the interactive upgrade prompt needs a non-interactive mode before we use this in CI.

To security/compliance: The security-audit skill is declared by default and pinned to a specific commit, with an audit check that flags absence as MEDIUM and an audited withExcludedSkills() opt-out. Deviations are therefore visible and justified rather than silent. Caveat to state plainly: pinning gives reproducibility but not currency — an unpinned bump process means the pinned commit ages. Recommend we define a rotation cadence and treat this as the control, not the check itself.

To the adopting team (the honest pitch): You get a repo that starts with working agent config, skill tags, and vendor skills, and an upgrade command that asks before it changes anything. The trade-off is coupling: repo-init tracks laravel/boost naming closely (this release fixed agent names to copilot/codex), so expect periodic patch releases. Pin repo-init and laravel/boost together, and treat both as one upgrade unit.

What to ask before committing: Who owns the pin-rotation cadence? What is our supported laravel/boost range? Do we accept the sandermuller/* ecosystem dependency in the default path, or opt out via withExcludedSkills() for now? And does the upgrade flow give us a non-interactive mode, or do we gate adoption on it?