Boost Core Laravel Package

Technical Evaluation

Architecture fit. Unchanged in principle, and now better evidenced. boost-core remains a source-of-truth compiler sitting in the developer-experience layer: authors write skills, guidelines, and commands once in .ai/, and the package fans them out to ten agent-specific layouts (Claude Code, Cursor, Copilot, Codex, Gemini, Junie, Kiro, OpenCode, Amp, Antigravity). 1.13.0 confirms the pattern extends to a second target dimension beyond agent format — output scope — with project scope and user scope (--scope=user) now both produced from the same content model. The framework-free, no-runtime-dependency posture still holds, and remains the strongest architectural signal: the package can serve Laravel apps, Symfony services, legacy PHP, and non-PHP repos alike. The new ~/.boost/user-scope.php selector file is architecturally coherent — it puts per-machine curation under an explicit declarative config rather than implicit globbing — but it does introduce a second, unversioned configuration surface that is not governed by the repo. That is a legitimate design choice for personal preferences; it is not a place for team policy.

Integration feasibility. Confirmed feasible and now materially less speculative. The release notes resolve several previously open mechanical questions: the entry point is boost sync with a --scope flag, there is a --check mode (used to predict skill-name clashes), sync is idempotent enough to be run repeatedly (syncUserScopeOnce() re-syncs after config edits), and there is an auto-sync helper (BoostAutoSync) suggesting first-class hook integration. Ownership semantics are now explicit: user-scope sync refuses to write over a file boost does not own and refuses to write through a symlink at a target path. That is exactly the guardrail the previous assessment flagged as missing for the silent-overwrite risk, and it is a strong signal of maintainer care. Integration cost is still composer require --dev, a config entry, and a sync invocation, with the blast radius of a bad sync being a diff rather than an incident.

Technical risk. Maturity remains the dominant risk — the community and dependent-base picture has not changed — but the staleness risk has receded. Two consecutive releases (1.12.1 → 1.13.0) with a structured changelog and a dedicated UPGRADING.md anchor indicate an active, disciplined cadence, and the date-anomalous release metadata flagged previously looks increasingly like a data artifact rather than abandonment. What 1.13.0 does establish is the shape of the risk we actually carry: the package will make breaking changes to generated paths and identifiers when the old layout is functionally broken, and it expects you to read migration notes before syncing. Here the change is a genuine bug fix — nested ~/.{agent}/skills/<vendor>__<package>/<skill>/ paths were invisible to Claude Code, so most user-scope skills silently did nothing. That is a correct call, but it means "we pinned and forgot" is a real failure mode, and it means generated-path stability is coupled to third-party agent behavior we do not control. Secondary risks narrow: silent overwrite is now defended against for user scope; skill-name collisions across global packages are detected and reported deterministically (first package by name wins, second reports the clash owner). Remaining supply-chain exposure from running a near-zero-adoption dev dependency in CI is unchanged and still argues for exact pinning.

Key questions.

• Is the ownership/symlink refusal behavior also enforced at project scope, or only user scope?
• The -user suffix prevents a user-scope skill from shadowing a project skill of the same name — is the reverse also true, and what happens when a project skill and a user skill are both intended to apply?
• What is the support window for UPGRADING.md breaking changes — are user-scope path layouts treated as semver-breaking, or does 1.13 being a minor release imply generated paths are not covered by semver?
• Which of the ten agents are first-class, tested targets versus best-effort adapters, and is there an SLA for upstream format changes?
• Does --check cover project scope and drift, or only user-scope clash prediction? Can it be the basis of a single CI gate?
• Is the removed 0.3 → 0.4 migration the only legacy shim being dropped, and are there other time-bombed migrations that will disappear in a future minor?
• What is the relationship to and overlap with Laravel Boost — run both, or is one a superset?
• What is the release and support model, and who is the second maintainer?
• What PHP version range and OS/container support are tested, and does it handle monorepos with nested projects?
• Any sanitization, provenance, or secret-scanning hooks for content that ends up in agent prompts?

