AGENTS.md

=== foundation rules ===

Laravel Boost Guidelines

The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to ensure the best experience when building Laravel applications.

Foundational Context

This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions.

• database - PostgreSQL

• php - 8.4

• inertiajs/inertia-laravel (INERTIA_LARAVEL) - v3

• laravel/ai (AI) - v0

• laravel/cashier (CASHIER) - v16

• laravel/framework (LARAVEL) - v13

• laravel/prompts (PROMPTS) - v0

• laravel/socialite (SOCIALITE) - v5

• tightenco/ziggy (ZIGGY) - v2

• larastan/larastan (LARASTAN) - v3

• laravel/boost (BOOST) - v2

• laravel/mcp (MCP) - v0

• laravel/pail (PAIL) - v1

• laravel/pint (PINT) - v1

• laravel/sail (SAIL) - v1

• phpunit/phpunit (PHPUNIT) - v13

• rector/rector (RECTOR) - v2

• @inertiajs/react (INERTIA_REACT) - v3

• react (REACT) - v19

• tailwindcss (TAILWINDCSS) - v4

• eslint (ESLINT) - v9

• prettier (PRETTIER) - v3

Skills Activation

This project has domain-specific skills available. You MUST activate the relevant skill whenever you work in that domain—don't wait until you're stuck.

• shadcn — Activates whenever working with shadcn/ui components, components.json, registry items, presets, generated blocks, or component composition/styling fixes. Use when adding or updating shadcn components, checking registry docs/examples, or deciding whether to reuse an existing shadcn primitive before building custom UI.
• ziggy-development — Activates whenever referencing backend routes in frontend components. Use when generating URLs with Ziggy's route() function, working with named Laravel routes in TypeScript, or debugging route resolution.
• cashier-stripe-development — Handles Laravel Cashier Stripe integration including subscriptions, webhooks, Stripe Checkout, invoices, charges, refunds, trials, coupons, metered billing, and payment failure handling. Triggered when a user mentions Cashier, Billable, IncompletePayment, stripe_id, newSubscription, Stripe subscriptions, or billing. Also applies when setting up webhooks, handling SCA/3DS payment failures, testing with Stripe test cards, or troubleshooting incomplete subscriptions, CSRF webhook errors, or migration publish issues.
• socialite-development — Manages OAuth social authentication with Laravel Socialite. Activate when adding social login providers; configuring OAuth redirect/callback flows; retrieving authenticated user details; customizing scopes or parameters; setting up community providers; testing with Socialite fakes; or when the user mentions social login, OAuth, Socialite, or third-party authentication.
• inertia-react-development — Develops Inertia.js v3 React client-side applications. Activates when creating React pages, forms, or navigation; using , , useForm, useHttp, useLayoutProps, or router; working with deferred props, prefetching, optimistic updates, instant visits, or polling; or when user mentions React with Inertia, React pages, React forms, or React navigation.
• inertia-form-system — Builds and updates application forms using the shared Inertia + shadcn form system. Use when creating or refactoring React forms, adding client-side validation, wiring dirty-form protection, showing consistent field errors, working with success/error toasts, or deciding between the shared form hook and raw Inertia forms.
• tailwindcss-development — Always invoke when the user's message includes 'tailwind' in any form. Also invoke for: building responsive grid layouts (multi-column card grids, product grids), flex/grid page structures (dashboards with sidebars, fixed topbars, mobile-toggle navs), styling UI components (cards, tables, navbars, pricing sections, forms, inputs, badges), adding dark mode variants, fixing spacing or typography, and Tailwind v3/v4 work. The core use case: writing or fixing Tailwind utility classes in HTML templates (Blade, JSX, Vue). Skip for backend PHP logic, database queries, API routes, JavaScript with no HTML/CSS component, CSS file audits, build tool configuration, and vanilla CSS.
• datagrid — Builds and configures datagrid (data table) views in this project. Use when creating index pages with tables, card grids, filters, tabs, sorting, pagination, row actions, bulk actions, custom cell/card rendering, shared scaffold datagrid adapters, or common datagrid preset patterns.
• laravel-inertia-crud-development — Activates whenever building or expanding CRUD resources in this project. Use when creating Laravel models, migrations, factories, seeders, form requests, resource controllers, Inertia pages, Ziggy-backed forms, filtering/sorting/pagination, scaffold-generated CRUD resources, or PHPUnit CRUD coverage.
• module-development — Activates when creating new modules, adding features to existing modules, working with module config files (navigation, abilities), module service providers, module database classes (factories, seeders), module manifests, module diagnostics, or module testing. Use when any work involves the modules/ directory.
• pull-request-review — Reviews GitHub pull requests from URLs, fetches PR branches locally, compares them to main, runs focused validation, and produces a manual review checklist before merge. Use when the user shares a PR URL or asks to check a PR before merging.
• ai-sdk-development — Builds AI agents, generates text and chat responses, produces images, synthesizes audio, transcribes speech, generates vector embeddings, reranks documents, and manages files and vector stores using the Laravel AI SDK (laravel/ai). Supports structured output, streaming, tools, conversation memory, middleware, queueing, broadcasting, and provider failover. Use when building, editing, updating, debugging, or testing any AI functionality, including agents, LLMs, chatbots, text generation, image generation, audio, transcription, embeddings, RAG, similarity search, vector stores, prompting, structured output, or any AI provider (OpenAI, Anthropic, Gemini, Cohere, Groq, xAI, ElevenLabs, Jina, OpenRouter).
• medialibrary-development — Build and work with spatie/laravel-medialibrary features including associating files with Eloquent models, defining media collections and conversions, generating responsive images, and retrieving media URLs and paths.
• laravel-permission-development — Build and work with Spatie Laravel Permission features, including roles, permissions, middleware, policies, teams, and Blade directives.

