Claude Php Setup Laravel Package

Product Decisions This Supports

• Adopting AI coding assistants as a team capability, not a per-engineer habit. The package's job is to generate the context layer (root CLAUDE.md, slash commands, subagent definitions) that makes Claude Code useful on a PHP codebase. That is the difference between "everyone prompts differently" and "the assistant knows our conventions" — a measurable onboarding and consistency decision.
• Roadmap sequencing for developer-experience (DevEx) work. If AI-assisted development is on the roadmap, this is the cheapest possible first step: a scaffolding generator, no runtime footprint, no service dependency, no data leaving the repo beyond what the assistant already sees. It answers "do we standardize assistant context files?" before you commit engineering time to a bespoke solution.
• Build vs. buy (really: build vs. fork vs. write-by-hand). The honest comparison has three options — (a) spend an hour having an engineer hand-write CLAUDE.md, (b) fork this MIT CLI and own it, (c) adopt a maintained alternative. This package only wins on (b), and only if the generated templates encode conventions your team hasn't articulated yet. The decision is worth making explicitly rather than defaulting to whichever link a developer found.
• Convention codification as a forcing function. The generator emits opinionated rules (strict typing, final classes, DI over abstractions, BC-preservation, English PHPDoc, no tool attribution in commits). Reviewing those generated rules is a fast, low-stakes way to surface disagreements your team has been silently absorbing for years — a useful artifact for an architecture or standards review even if you never run the tool again.
• Spec-driven development pilot. The bundled speckit-* skills (analyze, prerequisites checks, extension hooks, read-only analysis of spec/plan/tasks) point at a workflow where the assistant audits specifications rather than writing code. If you're evaluating whether structured prompting beats ad-hoc prompting, this is a ready-made script to test that hypothesis.
• Concrete use cases: bootstrapping AI context for a legacy Laravel/Symfony repo before a migration; standardizing CLAUDE.md across several packages; producing a reviewed, version-controlled "house rules" document; onboarding contractors who must follow your conventions from day one.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is PHP, ideally Symfony or Laravel, and your engineers are already using or trialing Claude Code.
• You are willing to fork and own it. Adoption here is adoption of MIT-licensed source, not of a vendor. Budget an owner and a few hours per year.
• You want a starting point for conventions — you'll review and edit every generated file rather than trusting the defaults.
• Risk tolerance is genuinely low: it's a dev-machine CLI emitting markdown, with no runtime, build, or deployment coupling. Worst case is a wasted afternoon.

Look elsewhere — or don't bother — when:

• You need maintained software. The package is explicitly abandoned, has one star, zero dependents, and no release cadence you can rely on. If your org requires a support path, security response, or an upgrade story, this fails procurement before it fails technically.
• A hand-written context file is enough. For a single small repo, an engineer writing CLAUDE.md directly is faster than evaluating, forking, and regenerating. This tool's value scales with the number of repos and the complexity of conventions, not with enthusiasm.
• You are not on PHP, or you're on a heavily customized stack where the generated rules will be immediately wrong and the editing cost exceeds the writing cost.
• Your assistant strategy is unsettled. If you haven't chosen tooling, or you're multi-assistant (Copilot, Cursor, Claude), a Claude-specific generator narrows you prematurely; prefer a neutral conventions doc that each tool can consume.
• Monorepo or unusual layout. Generators assume conventional structures; expect manual reconciliation.

Recommendation: treat this as a spike input, not a dependency. Timebox an evaluation — one engineer, one repo, one afternoon — with the exit criterion "does a reviewed, edited output beat what we'd write freehand?" If yes, fork it, strip anything you don't want, and stop tracking upstream. Do not add it to any automated pipeline or CI.

How to Pitch It (Stakeholders)

To executives (60 seconds): This is a free, MIT-licensed developer utility that generates the instruction files our engineers feed to AI coding assistants. Cost is a few hours of one engineer's time; there is no runtime dependency, no vendor relationship, no customer data involved, and no lock-in — the output is plain markdown we own and version in Git. The realistic upside is consistency: assistant-generated code that follows our conventions instead of each engineer's improvisation. The realistic downside is a wasted afternoon. One caveat stated plainly: the project is abandoned, so if we find it useful we adopt the code, not the project — we fork it and maintain our copy, and we don't build anything on top of it that we'd have to unwind later.

To engineering leadership: The reason to look at it is the content, not the tool. Its templates encode a coherent PHP/Symfony posture — strict typing, final classes, constructor injection, no BC breaks without explicit sign-off, tests next to changed behavior, changelog and upgrade notes kept in sync — plus an opinionated set of assistant workflows for reviewing a specification before implementation. That's a reviewable, editable artifact, which makes it a good vehicle for a standards conversation. It's also the reason not to adopt it blindly: you'll disagree with some rules, and you should, in writing, before they get baked into a thousand AI-generated pull requests.

To security and platform: No runtime footprint, no network calls at build or deploy time, no secrets handling, no CI integration required. MIT license is permissive; the code is small and inspectable. The material risks are supply-chain hygiene (the package is unmaintained, so pin or vendor the fork) and the more subtle one: whatever conventions you generate become de facto policy for AI-authored code, so the content deserves a standards owner even though the tool doesn't.

The ask: one engineer, one afternoon, one repo, a written verdict on whether the output beats hand-written context. If it doesn't, we've spent an afternoon and learned what we think our conventions are — which we needed anyway.