Repo Init Laravel Package

Technical Evaluation

What this package is. repo-init is a developer-experience scaffolder: it generates and upgrades repository boilerplate (Boost config, agent definitions, remote skill declarations, tags). It is not a runtime library — nothing in this release ships to production, which materially lowers the blast radius and shifts risk into the engineering workflow rather than the product surface.

Architecture fit. The 1.20.0 changes are additive to the scaffold template layer:

• Remote skills as first-class output. Every scaffolded repo now declares Cloudflare's security-audit skill in withRemoteSkills(), pinned to a commit SHA. This is the correct pattern (immutable pin over a floating ref) and is enforced by the tool's own audit, which flags a missing entry as MEDIUM. Practically, this means repo-init now encodes a security baseline opinion, not just formatting preferences — a meaningful step up in what teams are implicitly adopting.
• Ecosystem bundling. laravel-project now pulls in sandermuller/project-boost-laravel (with a .config/boost.php stub) alongside laravel/boost, plus sandermuller/boost-skills and an always-on voice tag. This deepens coupling to a single-vendor (SanderMuller) toolchain layered on top of first-party Laravel Boost. Acceptable for an opinionated scaffold, but it is now a two-vendor dependency graph where it was previously one.
• Bug fix. stubs/laravel-project/boost.json now uses current laravel/boost agent names (copilot, codex). This is a correctness fix for generated output and should be treated as a required upgrade for anyone whose repos were scaffolded against the stale names.

Integration feasibility. Low effort for greenfield; moderate for existing repos. The upgrade path is deliberately gated: it asks before adding the project-boost-laravel wrapper and runs project-boost:reconcile first, preserving existing agents, tags vendor skills. That is well-designed for humans and awkward for automation — see Operational Impact.

Technical risk.

• Supply chain. New transitive trust in Cloudflare's security-audit skill plus two SanderMuller packages. SHA pinning mitigates drift but creates a manual bump obligation nobody owns by default.
• Interactive upgrade. Prompted confirmations are a CI/automation blocker if the upgrade is scripted at fleet scale.
• Silent divergence. Repos scaffolded on ≤1.19.1 carry stale agent names; the fix only lands on regeneration or upgrade.
• Opt-out path exists (withExcludedSkills()), which is the right escape hatch and should be documented in the internal runbook.

Key questions.

1. Is repo-init upgrade run interactively by developers, or scripted centrally by platform engineering? Determines whether the prompts are a feature or a blocker.
2. Who owns the SHA bump cadence for security-audit and boost-skills, and what triggers a bump?
3. Do the old agent names in pre-1.20.0 boost.json files cause real breakage, or only cosmetic mismatch? Drives upgrade urgency.
4. Is sandermuller/project-boost-laravel acceptable under our third-party dependency policy, and what is its bus factor?
5. Does the always-on voice tag impose token/context cost on every generated repo, and can it be excluded?

Integration Approach

Stack fit. Targets Laravel/PHP teams already using laravel/boost and agent-assisted workflows. If the org is not on Boost, most of 1.20.0 is inert; the security-audit remote skill is the only broadly transferable piece.

Migration path.

1. Run the audit against a sample of existing repos to size the "missing remote skill" MEDIUM findings — this is your real backlog estimate.
2. Upgrade one representative laravel-project repo manually, answering the wrapper prompt, and inspect the project-boost:reconcile output and diff to agents/tags/vendor skills.
3. Confirm .config/boost.php stub and updated boost.json agent names are correct in the generated tree.
4. Establish the pinned-SHA policy before rollout, not after.
5. Roll to remaining repos in waves.

Compatibility.

• Upgrades are designed to be non-destructive to existing agents, tags, and vendor skills — verify rather than assume on the pilot.
• Treat 1.20.0 as a minor with a migration note, not a drop-in: it changes generated output and adds dependencies.
• withExcludedSkills() provides a clean rollback lever per-repo if security-audit proves noisy.

Sequencing. Do the boost.json agent-name fix first (cheap, correctness), then the security-audit skill adoption (policy decision, needs SHA ownership), then the project-boost-laravel / boost-skills bundling (largest dependency-policy surface, most likely to need exception approval).

Operational Impact

Maintenance. New ongoing obligation: pinned SHA bumps for security-audit and boost-skills. Without a named owner and a cadence (e.g. quarterly, or on upstream security advisory), pins rot silently — a pinned SHA is only a security control if someone refreshes it. Budget a small recurring line item.

Support. Expect two classes of tickets: (a) "upgrade asked me a question I didn't understand" around project-boost:reconcile and the wrapper prompt; (b) drift reports from repos that skipped the upgrade and still carry stale agent names. Both are documentation problems more than engineering ones. The linked UPGRADING.md section is the right artifact — mirror it internally rather than pointing developers at an external repo.

Scaling. Interactive prompts are the scaling constraint. At 5 repos, fine. At 50+, you want a non-interactive path or a centralized platform-engineering run — and 1.20.0 does not obviously offer one. Flag this before committing to fleet-wide adoption; it may require a wrapper script or waiting for a --yes-style flag.

Failure modes.

• Prompt-in-CI hang: scripted upgrades stall on the wrapper confirmation.
• SHA drift: audit findings accumulate because pins are never refreshed.
• Reconcile clobber: if project-boost:reconcile misbehaves, hand-tuned agent config could be overwritten despite the stated preservation guarantee — test on the pilot.
• Dependency concentration: two new SanderMuller packages in the critical scaffolding path; an upstream abandonment freezes your generator.
• Opt-out sprawl: teams excluding security-audit for noise reasons quietly lose the baseline the release was designed to establish.

Ramp-up. Low for developers consuming scaffolds (near-zero). Moderate for whoever owns the generator: understanding withRemoteSkills() / withExcludedSkills() semantics, the reconcile step, and the SHA pinning policy is a half-day of reading plus a pilot. Recommend designating one owner for the generator and one reviewer for dependency additions, rather than treating this as everyone's side project.

TPM recommendation. Adopt 1.20.0 — the agent-name fix alone justifies it, and SHA pinning is the right call. Gate fleet rollout on three things: a named SHA-bump owner, a documented non-interactive upgrade path (or an explicit decision to keep it manual), and dependency-policy sign-off on project-boost-laravel and boost-skills. Until those land, pilot on a handful of repos and keep withExcludedSkills() in the back pocket.