Conventions

• You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, and naming.
• Use descriptive names for variables and methods. For example, isRegisteredForDiscounts, not discount().
• Check for existing components to reuse before writing a new one.
• Default to standard component sizing for buttons, inputs, selects, tabs, and datagrid/filter controls. Do not reach for sm or smaller variants unless the tighter density is clearly necessary; if it materially affects UI density, confirm with the user first.
• This is a greenfield application. Prefer the cleanest current design over preserving legacy patterns.
• There are no live instances that require backward compatibility. Do not keep compatibility layers, transitional APIs, or temporary shims unless the user explicitly asks for them.
• Remove dead code, unused branches, stale helpers, obsolete UI, and old integration paths as part of the change whenever they are no longer needed.
• PostgreSQL is the primary and only database target for application code. Treat PostgreSQL as first-class and do not spend effort preserving behavior for SQLite, MySQL, MariaDB, or SQL Server unless the user explicitly asks for it.
• Shared Inertia props must stay shell-safe and minimal. Do not add feature-level data, management metadata, or broad permission maps to shared payloads when page props can carry them instead.
• Shared module payloads are runtime descriptors only. Ordinary shared frontend module data should be limited to name, slug, and inertiaNamespace; keep paths, providers, seeders, route files, and other diagnostics on management or inspection pages only.
• Treat shared auth.abilities as route/page-scoped UI data, not a global dump of every permission in the app. Only ship the abilities the current page family actually consumes.

Verification Scripts

• Do not create verification scripts or tinker when tests cover that functionality and prove they work. Unit and feature tests are more important.

Application Structure & Architecture

• Stick to existing directory structure; don't create new base folders without approval.
• Do not change the application's dependencies without approval.

Scaffold-first CRUD workflow

