Laravel Boost Copilot Cli Laravel Package

Product Decisions This Supports

• AI-assisted development workflow standardization. This package is a thin adapter that lets GitHub Copilot CLI consume Laravel Boost's curated project context and tooling. It directly supports the decision of which AI coding assistant your team standardizes on, and whether that choice can be decoupled from the framework-specific context layer underneath.
• Build vs. buy vs. wait on the AI context layer. Laravel Boost is the "official" context server; this package is a community bridge to one specific client. The decision it informs is whether to (a) adopt a bridge now, (b) build an internal adapter, or (c) wait for first-party Copilot CLI support. With minimal stars and zero dependents, this is still a signal of demand, not a dependency to standardize on.
• Where configuration lives in the repo (new in 2.3.0). The default MCP config path now points at .github/mcp.json rather than a package-defined location. That is a small but strategically useful shift: assistant context becomes a first-class, repo-local, version-controlled artifact living next to workflows and issue templates, discoverable by any tool that already reads .github/. It strengthens the case for "context as a checked-in repo asset" over "context as per-developer local setup"—which is the durable part of this pattern regardless of which adapter you use.
• Roadmap input for developer experience (DX) and onboarding. If your roadmap includes "new engineers productive in days, not weeks" or "consistent AI suggestions across the team," the underlying pattern—shipping a versioned, repo-local context bundle so every assistant gives framework-accurate answers—is roadmap-worthy even if this specific package is not. A default path under .github/ makes that pattern easier to explain and adopt without a package-specific convention.
• Vendor and tool-portability strategy. Adopting an adapter layer implies you value portability across assistants (Copilot CLI today, Claude Code or Cursor tomorrow). Standardizing on a .github/mcp.json-style location reduces the cost of that portability bet by anchoring context to the repo rather than to a vendor's config schema.
• Tooling budget and support allocation. Informs whether to spend engineering hours on community glue versus pinning to a supported, maintained integration—useful input to next-quarter platform/infra allocation. The 2.3.0 release shows routine maintenance (dependency bump, contributor PR) but does not change the support calculus.
• Evaluation of internal AI pilots. A low-cost way to run a contained pilot: does giving Copilot CLI real Laravel context measurably improve suggestion quality, review time, or test-writing speed? The package is cheap enough to test the hypothesis.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is Laravel/PHP and you already use (or are trialing) GitHub Copilot CLI as an interactive terminal assistant.
• You want framework-aware context—routes, models, conventions, available Artisan commands—rather than generic LLM guesses about Laravel idioms.
• You are comfortable committing MCP context at .github/mcp.json (the new default since 2.3.0) and treating it as a reviewed repo artifact. If your org restricts what may live under .github/, or you already have a different canonical location for assistant config, plan to override the path explicitly and document it.
• You are running a time-boxed pilot or spike, where a single-maintainer adapter is an acceptable risk because the blast radius is one developer's terminal session.
• You have engineering capacity to read the source (it's MIT and small) and pin a commit or fork it if the maintainer disappears.
• You accept a low-support-ceiling tradeoff: you are trading official support and SLAs for early access and a small surface area.

Look elsewhere when:

• You need production or org-wide guarantees—no dependents, minimal stars, and a single maintainer mean the bus factor is effectively one. Prefer first-party Laravel Boost integrations or your own thin wrapper you control.
• Your team is standardized on Claude Code, Cursor, or another client—this adapter is Copilot-CLI-specific and adds maintenance overhead for no benefit.
• You are not on Laravel Boost already; the adapter only makes sense as an extension of that context layer.
• Security or compliance review requires established provenance, release cadence, and disclosure processes. A dependency bump and a path-default change do not constitute an adoption or review history.
• The assistant vendor ships native support for MCP-style Laravel context—at which point the bridge is redundant and should be retired, not defended.

Upgrading note for anyone already pinned: 2.3.0 changes the default MCP config path to .github/mcp.json. Existing setups that relied on the previous default will need their config moved or the path set explicitly. Treat this as a migration step, verify it in the pilot branch, and keep the pinned version recorded so the change is intentional rather than incidental.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our engineers increasingly use AI coding assistants, but generic assistants know little about our Laravel codebase and tend to suggest patterns we don't use—costing review time and rework. Laravel Boost solves the context problem for Laravel specifically; this package extends that context to GitHub Copilot CLI. It is a small, MIT-licensed community adapter with essentially no adoption yet, so I am not recommending it as a platform dependency. I am recommending a two-to-four week, two-engineer pilot to measure whether framework-aware context measurably improves assistant usefulness. The latest release moved the default config to .github/mcp.json, which is the right direction—context becomes a reviewed file in the repo, not a per-machine setup—but it also means a config migration for anyone already testing it. If the pilot shows benefit, we invest in a supported path (first-party integration or a wrapper we own); if not, we've spent almost nothing and learned where AI tooling actually pays off.

For engineering leadership: Treat this as a reference implementation, not a library. It validates the architecture we'd want anyway—a versioned context bundle checked into the repo at a conventional, tool-neutral path (.github/mcp.json as of 2.3.0), consumed by whichever assistant a developer prefers—so it de-risks the build-vs-buy decision by letting us prototype the integration in days. The 2.3.0 changelog is small and expected: a CI action bump via Dependabot and the config-path change. That is evidence of light maintenance hygiene, not of a support commitment. Recommended actions: pin to a specific commit (2.3.0 or later), fork if we go beyond the pilot, assign one owner, fold the .github/mcp.json path into our repo conventions, and set an explicit review date to reassess against native Copilot CLI or Laravel Boost support. Explicitly flag the risks: single maintainer, zero dependents, no security review trail, and default-path changes like this one that can silently affect existing setups. Do not add it to shared tooling images or CI until the pilot produces evidence.

For the pilot team: Success criteria up front—median time-to-first-useful-suggestion on an unfamiliar module, PR review comment volume on AI-drafted code, and developer-reported trust in suggestions—measured against Copilot CLI without the adapter. Start the pilot on 2.3.0 so the .github/mcp.json layout is what we evaluate, and note any friction from the path change in your write-up, since that friction is itself a finding about how much we should invest in repo-local assistant context. Kill the pilot if the deltas are within noise.