Worktree Prompt Laravel Package

Product Decisions This Supports

• Developer experience roadmap: Decides whether to standardize “one command to create a working Laravel worktree” as an internal workflow, instead of relying on ad hoc shell scripts and tribal setup knowledge.
• Build vs. buy for internal tooling: Weighs maintaining our own worktree/bootstrap scripts against adopting lwt, which already handles Composer/npm reuse, .env copying, storage/build folders, database creation, migrations, and idempotent re-runs.
• Parallel delivery model: Supports feature + hotfix workstreams, multiple review checkouts, QA of several branches, and isolated experiments without stashing or cloning repeatedly.
• AI-agent development workflow: lwt setup is directly useful when agents create their own worktrees (e.g. .claude/worktrees/), turning agent-created checkouts into runnable Laravel apps.
• Environment isolation policy: Per-worktree databases (--db=copy|empty) and --url reduce cross-branch database collisions and make migrations safer to test.
• Onboarding investment: Reduces time-to-first-PR by codifying setup steps, but raises policy questions around copying .env files and creating/dropping databases.
• Adoption risk decision: v1.0.0 is a first release; treat it as a dev-tooling pilot, pin the version, and trial on a secondary repository before mandating it.

When to Consider This Package

• Consider it when the team already uses, or wants to adopt, git worktrees for Laravel projects and wants setup/teardown automated.
• Good fit for standard Laravel layouts using Composer, npm, and Postgres/MySQL/MariaDB/SQLite, with local development on macOS/Linux; validate Windows/WSL behavior separately.
• Strong fit when developers need multiple runnable branches at once: feature work alongside hotfixes, review checkouts, QA branches, or AI-agent worktrees.
• Useful when setup repeatedly involves the same manual steps: .env copying, storage/ and bootstrap/cache, public/build, public/storage, database creation, and migrations.
• Also consider lwt setup [path] if worktrees are created by other tools or agents and need to be made runnable safely and repeatably.
• Look elsewhere or wrap carefully if the team relies on Docker/Sail/Devcontainers, remote/ephemeral environments, nonstandard monorepos, custom secret management, or strict controls preventing .env copying and database create/drop.
• Defer broad rollout until v1.0.0 has been piloted; it is not a runtime dependency, but it touches developer machines, databases, and environment files.

How to Pitch It (Stakeholders)

For executives: This is a low-cost developer-productivity tool, not a production runtime dependency. It reduces setup toil and context switching, and makes parallel feature/hotfix work and AI-assisted development more practical by giving each branch its own runnable Laravel worktree and database. The main risks are tooling immaturity at v1.0.0 and local environment/security policy, so propose a small pilot with a pinned version.

For engineering: lwt turns git worktrees into runnable Laravel apps in one command: it reuses vendor/node_modules when lockfiles match, copies or links environment files, recreates storage/build artefacts, optionally provisions an isolated database, runs migrations, and cleans up safely by refusing dirty worktrees. It also supports worktrees created by other tools and AI agents. Trial it on a representative repo, confirm macOS/Linux and database assumptions, and document the .env/DB-admin policy before standardizing.