Integration Approach

Stack fit. Adopt as a require-dev dependency in the tooling layer only; never in a production autoload graph. It composes cleanly with pre-commit hooks, Composer scripts, and CI, and contends with no application constraints because it carries no runtime requirements. The scope decision now has two axes rather than one: repo-level .ai/ content (agent-agnostic, shareable across backend, frontend, and infrastructure repos, and therefore a candidate for an org-level convention) and user-scope publication (per-developer, per-machine, governed by ~/.boost/user-scope.php). Treat these as separate adoption decisions with separate governance — the repo-level content is a standard; the user-scope selector is a personal preference file that should not be centrally mandated.

Migration path. Repo-level migration is unchanged and reversible by construction: .ai/ is plain content we own, and every generated artifact can be deleted along with the dev dependency. For user scope, 1.13.0 introduces a real, if small, one-time migration. Sequence it deliberately: read UPGRADING.md#112--113 first, decide whether ~/.boost/user-scope.php is needed (only if globally installed packages publish more skills than a developer wants), then run the sync once and verify that the first-run reaping removed the old nested copies. Note the reaping is deliberately non-destructive — a nested file the developer edited is left behind — so plan a manual sweep for orphaned ~/.{agent}/skills/<vendor>__<package>/ directories, plus any leftover ~/.{agent}/skills/<package-basename>/ folders from the now-removed 0.3 → 0.4 migration. Also note the rename is not cosmetic: backticked skill names, slash commands, and relative skill links in .md files are rewritten, so any internal documentation that references skills by their old qualified names needs a grep and update. Keep the committed-output model as the default for project scope; it makes behavior observable in review.

Compatibility. Verify the supported PHP range against the oldest PHP we still run, and confirm behavior under Composer 2 with a committed lockfile. Because the package is framework-free, compatibility is almost entirely about PHP version and CI runner environment. Two new compatibility checks specific to this release: (a) confirm the reaping logic behaves correctly on case-sensitive Linux CI versus macOS dev machines, since skill names are now filesystem-visible identifiers and collisions across ten agent directories are a realistic failure mode; (b) confirm behavior on developer machines where ~/.{agent}/skills/ is itself a symlink or contains symlinked skills — the release refuses to write through symlinks at target paths, which is the right safety posture but means those developers will see silent no-ops and need to be told why.

Sequencing.

1. Sandbox spike in a throwaway branch: run project-scope sync, inspect output quality for all ten targets, and trim withAgents() to the two or three agents actually in use.
2. Content taxonomy workshop: define what belongs in skills vs guidelines vs commands, and codify what must never enter .ai/ (secrets, customer data, internal hostnames).
3. Pilot in one repo with committed output and a CODEOWNERS entry for .ai/.
4. Add a CI gate: sync then assert a clean tree (drift check), plus a pre-commit hook; evaluate whether --check can serve as the single check command.
5. Evaluate user-scope adoption separately with a small group: read UPGRADING.md, run one sync, verify the reap, sweep orphans, and decide whether ~/.boost/user-scope.php is needed at all.
6. Expand to three to five repos; measure diff volume and reviewer friction.
7. Re-evaluate formally at the next minor release or after one quarter of observed cadence — whichever comes first — before any org-wide mandate. Add a standing rule that minor releases are read for migration notes before any sync runs, since 1.13.0 demonstrates minors can carry breaking path changes.

Operational Impact

Maintenance. The recurring cost remains content stewardship, and 1.13.0 adds a modest, well-signposted upgrade tax. Ten output directories still multiply review surface — a one-line guideline change produces ten file edits and invites rubber-stamping — so keep the dedicated .ai/ owner group, the "review at the source, not the diff" convention, and the runbook. New this release: maintain a short user-scope runbook covering the -user naming convention, the ~/.boost/user-scope.php selector, and the expectation that skill identifiers can be renamed between minor versions with automatic link rewriting. Pin to exact versions so upgrades are deliberate; the changelog-plus-UPGRADING.md discipline makes a deliberate upgrade cheap, but only if someone actually reads it.