• For new standard CRUD work, prefer the scaffold contract and commands before inventing local patterns.
• Use scaffold:inspect to understand an existing scaffold resource before editing it.
• Use scaffold:generate when creating a new standard app or module CRUD so classes, pages, tests, and registration targets follow the canonical shape.
• Use scaffold:doctor after scaffold changes to validate route names, page files, ability mappings, registration blocks, and convention drift.
• Use make:module-scaffold when creating a new module shell or a new module plus its first standard CRUD instead of hand-assembling module.json, providers, routes, abilities, navigation, and seeders.
• Use module:inspect after module runtime changes to validate provider resolution, page roots, route files, navigation/abilities paths, and database seeder metadata.
• Generated scaffolds now carry explicit registration targets and merge markers for routes, navigation, and module abilities. Preserve manual entries outside generated marker blocks and update generated sections through the scaffold workflow rather than ad hoc edits when practical.
• For legacy non-generated registrations, scaffold:doctor --strict-legacy-registrations can be used to audit whether routes and navigation still reference the expected controller, route, permission, and active-pattern hooks.
• When working on scaffold index pages, prefer the shared adapter flow from ScaffoldDefinition::toInertiaConfig() and resources/js/lib/scaffold-datagrid.ts instead of rebuilding tabs, filters, sorting, and per-page state by hand.
• If a scaffold-backed controller overrides index(), it must still return 'config' => $this->service()->getScaffoldDefinition()->toInertiaConfig() or the frontend will lose scaffold column widths, filters, tabs, and action metadata.
• If a scaffold-backed React index page defines custom DatagridColumn[], pass scaffoldColumns={config.columns} to <Datagrid> so column widths continue to come from the backend definition instead of drifting into page-local Tailwind width classes.
• Treat scaffold definition widths as the source of truth for table layout. Do not duplicate width decisions in page-level headerClassName / cellClassName unless the definition cannot express the requirement.
• Scaffold index/list rows must use explicit payload contracts. Prefer resource-level allowlists and list-specific serialization hooks over exposing all model attributes by default.
• Standard scaffold pages should use one backend-driven datagrid contract for actions and empty states. Custom pages may opt out, but when they do, they should also suppress redundant backend action or empty-state payloads.
• Empty-state create actions must be authorized on the backend before they are sent to the page payload.
• Use shared scaffold config/types where helpful, but keep straightforward frontend route('...') calls explicit and readable when route names are stable.
• Treat scaffold form metadata as optional. Prefer explicit form props and feature-local field configuration unless the form is intentionally generic or generator-driven.

Frontend Bundling

• This project uses pnpm, not npm, for frontend package management and scripts.
• Prefer pnpm dev for frontend development. Do not run build commands for routine frontend validation unless the user explicitly asks for a production build.
• If the user doesn't see a frontend change reflected in the UI, it could mean they need to run pnpm run build, pnpm run dev, or composer run dev. Ask them.
• This project does not use Inertia SSR. Do not add, restore, or rely on SSR / hydration-specific setup unless the user explicitly asks for it.

Documentation Files

• You must only create documentation files if explicitly requested by the user.

Replies

• Be concise in your explanations - focus on what's important rather than explaining obvious details.

=== boost rules ===

Laravel Boost

• Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.

Artisan Commands

• Run Artisan commands directly via the command line (e.g., php artisan route:list, php artisan tinker --execute "...").
• Use php artisan list to discover available commands and php artisan [command] --help to check parameters.

URLs

• Whenever you share a project URL with the user, you should use the get-absolute-url tool to ensure you're using the correct scheme, domain/IP, and port.

Debugging

• Use the database-query tool when you only need to read from the database.
• Use the database-schema tool to inspect table structure before writing migrations or models.
• To execute PHP code for debugging, run php artisan tinker --execute "your code here" directly.
• To read configuration values, read the config files directly or run php artisan config:show [key].
• To inspect routes, run php artisan route:list directly.
• To check environment variables, read the .env file directly.

Reading Browser Logs With the browser-logs Tool

• You can read browser logs, errors, and exceptions using the browser-logs tool from Boost.
• Only recent browser logs will be useful - ignore old logs.

Searching Documentation (Critically Important)

• Boost comes with a powerful search-docs tool you should use before trying other approaches when working with Laravel or Laravel ecosystem packages. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages.
• Search the documentation before making code changes to ensure we are taking the correct approach.
• Use multiple, broad, simple, topic-based queries at once. For example: ['rate limiting', 'routing rate limiting', 'routing']. The most relevant results will be returned first.
• Do not add package names to queries; package information is already shared. For example, use test resource table, not filament 4 test resource table.
• If search-docs returns No results found, do not assume the tool is broken. Treat that as a query or filter miss first, then retry with broader wording, multiple related queries, and fewer or no package filters before concluding the tool is unavailable.
• Treat actual tool failure as transport or execution failure, such as a timeout, connection error, malformed response, or repeated failure across broad queries. A valid No results found response means the tool is working.

Available Search Syntax

1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'.
2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit".
3. Quoted Phrases (Exact Position) - query="infinite scroll" - words must be adjacent and in that order.
4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit".
5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms.

=== php rules ===

PHP

• Always use curly braces for control structures, even for single-line bodies.

Constructors

• Use PHP 8 constructor property promotion in __construct().
  • public function __construct(public GitHub $github) { }
• Do not allow empty __construct() methods with zero parameters unless the constructor is private.

Type Declarations

• Always use explicit return type declarations for methods and functions.
• Use appropriate PHP type hints for method parameters.

protected function isAccessible(User $user, ?string $path = null): bool
{
    ...
}

Enums

• Typically, keys in an Enum should be TitleCase. For example: FavoritePerson, BestLake, Monthly.

Comments

• Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless the logic is exceptionally complex.

PHPDoc Blocks

• Add useful array shape type definitions when appropriate.

=== tests rules ===

Test Enforcement

• Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass.
• Run the minimum number of tests needed to ensure code quality and speed. Use php artisan test --compact with a specific filename or filter.
• For module tests, prefer the shared InteractsWithModuleManifest helpers such as withEnabledModules() and useModuleSandbox() instead of implicit manifest swapping or ad hoc test setup.

=== inertia-laravel/core rules ===

Inertia

• Inertia creates fully client-side rendered SPAs without modern SPA complexity, leveraging existing server-side patterns.
• Components live in resources/js/pages (unless specified in vite.config.js). Use Inertia::render() for server-side routing instead of Blade views.
• ALWAYS use search-docs tool for version-specific Inertia documentation and updated code examples.
• IMPORTANT: Activate inertia-react-development when working with Inertia client-side patterns.

Inertia v3

• Use all Inertia features from v1, v2, and v3. Check the documentation before making changes to ensure the correct approach.
• New v3 features: standalone HTTP requests (useHttp hook), optimistic updates with automatic rollback, layout props (useLayoutProps hook), instant visits, simplified SSR via @inertiajs/vite plugin, custom exception handling for error pages.
• Carried over from v2: deferred props, infinite scroll, merging props, polling, prefetching, once props, flash data.
• Use Inertia's <Head> for page titles and metadata. Prefer a small shared wrapper component for default descriptions and consistent metadata.
• Keep root-template head elements in resources/views/app.blade.php; page-level <Head> should override or extend, not duplicate them. Use head-key for duplicate-prone tags like description.
• Use Inertia <Link> for internal navigation. For non-GET visits, prefer button rendering over anchor links for accessibility.
• Prefer Inertia <Form> for straightforward server-driven forms with uncontrolled inputs; prefer useForm when controlled state, imperative submission, remembered history state, or client-side mutation is needed.
• With React <Form>, prefer name plus defaultValue / defaultChecked over controlled value state unless the UI truly needs control.
• Use useHttp for standalone JSON or external requests that should not trigger page navigation; prefer it over raw fetch() for app-owned endpoints when Inertia request ergonomics are useful.
• File uploads are converted to FormData automatically when File values are present. Use progress for upload UI, forceFormData only when needed, and prefer method-spoofed post uploads over direct put / patch multipart requests in Laravel.
• Use Ziggy's route() function to generate URLs for Link href, form actions, and router methods. Pass the URL string directly.
• Use disableWhileProcessing, resetOnSuccess, resetOnError, and setDefaultsOnSuccess intentionally to simplify form UX.
• Use keyed useForm() instances for drafts that should survive history navigation, and exclude sensitive fields with dontRemember().
• useHttp also supports remembered state, dontRemember(), progress, cancellation, withAllErrors(), built-in Precognition, and optimistic updates.
• Built-in Inertia Precognition support is available for forms and useForm; prefer it over legacy client packages when real-time Laravel validation is needed.
• Validation errors for Inertia page visits come from redirects and shared props, not 422 JSON handling. Form helper errors are already scoped; use errorBag mainly for manual multi-form page submissions.
• Prefer built-in Inertia optimistic updates for small reversible UI changes, and return only the minimal changed subset so rollback stays predictable.
• Prefer router.get/post/put/patch/delete/reload shortcut methods over raw router.visit() when they clearly express intent; router.reload() preserves scroll and state automatically.
• Use router.visit() options like replace, preserveState, preserveScroll, only, except, preserveErrors, component, and pageProps intentionally.
• Use useLayoutProps, setLayoutProps, setLayoutPropsFor, and resetLayoutProps only with persistent Inertia layouts, not simple wrapper components that remount every visit.
• This project does not use Inertia viewTransition; do not add it to links, visits, or global defaults.
• Use client-side router.push() / router.replace() only when no server request should run, and keep pushed routes renderable by the server on refresh.
• Use prop helpers like router.replaceProp(), router.appendToProp(), and router.prependToProp() for lightweight client-only page prop updates.
• Cancel stale visits with router.cancelAll() when needed; use onBefore, onCancelToken, onHttpException, and onNetworkError deliberately for manual visits.
• Instant visits are best for pages that can render with shared props only; use component only when the intermediate render is safe.
• Use replace, preserveState, preserveScroll, and only intentionally when they improve navigation UX.
• You may opt into the standards-compliant data-inertia head attribute with defaults.future.useDataInertiaHeadAttribute.
• When using deferred props, add an empty state with a pulsing or animated skeleton.
• Axios has been removed. Use the built-in XHR client with interceptors, or install Axios separately if needed.
• Inertia::lazy() / LazyProp has been removed. Use Inertia::optional() instead.
• Prop types (Inertia::optional(), Inertia::defer(), Inertia::merge()) work inside nested arrays with dot-notation paths.
• SSR works automatically in Vite dev mode with @inertiajs/vite - no separate Node.js server needed during development.
• Event renames: invalid is now httpException, exception is now networkError.
• router.cancel() replaced by router.cancelAll().
• The future configuration namespace has been removed - all v2 future options are now always enabled.

=== laravel/v13 rules ===

Laravel 13

• CRITICAL: ALWAYS use search-docs tool for version-specific Laravel documentation and updated code examples.
• Since Laravel 11, Laravel has a new streamlined file structure which this project uses.

Laravel 13 Structure

• In Laravel 13, middleware are no longer registered in app/Http/Kernel.php.
• Middleware are configured declaratively in bootstrap/app.php using Application::configure()->withMiddleware().
• bootstrap/app.php is the file to register middleware, exceptions, and routing files.
• bootstrap/providers.php contains application specific service providers.
• The app\Console\Kernel.php file no longer exists; use bootstrap/app.php or routes/console.php for console configuration.
• Console commands in app/Console/Commands/ are automatically available and do not require manual registration.

Database

• When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost.
• Laravel 13 allows limiting eagerly loaded records natively, without external packages: $query->latest()->limit(10);.

Models

• Casts can and likely should be set in a casts() method on a model rather than the $casts property. Follow existing conventions from other models.

=== ziggy/core rules ===

Ziggy (tightenco/ziggy)

Ziggy exposes Laravel named routes to TypeScript via the global route() function, powered by ZiggyRouteFilter which replaces the @routes Blade directive.

• IMPORTANT: Activate ziggy-development skill whenever referencing backend routes in frontend components.
• Basic usage: route('posts.show', { post: 1 }) → "/posts/1".
• The route() function returns a URL string. Pass it directly to Link href, router.visit(), form.submit(), etc.
• Query parameters: route('posts.index', { _query: { page: 2, sort: 'name' } }).
• Current route check: route().current('posts.*') for active link detection.
• Route definitions are rendered server-side by ZiggyRouteFilter in resources/views/app.blade.php on full page loads.
• Routes are filtered per user role: super users get all routes, other users get only the groups their permissions allow. Groups are defined in config/ziggy.php.
• When the admin slug or user role changes, Inertia asset versioning forces a full page reload so the filtered route set is refreshed.
• When a route may be filtered out for the current user, check route().has('name') before rendering links or calling route('name').
• Cache is stored per role ID; call ZiggyRouteFilter::clearCache() when permissions or route groups change.

