Working with Claude Code

Everything here works with any coding agent that can read files and run commands. Claude Code needs the least setup, because the conventions are already where it looks.

Getting started

bin/setup --demo
cd apps/saas          # or apps/vue, whichever edition you have
claude

Nothing else. CLAUDE.md at the repository root points at AGENTS.md, and .claude/skills/ is discovered automatically. The first thing worth doing is asking it to read the guide, so the conventions are in context before it writes anything:

Read AGENTS.md, then tell me where a "projects" feature should live in this codebase and why.

The answer should be your edition, with the reasoning that a package is a boundary with a maintenance cost and one consumer. If it proposes a package instead, the conventions did not land and it is worth starting again rather than reviewing the diff.

Asking for work

Skills trigger on what you describe, not on a command you have to remember. Each of these matches one:

Add a settings screen where a user can manage their API tokens.

Add a "Team" plan at $99 a month with 100 seats and a 14-day trial.

We're launching in Germany. Add German.

Change the email branding to our colours and put our office address in the footer.

Pull the new kit version and tell me what I need to merge by hand.

You can also name one directly: use the add-a-screen skill to build a projects list.

The skills are ordinary markdown. Read .claude/skills/add-a-screen/SKILL.md yourself before trusting it with something important; it is short, it is the same thing the agent reads, and the skills reference summarises all seven.

Reviewing what comes back

Ask for the gates, and read the output rather than the summary:

Run npm run build, php artisan test, npm run types and npm run lint:check, and show me the failures.

Three specific things to check by eye, because the suite will not catch them:

Nothing under packages/ changed. git diff --stat packages/ should be empty. An edit there is silently discarded on the next upgrade, and it is the single most expensive mistake available in this repository.

No sentence was typed into a component. Every string a person reads belongs in lang/{locale}/app.php. TranslationParityTest catches a key missing from a locale, but it cannot catch a string that never became a key at all.

Queries are scoped to the tenant. The kit scopes its own tables; a model you added is yours to scope. A missing organization_id on a query is a cross-tenant data leak that passes every test you have.

Two things worth telling it up front

Which tenant a new model belongs to. "Projects belong to an organization" is one sentence that removes a whole class of wrong guess, because the agent then knows to add the foreign key, scope the queries and reach for Organizations::current() rather than auth()->user().

Whether a feature is behind a plan. "Only Pro and above" tells it to use Billing::subscribed(null, 'pro') rather than inventing its own check against a price identifier.

When it gets stuck

The kit's own error messages are written to be read by whoever hits them, so paste them back verbatim rather than paraphrasing.

Two failures come up often enough to name here:

"Vite manifest not found" is environment, not a regression. npm run build has not been run. Several feature tests render Inertia pages and need public/build to exist.

A string rendering as its dotted key means either the locale file is missing the key or the translation group is not exported in app/I18n/LaraspringTranslations.php. Check the export list first; it is the one that produces no error anywhere.

Other agents

Nothing here is Anthropic-specific.

Cursor and Copilot read AGENTS.md at the root, which is the same file. Point them at a skill by path when you want a specific procedure followed: follow .claude/skills/add-a-locale/SKILL.md and add German.

Any other tool can be given AGENTS.md as context. The gates are ordinary npm and artisan commands, so whatever runs a shell can verify its own work.