Support. Still effectively self-support at this adoption level, but the trajectory is encouraging: consecutive releases, a documented upgrade path, and defensive engineering (ownership checks, symlink refusal, deterministic clash resolution, invalid-config-fails-closed with no reaping on error) are the behaviors of a maintainer who expects others to depend on this. MIT license still permits forking, the codebase appears small and readable, and the docs site plus llms.txt remain unusually good for agent-assisted troubleshooting. Keep the internal fork-or-vendor contingency documented in the adoption record with a named owner, and log the single-maintainer dependency as a tracked vendor risk. Downgrade the "abandonment" likelihood slightly; upgrade the "we get surprised by a breaking minor because nobody read the notes" likelihood.

Scaling. Scales linearly and cheaply: no service, no quota, no per-seat cost. The constraint is cognitive, not infrastructural. At ten-plus repos, distribute a shared .ai/ baseline as a private Composer package or submodule and let repos layer local additions rather than copy-pasting directories. Trim the agent list — ten agents is more than most teams read, and each one carried is exposure to format churn. User scope scales differently and worse: it is N developers × M globally installed packages, with the first-package-by-name-wins rule making the effective skill set machine-dependent. If a team standardizes on user-scope skills, the honest answer is that it becomes unmanaged per-machine state — either accept that, or push the content into project scope where it is versioned and reviewable.

Failure modes.

• Breaking path/name changes in a minor release — mitigated by reading UPGRADING.md before every sync; make this a checklist item, not a virtue.
• Developers syncing user scope without reading the notes and ending up with a mix of old nested and new flat skills — run the reap, then sweep remaining orphan directories (including pre-0.4 leftovers) manually.
• Silent no-op where boost refuses to write over an unowned file or through a symlink — correct behavior, but invisible; add it to the troubleshooting runbook.
• Skill-name clash across globally installed packages where the "wrong" package wins by alphabetical order — use ~/.boost/user-scope.php to pin intent, and treat --check output as a required review artifact.
• Stale or invalid ~/.boost/user-scope.php — fails closed and reaps nothing, which is safe but means a typo silently blocks publication; validate after edits.
• Upstream agent-format drift producing valid-looking but ineffective files — pin versions and re-validate with a smoke test on one real prompt workflow after each upgrade.
• Generated-file churn drowning meaningful diffs — trim the agent list and hold the review convention.
• Version skew across repos causing agents to behave differently per project — centralize the pinned version in the shared baseline package.
• Silent overwrite of hand-edited generated output — now defended against at user scope; confirm project-scope parity and back it with the CI drift check.
• Prompt-injection or secret leakage through generated content — treat .ai/ as a public artifact; add a pre-commit secret scan and keep environment-specific values out.
• Abandonment or a stale release — escape hatch remains fork-and-patch or a hand-maintained script; hours, not weeks.

Ramp-up. Measured in hours for project scope, plus roughly thirty minutes per developer for the user-scope migration if they use it at all. Installation and first sync are trivial; the real time goes into the content taxonomy workshop and governance rules — realistically half a day for a team lead plus a short onboarding note. Because output is plain text and the tool is developer-facing, onboarding risk stays inside the engineering org and never reaches production availability or customer-facing behavior. Recommendation: pilot, do not standardize — the underlying problem (multi-agent config sprawl) is real, 1.13.0 is evidence of active and careful maintenance, and the opportunity score relative to maturity still supports investment. But two releases do not make a support guarantee, generated-path stability is not yet established as semver-protected, and the maintainer base remains one person. Pilot project scope first, run user scope as a separate opt-in experiment, and revisit the standardization decision at the next minor release.