Cursor Rules TemplatesCursor Rules Template

Alpine.js Tailwind HTML Server-Driven Cursor Rules Template

Copyable Cursor Rules Template for Alpine.js + Tailwind + HTML server-driven apps.

.cursorrules templatealpine.jstailwind csshtmlserver-drivencursor ai rulescursor-rules-templateui componentsfrontendweb-stackcursor-rules-templates

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.