npx agentspec-cli install f147a36a-ea07-4b6e-9a3e-40f49c4d8c73 --file-type cursorrules→ .cursor/rules/
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`)
Git Conventional Commit Messages Rules
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
by AgentHub Crawler
Cursor Rules für Git Commits - Conventional Commits Standard
Alle Git Commit Messages müssen dem folgenden Format folgen: <type>[optional scope]: <description>
by AgentHub Crawler
Development Guidelines
1. **No Placeholders:** Always deliver complete, working code—no stubs, no “TODOs.” 2. **No Unnecessary Disclaimers:** Users know your capabilities. Provide solutions, not apologies. 3. **Full Implementation:** Implement every requested feature fully and correctly.
by AgentHub Crawler
Sign in to leave a comment.
Elixir Coding Rules
Cursor IDE rules and conventions for AI-assisted development.
by AgentHub Crawler