Elixir Phoenix Docker Setup Cursorrules Prompt Fil

Fertige Cursor-Regel für Docker-Setups von Elixir/Phoenix-Projekten.

Original-Beschreibung der Autoren: Cursor rules for Elixir development with Phoenix and Docker integration.

Die Regel

---
description: "Cursor rules for Elixir development with Phoenix and Docker integration."
globs: **/*
alwaysApply: false
---
Act as an expert senior Elixir engineer.

Stack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls

- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.

- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.

- If my response starts with "VV", give the most succinct, concise, shortest answer possible.

## Commit Message Guidelines:

- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:
  [optional scope]: [optional body][optional footer(s)]

Where:

- **type:** One of the following:
  - `build`: Changes that affect the build system or external dependencies (e.g., Maven, npm)
  - `chore`: Other changes that don't modify src or test files
  - `ci`: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)
  - `docs`: Documentation only changes
  - `feat`: A new feature
  - `fix`: A bug fix
  - `perf`: A code change that improves performance
  - `refactor`: A code change that neither fixes a bug nor adds a feature
  - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  - `test`: Adding missing tests or correcting existing tests

- **scope (optional):** A noun describing a section of the codebase (e.g., `fluxcd`, `deployment`).

- **description:** A brief summary of the change in present tense.

- **body (optional):** A more detailed explanation of the change.

- **footer (optional):** One or more footers in the following format:
  - `BREAKING CHANGE: ` (for breaking changes)
  - `<issue_tracker_id>: ` (e.g., `Jira-123: Fixed bug in authentication`)

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Cursor-Regel liefert eine fertige Konfiguration für Elixir/Phoenix-Projekte, die in Docker laufen sollen. Sie legt fest, wie der KI-Editor beim Aufsetzen von Dockerfile, docker-compose und Umgebungsvariablen für eine Phoenix-App vorgehen soll — inklusive typischer Elixir-Konventionen (Mix, Ecto, Ports). Wer neu in Elixir/Phoenix ist oder ein bestehendes Projekt containerisieren will, bekommt damit einen konsistenten Startpunkt, statt bei jedem Prompt neu erklären zu müssen, wie Dockerfile und Compose-Setup aussehen sollen. Der Nutzen hängt stark davon ab, wie gut die Regel zur eigenen Projektstruktur passt — bei stark abweichenden Setups (z. B. Umbrella-Apps, Mix Releases) sollte man sie vor dem Einsatz prüfen und anpassen.

Praxis-Tipp

Regel-Datei nach .cursor/rules kopieren und mit einem Prompt wie „Erstelle Dockerfile und docker-compose.yml für dieses Phoenix-Projekt“ testen, dann gegen die eigene Mix-Konfiguration abgleichen.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …