awcodes/sparky
Sparky is a lightweight Laravel package by awcodes for rendering compact sparkline charts, making it simple to add quick visual trend indicators to your app. Easy to install and integrate with existing Laravel projects.
Verify the artifact before anything else. The registry entry and the bundled description.md describe a dependency-free inline-SVG sparkline plugin; the repository, the v0.1.0 release, and the agents/skills tree describe a Filament starter kit. Those are different products. Open the pinned commit and look for composer.json, a Filament panel provider, and agents/skills/. If you find a plugin with a SparklineColumn class, the day-to-day usage is trivial (register the plugin, drop the column in a table, add the widget) and you can stop reading the rest of this. If you find a panel provider and skills, it is a starter kit and the workflow below applies.
Assuming the starter kit, the only supported entry point is a fresh project:
composer create-project awcodes/sparky my-admin
cd my-admin
cp .env.example .env
php artisan key:generate
php artisan migrate --seed
npm install && npm run build
php artisan serve
Before writing feature code, do four things in order:
composer.json and package.json tell you whether this is Filament 4 / Livewire 4 / Tailwind 4 / Pest 4. Every bundled skill assumes that generation; if the constraints disagree, the skills are stale and so is any agent guidance built on them.agents/skills/fluxui-development, livewire-development, pest-testing, tailwindcss-development are the actual differentiator. Read them before your coding agent does.php artisan test (plus the browser suite if one ships). A red suite on day one is a stop signal, not a bug to fix.Where to look first, in priority order: agents/skills/, then app/Providers/Filament/*PanelProvider.php (path, middleware, guard, colors, discovered resources), then tests/ (the architecture suite encodes what the author considers non-negotiable), then whatever Boost guidelines ship (AGENTS.md, CLAUDE.md, boost.json) — check whether they are generic Laravel advice or Sparky-specific.
First real use case: pick one genuine admin screen and build it end to end — model, migration, factory, Filament resource via Blueprint, table filters, a form with at least one relationship, a Pest feature test. Time it. That single vertical slice answers the only question that matters: hours to first feature versus your current baseline.
Blueprint-first resource generation. The kit's premise is that you do not hand-write resources from scratch. Let Blueprint generate from the schema, then tune the generated form and table rather than replacing them. Keep generated code recognizable so regeneration stays cheap; put customizations where Blueprint will not clobber them (custom actions, separate schema classes, table configurators).
Point your agent at the skills explicitly. In CLAUDE.md or your agent's system prompt, make the skill files the reference standard rather than background reading:
Before writing Flux, Livewire, Pest, or Tailwind code, read
agents/skills/<area>/SKILL.md and follow it. Use `search-docs`
for component-level detail. Do not introduce components or
patterns outside those documented there.
Then measure it: review-churn rate on agent-authored PRs. If reviewers keep rewriting agent output to match house style, the skills are not binding and you have lost the differentiator.
Single-file Livewire components as the default. Livewire 4 makes SFC the default (make:livewire create-post puts PHP and Blade in one file). Use --mfc when you need a separate JS/test file and --class only when porting v3 code. Do not mix formats within one feature; livewire:convert exists when you need to switch.
Write down the Filament vs. Flux boundary on day one. Both are installed and they conflict at the convention level. A workable rule:
<flux:*> inside a resource.resources/views/components.Use Livewire 4 idioms rather than full-component re-renders. Islands (@island(name: 'stats')) for isolated dashboard widget updates, wire:click.async / #[Async] for slow actions that should not block, defer and lazy.bundle for expensive panels. These are the reason to be on v4 and they are documented in the bundled skill.
Pest architecture tests as guardrails, not decoration. A rule like "no Flux components inside app/Filament" written as a test fires on agent PRs too. Keep the shipped ones and extend them.
Selective extraction for existing apps. Do not composer require this into a running project; it is not designed for that and there is no upgrade channel. Scaffold into a throwaway sandbox, diff against a laravel new baseline, and copy only deltas you can justify in one written line each. The dev-only layer — Pest config, Boost guidelines, Tailwind v4 CSS-first config, agents/skills/ — is the cheapest and most transferable cut.
composer create-project awcodes/sparky /tmp/sparky-sandbox
laravel new /tmp/baseline
diff -rq /tmp/sparky-sandbox /tmp/baseline
Fork and pin into your org template repo. A copied tree with no upstream diff means every Filament and Livewire major becomes a manual coordinated migration — budget for that rather than assuming a merge path.
The metadata does not match the artifact. The registry and description.md say sparkline library; the repo and skills say starter kit. At 13 stars and zero dependents there is no ecosystem signal to triangulate. Verify against the pinned commit and record the discrepancy in your adoption notes — it will confuse the next engineer and it will confuse your agent if you feed it the registry description.
There is one release (v0.1.0, 2026-01-28), one maintainer, no upgrade policy. Treat upstream as inspiration, not a dependency feed. Vendor at a pinned commit and own the migration treadmill yourself.
Opinionation is the product, and it becomes a liability around month six. Track deletion volume during evaluation — the percentage of the kit you keep versus delete is the best single proxy for fit. Deleting 40% means the kit is fighting you and you should have installed Filament directly.
Greenfield only. Retrofitting the conventions onto a mid-flight project is the expensive part to change late. The kit assumes you start empty.
Free-edition Flux is a hard boundary. The skill scopes to the free component list (avatar, badge, brand, breadcrumbs, button, callout, checkbox, dropdown, field, heading, icon, input, modal, navbar, otp-input, profile, radio, select, separator, skeleton, switch, text, textarea, tooltip). Grep for flux: across the tree and cross-check before committing; a Pro component in shipped views means broken templates and a violated guideline simultaneously.
Livewire 4 behavior changes bite silently. wire:model now ignores child events by default (use wire:model.deep for v3 behavior), wire:scroll is wire:navigate:scroll, wire:transition uses the View Transitions API with modifiers removed, and $wire.$js('name', fn) became $wire.$js.name = fn. The skill flags these but the app itself may not be migrated. If something that "should" work does not fire, check the v4 change list first.
Debug by diffing against a baseline. When a generated resource behaves oddly, diff it against laravel new + php artisan filament:install + a hand-written resource. The difference is either a kit convention worth keeping or an opinion you did not agree to — you learn something concrete in minutes instead of reading source.
SaaS scaffolding is out of scope. No billing, teams, invitations, or subscription gating. Budget those separately rather than assuming they are in the box.
Set a hard evaluation gate. One engineer, one week, one real feature. Write success criteria before starting: hours to first feature vs. baseline, percentage of kit kept vs. deleted, defect and review-churn rate on agent-authored PRs. Downside is capped at the week; the output informs build-vs-adopt either way.
How can I help you explore Laravel packages today?