Alpine.js Tailwind HTML Server-Driven Cursor Rules Template
Copyable Cursor Rules Template for Alpine.js + Tailwind + HTML server-driven apps.
Target User
Frontend engineers and full-stack developers building server-rendered UIs with Alpine.js and Tailwind
Use Cases
- Generate server-rendered components with AI guidance
- Standardize front-end behavior with cursor rules
- Safely onboard AI-assisted UI generation
Markdown Template
Alpine.js Tailwind HTML Server-Driven Cursor Rules Template
Overview
This Cursor rules configuration is designed for a server-driven UI stack using Alpine.js for interactivity, Tailwind CSS for styling, and HTML templates served from a Node/Express-like server. It provides a concrete, paste-ready .cursorrules block to guide Cursor AI during UI prototyping and component generation.
Direct answer: Paste the code block into your project root as .cursorrules to enable reproducible AI-assisted UI patterns for an Alpine.js + Tailwind + HTML server-rendered stack.
When to Use These Cursor Rules
- When building server-rendered HTML pages with dynamic components via Alpine.js
- When coupling Tailwind CSS utilities with AI-guided UI generation
- When you need a deterministic, testable Cursor AI workflow for UI assembly
- When you require safe, architecture-consistent prompts for front-end templates
Copyable .cursorrules Configuration
Framework: Alpine.js + Tailwind + HTML (server-driven rendering)
Context: You are an AI assistant integrated into a server-rendered UI. Use Alpine.js for interactivity, Tailwind for styling, and render pages through server templates. Do not access server internals from client.
CodeStyle: HTML templates with Tailwind classes; avoid inline scripts; Alpine.js directives only; prefer semantic HTML.
Architecture: Server-rendered templates under /views; static assets under /public; routes defined in server.js; data fetched server-side and injected into templates.
AuthenticationSecurity: Do not expose secrets in client. Validate inputs on server; implement CSRF protections for forms; escape user content to prevent XSS.
DatabaseORM: Not used in raw templates; if data is required, fetch server-side and pass as template data; never query database from client.
TestingLinting: Use Playwright for E2E tests; HTML lint via Prettier with plugin; Tailwind class linting via stylelint or tailwindcss-intellisense during dev.
ProhibitedActionsAntiPatterns: Do not bypass server-side rendering; Do not perform client-side network calls to server endpoints that require authentication without restrictions; Do not embed server credentials; Do not use eval or innerHTML with untrusted content.
Recommended Project Structure
project-root/
├─ server/
│ ├─ server.js
│ └─ routes/
│ └─ home.js
├─ views/
│ └─ layout.html
├─ public/
│ ├─ index.html
│ ├─ assets/
│ │ ├─ css/
│ │ │ └─ tailwind.css
│ │ └─ js/
│ │ └─ alpine.min.js
│ └─ images/
└─ cursorrules/
└─ alpinejs-tailwind.html
Core Engineering Principles
- Clear separation of concerns between server-rendered templates, client interactivity (Alpine.js), and styling (Tailwind CSS).
- Security by design: validate on server, escape inputs, and avoid exposing secrets to the client.
- Safe AI-assisted development with explicit Do Not rules and anti-patterns.
- Reproducible builds and deterministic file paths for templates and assets.
- Observability: log template rendering and AI decisions in a non-sensitive way; include simple test hooks.
- Accessibility: semantic HTML, proper ARIA where needed, and keyboard navigability.
Code Construction Rules
- Only use Alpine.js for interactivity; do not rely on external DOM manipulation libraries.
- Tailwind CSS utilities should drive all styling; avoid inline CSS blocks.
- All server data injected into templates must be sanitized and escaped server-side before rendering to HTML.
- Keep a strict directory separation: server routes under /server, templates under /views, and assets under /public.
- Do not embed secrets in client-side code; fetch secrets from server endpoints with proper authentication.
- AI-generated HTML must not include dangerous inline scripts or eval.
Security and Production Rules
- Enforce CSRF protection for any forms and state-changing operations on the server.
- Escape all dynamic content and validate user input on the server prior to rendering templates.
- Apply a strict Content Security Policy (CSP) and modern security headers in the server response.
- Use environment variables for secrets; rotate keys and audit dependencies regularly.
- Keep Tailwind and Alpine.js dependencies updated and pin versions for reproducible builds.
Testing Checklist
- Unit tests for Alpine.js components using a lightweight test runner that can simulate DOM interactions.
- Integration tests for server-rendered routes verifying template placeholders render correctly.
- End-to-end tests (Playwright) that cover authentication flows (if any) and UI component interactions.
- Linting: HTML and Tailwind assets linted; ensure CSS tree-shaking and purge paths configured.
- CI checks for security and dependency updates.
Common Mistakes to Avoid
- Mixing server and client logic; server data inlined without sanitation.
- Overusing inline scripts; bypassing Alpine.js patterns.
- Neglecting accessibility for dynamically revealed content.
- Ignoring CSP and missing security headers.
- Failing to pin dependency versions or to run linting in CI.
FAQ
What is the purpose of this Cursor Rules Template?
This template provides a concrete, pasteable .cursorrules block and a stack-specific project structure for Alpine.js + Tailwind + HTML server-driven UIs, helping ensure safe AI-assisted development and consistent architecture.
How do I paste this into a .cursorrules file?
Copy the code block under Copyable .cursorrules Configuration into the root of your project as .cursorrules and adjust any framework-specific paths or endpoints to your app.
What directories should I focus on in this stack?
Focus on /server for routes, /views for templates, and /public for assets. The /cursorrules block should reference these conventions for consistency.
How should I test locally?
Run server, start Tailwind build, and execute Playwright or Cypress tests for UI flows and component interactions; lint HTML and CSS as part of CI.
Can I adapt this to a different server framework?
Yes, the rules are stack-specific but adaptable. Replace server.js and route handlers with equivalents in your framework, keeping the template structure and AI instruction patterns intact.Overview
This Cursor rules configuration is designed for a server-driven UI stack using Alpine.js for interactivity, Tailwind CSS for styling, and HTML templates served from a Node/Express-like server. It provides a concrete, paste-ready .cursorrules block to guide Cursor AI during UI prototyping and component generation.
Direct answer: Paste the code block into your project root as .cursorrules to enable reproducible AI-assisted UI patterns for an Alpine.js + Tailwind + HTML server-rendered stack.
When to Use These Cursor Rules
- When building server-rendered HTML pages with dynamic components via Alpine.js
- When coupling Tailwind CSS utilities with AI-guided UI generation
- When you need a deterministic, testable Cursor AI workflow for UI assembly
- When you require safe, architecture-consistent prompts for front-end templates
Copyable .cursorrules Configuration
Framework: Alpine.js + Tailwind + HTML (server-driven rendering)
Context: You are an AI assistant integrated into a server-rendered UI. Use Alpine.js for interactivity, Tailwind for styling, and render pages through server templates. Do not access server internals from client.
CodeStyle: HTML templates with Tailwind classes; avoid inline scripts; Alpine.js directives only; prefer semantic HTML.
Architecture: Server-rendered templates under /views; static assets under /public; routes defined in server.js; data fetched server-side and injected into templates.
AuthenticationSecurity: Do not expose secrets in client. Validate inputs on server; implement CSRF protections for forms; escape user content to prevent XSS.
DatabaseORM: Not used in raw templates; if data is required, fetch server-side and pass as template data; never query database from client.
TestingLinting: Use Playwright for E2E tests; HTML lint via Prettier with plugin; Tailwind class linting via stylelint or tailwindcss-intellisense during dev.
ProhibitedActionsAntiPatterns: Do not bypass server-side rendering; Do not perform client-side network calls to server endpoints that require authentication without restrictions; Do not embed server credentials; Do not use eval or innerHTML with untrusted content.
Recommended Project Structure
project-root/
├─ server/
│ ├─ server.js
│ └─ routes/
│ └─ home.js
├─ views/
│ └─ layout.html
├─ public/
│ ├─ index.html
│ ├─ assets/
│ │ ├─ css/
│ │ │ └─ tailwind.css
│ │ └─ js/
│ │ └─ alpine.min.js
│ └─ images/
└─ cursorrules/
└─ alpinejs-tailwind.html
Core Engineering Principles
- Clear separation of concerns between server-rendered templates, client interactivity (Alpine.js), and styling (Tailwind CSS).
- Security by design: validate on server, escape inputs, and avoid exposing secrets to the client.
- Safe AI-assisted development with explicit Do Not rules and anti-patterns.
- Reproducible builds and deterministic file paths for templates and assets.
- Observability: log template rendering and AI decisions in a non-sensitive way; include simple test hooks.
- Accessibility: semantic HTML, proper ARIA where needed, and keyboard navigability.
Code Construction Rules
- Only use Alpine.js for interactivity; do not rely on external DOM manipulation libraries.
- Tailwind CSS utilities should drive all styling; avoid inline CSS blocks.
- All server data injected into templates must be sanitized and escaped server-side before rendering to HTML.
- Keep a strict directory separation: server routes under /server, templates under /views, and assets under /public.
- Do not embed secrets in client-side code; fetch secrets from server endpoints with proper authentication.
- AI-generated HTML must not include dangerous inline scripts or eval.
Security and Production Rules
- Enforce CSRF protection for any forms and state-changing operations on the server.
- Escape all dynamic content and validate user input on the server prior to rendering templates.
- Apply a strict Content Security Policy (CSP) and modern security headers in the server response.
- Use environment variables for secrets; rotate keys and audit dependencies regularly.
- Keep Tailwind and Alpine.js dependencies updated and pin versions for reproducible builds.
Testing Checklist
- Unit tests for Alpine.js components using a lightweight test runner that can simulate DOM interactions.
- Integration tests for server-rendered routes verifying template placeholders render correctly.
- End-to-end tests (Playwright) that cover authentication flows (if any) and UI component interactions.
- Linting: HTML and Tailwind assets linted; ensure CSS tree-shaking and purge paths configured.
- CI checks for security and dependency updates.
Common Mistakes to Avoid
- Mixing server and client logic; server data inlined without sanitation.
- Overusing inline scripts; bypassing Alpine.js patterns.
- Neglecting accessibility for dynamically revealed content.
- Ignoring CSP and missing security headers.
- Failing to pin dependency versions or to run linting in CI.
FAQ
What is the purpose of this Cursor Rules Template?
This template provides a concrete, pasteable .cursorrules block and a stack-specific project structure for Alpine.js + Tailwind + HTML server-driven UIs, helping ensure safe AI-assisted development and consistent architecture.
How do I paste this into a .cursorrules file?
Copy the code block under Copyable .cursorrules Configuration into the root of your project as .cursorrules and adjust any framework-specific paths or endpoints to your app.
What directories should I focus on in this stack?
Focus on /server for routes, /views for templates, and /public for assets. The /cursorrules block should reference these conventions for consistency.
How should I test locally?
Run server, start Tailwind build, and execute Playwright or Cypress tests for UI flows and component interactions; lint HTML and CSS as part of CI.
Can I adapt this to a different server framework?
Yes, the rules are stack-specific but adaptable. Replace server.js and route handlers with equivalents in your framework, keeping the template structure and AI instruction patterns intact.