Elixir Phoenix Docker Setup .cursorrules prompt file

Author: Zane Riley

What you can build

WebSocket Monitoring Dashboard: Build a real-time dashboard for monitoring and visualizing active WebSocket connections and message traffics using Phoenix LiveView and Phoenix LiveDashboard.Multi-tenant SaaS Platform: Develop a multi-tenant SaaS application tailored for small businesses to manage customer interactions and project workflows, leveraging Ecto's capabilities for handling tenant data separation.AI-Powered Code Linter: Create a robust code linter for Elixir projects, integrating Credo and Sobelow analyses with AI-generated optimization suggestions.CI/CD Deployment Pipeline: Construct a CI/CD pipeline tool utilizing Docker, Release Please, and Phoenix with features for automated testing and deployment to k8s or other hosting environments.Localized Mailing List Manager: Implement an application for managing and sending localized emails using Swoosh and Gettext, with features for handling bulk distribution and tracking engagement.File System Event Tracker: Develop a service for monitoring file system changes and events, with real-time synchronization and notification capabilities using the File System Watcher.Cluster Management Tool: Create a DNS-based cluster management solution facilitating dynamic service discovery and load balancing in Elixir applications.Automated Test Coverage Analysis: Design a tool using ExCoveralls to generate comprehensive test coverage reports across multiple Elixir projects within a development ecosystem.JSON and API Explorer: Build a tool for testing and exploring JSON APIs and web services with comprehensive features powered by Jason and Plug.Elixir Learning Platform: Establish an online platform featuring interactive tutorials and exercises for mastering Elixir, Phoenix, and related technologies like Phoenix LiveView.Q1: How can Tailwind CSS be effectively integrated into an existing Phoenix application?Q2: What strategies can improve performance in Elixir applications when implemented with Docker?Q3: How should I approach securing a Phoenix application using Sobelow's analysis tool?

Benefits

Synopsis

Developers utilizing Elixir and Phoenix can leverage this prompt to improve their commit documentation and ensure comprehensive code review by incorporating robust conventional commit strategies and thought-provoking follow-up questions.

Overview of .cursorrules prompt

The .cursorrules file defines guidelines and rules for an Elixir expert to follow when participating in a software development process using specific technologies such as Elixir, Phoenix, Docker, PostgreSQL, and more. It includes instructions for approaching code writing by considering all requirements before implementation. Additionally, it provides a structured format for conventional commit messages, detailing specific types, optional scopes, descriptions, body content, and footers to ensure clarity and consistency in code documentation and version control. The file also advises providing concise responses to inquiries prefixed with "VV" and suggests thought-provoking follow-up questions after providing solutions.

.cursorrules Content

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 throught-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`)