Laravel Boost Phpstorm Copilot Laravel Package

Product Decisions This Supports

• IDE-standardization decisions. If your engineering org is split between JetBrains (PhpStorm) and VS Code/Cursor users, this package is the cheapest path to giving PhpStorm users the same Laravel-aware AI context that Cursor/Claude Code users already get from Laravel Boost. It turns "should we force everyone onto one IDE?" into a much smaller, reversible configuration choice.
• Build vs. buy (really: adopt vs. vendor). The artifact here is small — an agent definition and MCP wiring that points PhpStorm's GitHub Copilot plugin at Laravel Boost's context. That's an afternoon of an engineer's time to reproduce internally. So the real decision is "consume this repo as a pinned, vendored config" vs. "write our own 40-line equivalent and own it." Both are cheap; the deciding factor is maintenance appetite, not cost.
• AI tooling pilot scoping. Good candidate for a 1-sprint, 1-team pilot (e.g., backend team on PhpStorm) with a clear success metric: fewer hallucinated Laravel APIs, less time re-explaining project conventions in chat, higher acceptance rate of Copilot suggestions in Laravel files. Kill/scale decision at the end.
• Roadmap signal for platform/DX investment. A 3-star, 0-dependent repo appearing within weeks of Laravel Boost's release is evidence that the "AI context for Laravel" surface is fragmenting by IDE and plugin. That argues for a roadmap item around internal, owned AI context distribution (a shared guidelines file + MCP config checked into each repo) rather than betting on any single third-party agent package.
• Risk register / supply-chain policy. With one maintainer, 3 stars, zero dependents and no downstream usage to shake out bugs, this belongs in the "evaluate, don't depend" tier. It informs a policy decision: third-party AI tooling configs are vendored and reviewed, never pulled transitively.

When to Consider This Package

Consider it when all of these hold:

• Your team is already on Laravel Boost (or is about to be) and wants its version-aware docs/guideline context available inside the IDE.
• The team's IDE is PhpStorm / JetBrains, and the AI assistant is GitHub Copilot via the plugin — not Claude Code, Cursor, or Copilot in VS Code, which have their own established paths.
• You can treat it as reference implementation + vendored config: read it, copy what you need into your repo, pin versions, and review diffs before upgrades.
• The pilot is time-boxed and non-critical — no CI gate, no mandatory onboarding dependency.
• Someone on the team owns PHP/Laravel + JetBrains tooling enough to debug config drift when PhpStorm or Copilot plugin versions move.

Look elsewhere (or just write it yourself) when:

• You need support, SLAs, or a maintainer who will respond. 3 stars / 0 dependents / single maintainer means an unowned bus factor. Not appropriate for a mandated org-wide standard.
• You're not on Laravel Boost. The package is an adapter, not a standalone value proposition — without Boost underneath it does very little.
• Your stack is Cursor/Claude Code/VS Code-first. Native or better-trodden paths exist; adding a JetBrains-specific shim is pure overhead.
• You need cross-IDE uniformity. A per-IDE agent file multiplies configs to maintain. If uniformity matters, prefer a repo-committed guidelines/context file plus each IDE's own MCP config, with this package as one input among several.
• Version risk is unacceptable. Verify PhpStorm, Copilot plugin, PHP and Laravel version compatibility yourself — the project is too young to have a compatibility matrix you can trust.

How to Pitch It (Stakeholders)

To executives (30 seconds): "Our Laravel developers on PhpStorm currently get worse AI assistance than colleagues on Cursor, purely because of IDE choice. This is a small, MIT-licensed open-source adapter that closes that gap for near-zero cost — no licenses, no vendor contract, a few engineer-hours to trial. It's a 3-star project with one maintainer, so we're running it as a one-team, one-sprint experiment and copying the config into our repo rather than depending on it. Expected upside is developer time saved and avoiding an IDE-migration mandate; downside is bounded to a few hours."

To engineering leadership: "It's a thin adapter — an agent definition plus MCP configuration — that wires Laravel Boost's Laravel-specific context into PhpStorm's GitHub Copilot plugin. It buys us consistency in AI-generated Laravel code across IDEs. We'll vendor it into a repo, pin it, and review changes; if it goes stale we own an equivalent config in under a day. Success looks like: fewer invented Laravel APIs in review, fewer repeated context explanations in chat, measurable Copilot acceptance in Laravel files after four weeks."

To the piloting engineers: "Treat this as a starting template, not a dependency. Read the agent definition, copy the parts that fit our conventions, check it in, and write down the PhpStorm/Copilot/PHP/Laravel versions it works with. Instrument before/after so we can defend or kill it with data — and flag any config fragility early, because upstream fixes will come from us, not from a maintainer."