README

AI agent guidelines and skills for the LaravelUi5 stack.

composer require laravelui5/chiron --dev
php artisan boost:install

When the installer asks "Which third-party AI guidelines/skills would you like to install?", tick laravelui5/chiron. Third-party material is opt-in — Boost will not take it without being told, and a scripted boost:install --no-interaction silently installs nothing from any third-party package until the choice is recorded in boost.json.

Your coding agent now knows how to write laravelui5/* — instead of guessing at it.

What this is

Laravel Boost lets a package teach the agent that works on its users' code. Chiron is the LaravelUi5 stack's half of that: one package carrying the guidelines (loaded upfront, every session) and the Agent Skills (loaded on demand) for laravelui5/odata, laravelui5/core and laravelui5/sdk.

It is named after the centaur who taught Achilles, Jason and Asclepius — the one who never fought a battle himself, and trained everyone who did.

What it contains — and nothing else

No PHP. No service provider, no autoloading, not a single class. Boost reads resources/boost/ straight out of the vendor directory, so this package is prose and nothing but prose. It cannot break, because it does not run.

resources/boost/
├── guidelines/core.blade.php          always loaded; sections render only for what you installed
└── skills/                            loaded on demand, when the task matches
    │                                  — laravelui5/odata —
    ├── laravelui5-odata-modeling/     a read surface: the decision tree, the perf gate, discovery,
    │                                  custom entity sets, annotations and code lists, the URL surface
    │                                  — laravelui5/core —
    ├── laravelui5-modules/            the module as a Composer package: ui5:app/ui5:lib, registration,
    │                                  how the UI5 sources reach the browser
    ├── laravelui5-artifacts/          which artifact to use (app, card, tile, chart, dashboard, report,
    │                                  resource …), and the provider behind it
    ├── laravelui5-actions/            every write is a Ui5Action; the handler contract adapts to
    │                                  Core-only or SDK installations
    │                                  — laravelui5/sdk —
    ├── laravelui5-dialogs/            global dialogs as shell-dispatched artifacts
    ├── laravelui5-security/           time-aware RBAC: #[Access], #[Act], See, #[Read], scoped roles
    ├── laravelui5-partners/           the partner model: the actor, org partners, the four "roles"
    ├── laravelui5-settings/           Setting vs Slot vs Customizing, and how each is declared
    └── laravelui5-shell/              LeanShell: navigation, command palette, help, value helps, intents

For the same reason it declares no require. Nothing here is executed, so nothing here has a platform requirement — and a php constraint would only stop someone from installing the package before they install the stack, which is one of the moments it is most useful.

A skill's SKILL file is the short instruction an agent loads first. Where a topic is large (OData modelling, artifacts, security, settings), the detail sits in the skill's references/ folder, and the agent reads only the part it is working on.

One package for three, on purpose

Boost loads a package's material only when that package is a direct dependency of the application — laravel/roster marks direct from the app's own composer.json. laravelui5/core requires laravelui5/odata, so a host that follows the install guide has OData as a transitive dependency, and Boost would never load its guidelines. Shipping the material inside the runtime packages therefore misses exactly the people who followed the instructions.

One package that the host requires directly fixes that by construction. It also decouples two things that have no business sharing a release: guidelines want to be rewritten the week you learn what an agent confuses; runtime packages are on strict SemVer with a tag, a Satis rebuild and a smoke test.

Sections are guarded, so you only get what applies to you:

@if (class_exists(\LaravelUi5\Core\CoreLibrary::class)) … @endif

With nothing installed, you still get the overview — which is the point when you are evaluating the stack rather than running it.

Keeping it current

php artisan boost:update            # refresh what is already published
php artisan boost:update --discover # also pick up newly installed packages

To have it happen on every composer update, add it to your application's scripts:

{
    "scripts": {
        "post-update-cmd": ["@php artisan boost:update --ansi"]
    }
}

Versioning

Chiron is versioned independently of the packages it describes — that independence is why it exists. Each release states in its changelog which majors of odata, core and sdk it was written against, and its composer.json enforces that with a conflict on the next major of each:

"conflict": {
    "laravelui5/odata": ">=4.0",
    "laravelui5/core": ">=3.0",
    "laravelui5/sdk": ">=2.0"
}

So guidance never outlives the major it was written for. Moving your app to the next major of any of the three needs a Chiron release that covers it, and Composer says so instead of handing your agent instructions for the version you just left. Requiring Chiron before you install the stack is unaffected — a conflict only applies to what is installed. Guidance that depends on a particular version within the range — a major, or a minor such as since odata 3.1 — says so inline.

Licence

MIT. See LICENSE.

The packages it describes are licensed separately: laravelui5/odata MIT, laravelui5/core under the Business Source License 1.1 (production use granted), laravelui5/sdk commercially.

laravelui5 / chiron

Package info

Security

Statistics