elixir-phoenix-docker-setup-cursorrules-prompt-fil: Cursor rule
Configures Cursor for Elixir and Phoenix development inside Docker. Enforces senior engineering practices, Conventional Commits, and quick replies via the VV prefix.
.cursor/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdcWhat elixir-phoenix-docker-setup-cursorrules-prompt-fil does
This rule primes Cursor to act as a senior Elixir engineer. It embeds a tech stack covering Phoenix LiveView, PostgreSQL, Ecto, Docker, Credo, and Sobelow. Before generating code, the assistant must analyze edge cases and system requirements.
Every full response ends with three bold follow-up questions labeled **Q1**, **Q2**, and **Q3**. When you need a quick answer without explanations, prefix your prompt with VV. The model will return only the bare minimum.
Commit suggestions adhere strictly to Conventional Commits with scopes and types like feat or fix. Because alwaysApply is set to false, Cursor does not inject these instructions into every single prompt automatically.
What it helps with
- Draft Phoenix contexts and Ecto schemas with security checks
- Generate structured Conventional Commit messages
- Get instant single-line Elixir answers using the
VVprefix - Explore architecture trade-offs using generated follow-up prompts
Example prompts for the agent
- VV How do I run Ecto migrations inside the Docker container?
- Create a Phoenix LiveView dashboard component with ExUnit tests.
- Suggest a commit message for adding Credo and Sobelow CI checks.
How to install elixir-phoenix-docker-setup-cursorrules-prompt-fil
Manually: put the files in place
.cursor/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/elixir-phoenix-docker-setup-cursorrules-prompt-fil.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdManually: put the files in place
.clinerules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about elixir-phoenix-docker-setup-cursorrules-prompt-fil
How to install elixir-phoenix-docker-setup-cursorrules-prompt-fil in Cursor?
Save the rule content into .cursor/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc in your project root.
What does this rule do?
It configures Cursor as a senior Elixir engineer across Phoenix, Ecto, and Docker. It mandates planning before coding and standardizes git commit formats.
How does the VV shortcut work?
Starting any prompt with VV instructs Cursor to skip background reasoning and provide the shortest possible reply.
Source text
elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc · CC0-1.0
--- 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`)
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules