Appearance
Working with coding agents
Laraspring is built to be driven by a coding agent, and that claim is narrower and more useful than it sounds. It does not mean the kit writes your product for you. It means an agent pointed at this repository already knows where a feature goes, which conventions it has to follow, and how to prove it did not break anything, without you explaining any of it first.
Three things carry that, and every one of them is a file in the repository rather than a promise on a landing page.
1. AGENTS.md states the conventions
The root AGENTS.md is written for an agent working on your product: the map of the repository, the decision of whether a feature belongs in your edition or in a package of its own, the recipes for a screen, a migration, a translation or an upload, the five contracts in laraspring/core and when to rebind one, the surfaces that are public API, and the traps that catch a first run.
It is the file most agents read on their own. Claude Code, Cursor and Copilot all look for it or for a pointer to it, and CLAUDE.md at the root is that pointer for Anthropic's tools.
Kit-internal conventions, the ones that only matter if you are changing packages/, live separately in CONTRIBUTING.md, so an agent building your product never has to read past what applies to it.
2. Skills turn a convention into a procedure
Knowing that "every string a person reads goes through a translation file" is not the same as knowing which two files to open and what the key looks like on the React side. The skills under .claude/skills/ close that gap: six step-by-step procedures for the jobs you will actually repeat, written against real paths and real commands.
They are plain markdown with a small frontmatter block. Claude Code loads one by name when a task matches its description; any other agent can read the same file.
3. The gates are the safety net
This is the part that makes the rest safe rather than merely fast.
Every change, whoever or whatever wrote it, has to survive the same checks:
bash
cd apps/saas # or apps/vue, whichever edition you have
npm run build # first, or the tests fail on a missing Vite manifest
php artisan test # the application suite
npm run types # tsc --noEmit; Vite strips types without checking them
npm run lint:check # ESLint, failing rather than fixing
npm run format:check # Prettier
vendor/bin/pint --test # PHP formattingEach Laraspring package additionally carries a suite that boots it with no edition around it, and each runs as its own job in CI, so a package that only works because the application happens to paper over it fails anyway.
859 tests ship with the kit before you write a line. That number is what an agent is actually working against: it can try something, run the suite, and find out. An agent with a fast, honest failure signal behaves very differently from one without, and most of the value here is in that loop rather than in any individual instruction.
The kit is also careful that a mistake is loud. A missing translation would normally fall back to English and look correct until a Spanish speaker read the screen, so TranslationParityTest fails on it instead. A plan with a missing price identifier raises at the configuration boundary rather than at checkout. That bias, refuse early and say why, is what makes an agent's output reviewable.
What this does not mean
An agent will not choose your product's architecture, and it should not. The decisions the kit has already made, which package owns what, which way dependencies flow, what is public API, are exactly the decisions it is not equipped to make well. What it is good at is the hundredth screen written the same way as the first, and that is what the conventions and the skills are for.