Use when adding, changing, or debugging Alpine.js behavior in Django-rendered templates, especially when Alpine.js coexists with HTMX partial updates.
SkillScore100Maintained
Automatic
◆Frontend / UI pack
Last verified 8/15/2026
What it changes
Passed 22 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill100%
Checks it passed that the model alone missed
The accordion toggle button binds :aria-expanded to the accordion toggle boolean state.
The component state initializes inline via x-init by parsing JSON from the script tag content.
The initial value is passed via a standard HTML data-* attribute and read in x-init using $el.dataset.
and 1 more in the full report
4 fixed18 passed either way0 still failing0 broke
Pass-rate lift
+18 pp
Tokens
+63%
Agent turns
0%
Response time
-23%
Model gemini-3.6-flashMeasured 8/15/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
I have a simple single-value string 'initial_query' from my Django view context that I need to pass into a small inline Alpine component controlling a text input field. How should I pass this string without using raw template tags directly inside complex JS logic?
What was checked, without and with the skill
Checked
Without skill
With skill
The initial value is passed via a standard HTML data-* attribute and read in x-init using $el.dataset.
Missed
Passed
case-08 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md191 lines2 files
Alpine.js with Django
Use this skill for local browser state in Django-rendered templates: dropdowns,
modals, tabs, disclosures, inline filters, disabled/loading states, small
preview interactions, and client-only toggles. Use Django views/forms/models as
the source of truth for durable state. Use HTMX when the server needs to return
fresh HTML.
Setup checks
Identify how the project loads Alpine. Prefer the existing static asset or
bundling pipeline as the source of truth.
Find the base template, layout, or bundled entrypoint that loads HTMX,
Alpine, and app JavaScript. Preserve the current ordering unless changing
initialization deliberately.
Determine whether the loaded Alpine file is self-starting or module-based. Do
not call Alpine.start() when the project already loads a self-starting
Alpine build. If using a module build, register components and start Alpine
from the owning entrypoint.
Simple Alpine behavior should usually live inline in the Django template with
x-data.
If a reusable component or store is worth extracting, register it before
Alpine starts. Check the existing script order before relying on
document.addEventListener("alpine:init", ...) from an app-wide script.
When reusable Alpine registration is needed, add or reuse a script or
entrypoint that runs before Alpine starts. Register components and stores
inside document.addEventListener("alpine:init", ...), include the file
through the project's normal asset path, and avoid double-starting Alpine.
Ownership rules
Django owns persistence, authorization, validation, redirects, and rendered
HTML.
HTMX owns server round trips and DOM swaps.
Alpine owns ephemeral state already present in the browser.
Plain JavaScript modules or bundled entrypoints own shared DOM behavior that
is not naturally scoped to one Alpine component.
Do not duplicate the same behavior in Alpine and a plain JS module.