=== laravel/core rules ===

Do Things the Laravel Way

• Use php artisan make: commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using php artisan list and check their parameters with php artisan [command] --help.
• If you're creating a generic PHP class, use php artisan make:class.
• Pass --no-interaction to all Artisan commands to ensure they work without user input. You should also pass the correct --options to ensure correct behavior.

Database

• Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
• Use Eloquent models and relationships before suggesting raw database queries.
• Avoid DB::; prefer Model::query(). Generate code that leverages Laravel's ORM capabilities rather than bypassing them.
• Generate code that prevents N+1 query problems by using eager loading.
• Use Laravel's query builder for very complex database operations.

Model Creation

• When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using php artisan make:model --help to check the available options.

APIs & Eloquent Resources

• For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.

Controllers & Validation

• Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
• Check sibling Form Requests to see if the application uses array or string based validation rules.

Authentication & Authorization

• Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).

URL Generation

• When generating links to other pages, prefer named routes and the route() function.

Queues

• Use queued jobs for time-consuming operations with the ShouldQueue interface.

Configuration

• Use environment variables only in configuration files - never use the env() function directly outside of config files. Always use config('app.name'), not env('APP_NAME').

Testing

• When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model.
• Faker: Use methods such as $this->faker->word() or fake()->randomDigit(). Follow existing conventions whether to use $this->faker or fake().
• When creating tests, make use of php artisan make:test [options] {name} to create a feature test, and pass --unit to create a unit test. Most tests should be feature tests.

Vite Error

• If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run pnpm run build or ask the user to run pnpm run dev or composer run dev.

=== pint/core rules ===

Laravel Pint Code Formatter

• If you have modified any PHP files, you must run vendor/bin/pint --dirty --format agent before finalizing changes to ensure your code matches the project's expected style.
• Do not run vendor/bin/pint --test --format agent, simply run vendor/bin/pint --format agent to fix any formatting issues.

=== phpunit/core rules ===

PHPUnit

• This application uses PHPUnit for testing. All tests must be written as PHPUnit classes. Use php artisan make:test --phpunit {name} to create a new test.
• If you see a test using "Pest", convert it to PHPUnit.
• Every time a test has been updated, run that singular test.
• When the tests relating to your feature are passing, ask the user if they would like to also run the entire test suite to make sure everything is still passing.
• Tests should cover all happy paths, failure paths, and edge cases.
• You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files; these are core to the application.

Running Tests

• Run the minimal number of tests, using an appropriate filter, before finalizing.
• To run all tests: php artisan test --compact.
• To run all tests in a file: php artisan test --compact tests/Feature/ExampleTest.php.
• To filter on a particular test name: php artisan test --compact --filter=testName (recommended after making a change to a related file).

=== inertia-react/core rules ===

Inertia + React

• IMPORTANT: Activate inertia-react-development when working with Inertia React client-side patterns.

=== tailwindcss/core rules ===

Tailwind CSS

• Always use existing Tailwind conventions; check project patterns before adding new ones.
• IMPORTANT: Always use search-docs tool for version-specific Tailwind CSS documentation and updated code examples. Never rely on training data.
• IMPORTANT: Activate tailwindcss-development every time you're working with a Tailwind CSS or styling-related task.

=== laravel/ai rules ===

Laravel AI SDK

• This application uses the Laravel AI SDK (laravel/ai) for all AI functionality.
• Activate the ai-sdk-development skill when building, editing, updating, debugging, or testing AI agents, text generation, chat, streaming, structured output, tools, image generation, audio, transcription, embeddings, reranking, vector stores, files, conversation memory, or any AI provider integration (OpenAI, Anthropic, Gemini, Cohere, Groq, xAI, ElevenLabs, Jina, OpenRouter).

=== spatie/laravel-medialibrary rules ===

Media Library

• spatie/laravel-medialibrary associates files with Eloquent models, with support for collections, conversions, and responsive images.
• Always activate the medialibrary-development skill when working with media uploads, conversions, collections, responsive images, or any code that uses the HasMedia interface or InteractsWithMedia trait.