Adminix Documentation Help

Laravel Boost

Adminix ships Laravel Boost resources for projects that install this package.

Files

  • resources/boost/guidelines/core.blade.php - short Adminix setup, package usage, storage, queue, upload, and safety rules.

  • resources/boost/skills/adminix-development/SKILL.md - the operational Adminix reference for installation, authorization, page providers, menus, lists, filters, actions, resource forms, modal CRUD, imports, charts, links, safety, and verification.

Discovery

When a parent Laravel project has Adminix installed, Laravel Boost can discover package guidance during:

php artisan boost:install php artisan boost:update --discover

Keep guidelines compact. Keep the skill high-signal but detailed enough for agents to build or review Adminix modules without guessing method names, field options, filter behavior, or modal contracts. The skill is an operational reference, not a replacement for the full Writerside documentation.

When updating Boost resources, use the same documentation standard as the public docs: start with the practical path, include runnable code or commands, state the expected result, and keep the important package safety caveat close to the example. Do not paste whole Writerside topics into Boost; link the behavior back to the compact rule that an agent needs while editing a Laravel project.

Page provider snippets

The Adminix development skill includes compact snippets for common page-provider work:

  • a tenant-scoped list page;

  • a queued CSV import configuration with explicit application-owned idempotency and authorization boundaries;

  • a starter Testbench assertion for generated page providers.

Use them after previewing the generated provider path:

php artisan make:adminix_page OrdersPage --tests --dry-run php artisan make:adminix_page OrdersPage --tests

The snippets are intentionally short. They are not a separate code generator and they do not replace reviewing the consuming application's model, policy, tenant scope, validation, and write authorization rules.

Contract verification

Boost resources are executable guidance, so byte-size checks alone are not enough. tests/Unit/BoostResourcesTest.php protects high-risk content contracts: the exact Composer package name and supported runtime, the documented installation/auth/migration/Doctor sequence, built-in saved-table-view storage, queue-handler ownership, and the difference between scalar image values and managed uploads. The same test keeps the skill within 500 lines and 30,000 bytes and the compact guideline within 4,000 bytes. It also prevents the resources from claiming that queued bulk execution restores an authenticated actor or reruns its web-dispatch authorization callback. It does not execute those runtime flows; feature tests, supported-database migration tests, and the full package suite provide that verification separately.

After changing either resource, run:

./vendor/bin/phpunit tests/Unit/BoostResourcesTest.php

Then exercise fresh-context scenarios that do not reveal the expected answer to the agent. At minimum, ask a clean agent to:

  • install Adminix in a new supported Laravel application and enable standard saved table views;

  • design a tenant-scoped page with a privileged write;

  • configure a queued CSV import that may be delivered more than once.

Review the proposed commands and code against the package source and tests. The scenarios must catch guessed package names, custom-storage inventions, browser-authoritative tenant IDs, and claims that Adminix makes application handlers idempotent or restores an authenticated queue user.

Last modified: 23 July 2026