Skip to content

chore(cursor-rules): simplify and reorganize cursor rules for CE #41691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
sondermanish merged 2 commits into from
Apr 6, 2026
Merged

chore(cursor-rules): simplify and reorganize cursor rules for CE #41691

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
33b8c40
chore(cursor-rules): simplify and reorganize cursor rules for CE
sondermanish Apr 3, 2026
e6c3b70
added coderabbit suggestion
sondermanish Apr 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions .cursor/rules/agent-behavior.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
description: Agent workflow orchestration, task management, and core principles for all interactions
globs:
alwaysApply: true
---

# Agent Behavior

## Workflow Orchestration
### 1. Plan Node Default
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
- If something goes sideways, STOP and re-plan immediately - don't keep pushing
- Use plan mode for verification steps, not just building
- Use subagents to build in plan mode when tasks are independent
- Write detailed specs upfront to reduce ambiguity
### 2. Subagent Strategy
- Use subagents liberally to keep main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw more compute at it via subagents
- One tack per subagent for focused execution
### 3. Self-Improvement Loop
- After ANY correction from the user: update `.cursor/lessons.md` with the pattern
- Add the learning in `.claude/lessons.md` incrementally
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until mistake rate drops
- Review lessons at session start for relevant project
### 4. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness
### 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Skip this for simple, obvious fixes - don't over-engineer
- Challenge your own work before presenting it
### 6. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests - then resolve them
- Zero context switching required from the user
- Go fix failing CI tests without being told how
## Task Management
1. **Plan First**: Write plan to `.cursor/todo.md` with checkable items
2. **Verify Plan**: Check in before starting implementation
3. **Track Progress**: Mark items complete as you go
4. **Explain Changes**: High-level summary at each step
5. **Document Results**: Add review section to `.cursor/todo.md`
6. **Capture Lessons**: Update `.cursor/lessons.md` after corrections
## Core Principles
- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
- **No Trigger Happy**: Don't start write actions and long plans without confirming intent from user explicitly
- **Minimat Impact**: Changes should only touch what's necessary. Avoid introducing bugs.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix typo in core principle label.

Minimat Impact should be Minimal Impact to avoid ambiguity in a global rule file.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/agent-behavior.mdc at line 53, Update the core principle label
"Minimat Impact" in .cursor/rules/agent-behavior.mdc to the correct spelling
"Minimal Impact" so the global rule reads "**Minimal Impact**: Changes should
only touch what's necessary. Avoid introducing bugs."—locate the label string
and replace it exactly to preserve surrounding markdown formatting.

36 changes: 36 additions & 0 deletions .cursor/rules/backend.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
description: Java backend — Spring Boot server, Maven modules, key packages, entry points, and build commands
globs:
alwaysApply: false
---
# Backend — `app/server/`

- **Stack:** Java 17, Spring Boot 3.x (Reactive WebFlux), MongoDB
- **Build:** Maven (`pom.xml`) — run with `mvn` or `./mvnw`
- **Entry point:** `appsmith-server/src/main/java/com/appsmith/server/ServerApplication.java`

## Maven Modules

| Module | Purpose |
|---|---|
| `appsmith-server` | Core app — controllers, services, domains, repositories, migrations, Git, exports/imports |
| `appsmith-interfaces` | Shared DTOs, models, constants, plugin interfaces (contract layer) |
| `appsmith-plugins` | ~28 datasource plugins (Postgres, Mongo, MySQL, REST API, GraphQL, S3, Snowflake, Redis, Oracle, Google Sheets, OpenAI, Anthropic, etc.) |
| `appsmith-git` | Git integration — file handlers, converters, services for app version control |
| `appsmith-ai` | AI features module |
| `reactive-caching` | Custom reactive caching library |

## Key Packages

`controllers/`, `services/`, `domains/`, `repositories/`, `dtos/`, `configurations/`, `git/`, `authentication/`, `exports/`, `imports/`, `workflows/`, `modules/`, `migrations/`

## EE Pattern

Community and enterprise code coexist. Look for `ce/` and `ee/` sub-packages within each module. Enterprise logic extends or overrides CE implementations.

## Testing

- **Framework:** JUnit
- **Unit tests:** `**/*Test.java`
- **Integration tests:** `**/*IntegrationTest.java`
- **Style check:** Spotless (`./mvnw spotlessCheck`)
261 changes: 102 additions & 159 deletions .cursor/rules/commit/semantic-pr-validator.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,174 +1,117 @@
---
description:
description: Conventional Commits format for PR titles and structured PR descriptions
globs:
alwaysApply: true
alwaysApply: false
---
# Semantic PR Validator

```yaml
name: Semantic PR Validator
description: Validates that PR titles follow the Conventional Commits specification
author: Cursor AI
version: 1.0.0
tags:
- git
- pull-request
- semantic
- conventional-commits
activation:
always: true
event:
- pull_request
- pull_request_title_edit
- command
triggers:
- pull_request.created
- pull_request.edited
- command: "validate_pr_title"
```
# Semantic PR Guidelines

## Part 1: PR Title

PR titles must follow [Conventional Commits](https://www.conventionalcommits.org/). Enforced by the `semantic-prs` GitHub app (config: `.github/semantic.yml`, `titleOnly: true` — only the PR title is validated, not individual commits).

### Format

## Rule Definition

This rule ensures that pull request titles follow the [Conventional Commits](mdc:https:/www.conventionalcommits.org) specification.

## Validation Logic

```javascript
// Function to validate PR titles against Conventional Commits spec
function validatePRTitle(title) {
// Regular expression for conventional commits format
const conventionalCommitRegex = /^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\([a-z0-9-_]+\))?(!)?: [a-z0-9].+$/i;

if (!conventionalCommitRegex.test(title)) {
return {
valid: false,
errors: [
"PR title doesn't follow the Conventional Commits format: type(scope): description",
"Example valid titles:",
"- feat(widget): add new table component",
"- fix: resolve login issue",
"- docs(readme): update installation instructions"
]
};
}

// Check for empty scope in parentheses
if (title.includes('()')) {
return {
valid: false,
errors: [
"Empty scope provided. Either include a scope value or remove the parentheses."
]
};
}

// Extract parts
const match = title.match(/^([a-z]+)(?:\(([a-z0-9-_]+)\))?(!)?:/i);

if (!match || !match[1]) {
return {
valid: false,
errors: [
"Failed to parse PR title format. Please follow the pattern: type(scope): description"
]
};
}

const type = match[1].toLowerCase();

// Validate type
const validTypes = ["feat", "fix", "docs", "style", "refactor",
"perf", "test", "build", "ci", "chore", "revert"];

if (!validTypes.includes(type)) {
return {
valid: false,
errors: [
`Invalid type "${type}". Valid types are: ${validTypes.join(', ')}`
]
};
}

return { valid: true };
}

// Triggered when a PR is created or the title is changed
function onPRTitleChange(prTitle) {
const validation = validatePRTitle(prTitle);

if (!validation.valid) {
return {
status: "failure",
message: "PR title doesn't follow Conventional Commits format",
details: validation.errors.join('\n'),
suggestions: [
{
label: "Fix PR title format",
description: "Update title to follow type(scope): description format"
}
]
};
}

return {
status: "success",
message: "PR title follows Conventional Commits format"
};
}

// Run on activation
function activate(context) {
// Register event handlers
context.on('pull_request.created', (event) => {
const prTitle = event.pull_request.title;
return onPRTitleChange(prTitle);
});

context.on('pull_request.edited', (event) => {
const prTitle = event.pull_request.title;
return onPRTitleChange(prTitle);
});

context.registerCommand('validate_pr_title', (args) => {
const prTitle = args.title || context.currentPR?.title;
if (!prTitle) {
return {
status: "error",
message: "No PR title provided"
};
}
return onPRTitleChange(prTitle);
});
}

// Export the functions
module.exports = {
activate,
onPRTitleChange,
validatePRTitle
};
```
type(scope): description
```

### Valid Types

## When It Runs
- `feat` — new feature
- `fix` — bug fix
- `docs` — documentation only
- `style` — formatting, no logic change
- `refactor` — neither fix nor feature
- `perf` — performance improvement
- `test` — adding or fixing tests
- `build` — build process or dependencies
- `ci` — CI configuration
- `chore` — other non-source changes
- `revert` — reverts a previous commit

This rule automatically runs in the following scenarios:
- When a new pull request is created
- When a pull request title is edited
- When a developer asks for validation via Cursor command: `validate_pr_title`
### Scope

## Usage Example
Optional. Represents the area affected: `client`, `server`, `widgets`, `plugins`, `git`, `auth`, `api`, etc.

To validate a PR title before submitting:
### Title Description

1. Create a branch and make your changes
2. Prepare to create a PR
3. Use the command: `validate_pr_title` in Cursor
4. Cursor will check your title and suggest corrections if needed
- Imperative mood: "add" not "added" or "adds"
- Lowercase first letter
- No trailing period

## Examples of Valid PR Titles
### Title Examples

Valid:
- `feat(widgets): add new table widget capabilities`
- `fix(auth): resolve login redirect issue`
- `docs: update README with setup instructions`
- `docs: update README with new setup instructions`
- `refactor(api): simplify error handling logic`
- `chore: update dependencies to latest versions`
- `chore: update dependencies to latest versions`

Invalid:
- `Added new feature` — missing type
- `fix - login bug` — wrong format
- `feat(client): Added new component.` — capital letter, trailing period, past tense

---

## Part 2: PR Description Body

The PR description follows the template in `.github/pull_request_template.md`. When generating a PR description, gather all needed information **in a single prompt** — do not ask the user multiple times.

### Information Gathering

Before writing the description, ask the user **once** for anything you don't already know. Combine all questions into a single message:
- **Issue link** — "Do you have an issue number or URL to link? (optional)"
- **Cypress tags** — "Any Cypress test tags to run? (optional, leave blank for none)"
- For `feat` PRs — motivation, user-facing behavior, how to test (if not already clear from context)
- For `fix` PRs — root cause, reproduction steps (if not already clear from context)

If the user has already provided this info (e.g., in the conversation or task description), or has explicitly said to skip it, do not ask again.

### Description Structure

```markdown
## Description
<!-- TL;DR required if description exceeds ~500 words or is highly technical -->

<concise summary of what changed and why>

<for feat: motivation, what's new, user-facing impact>
<for fix: root cause, what was broken, how it's fixed>
<for build/chore/refactor: what changed, why, compatibility notes>

Fixes #<issue> or Fixes <URL>
<!-- omit if no issue exists and user chose not to provide one -->

## Automation

/ok-to-test tags="<tags>"

### :mag: Cypress test results
<!-- leave this section untouched — CI auto-populates it -->

## Communication
Should the DevRel and Marketing teams inform users about this change?
- [ ] Yes
- [ ] No
```
Comment on lines +74 to +98
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Template documentation doesn't match actual .github/pull_request_template.md.

The simplified template structure omits important GitHub-specific callouts from the actual template:

  1. Line 76 shows a plain HTML comment for TL;DR, but the actual template has:

    > [!TIP]  
> _Add a TL;DR when the description is longer than 500 words..._

  2. Line 85 suggests issues are optional ("omit if no issue exists and user chose not to provide one"), but the actual template emphasizes:

    > [!WARNING]  
> _If no issue exists, please create an issue first, and check with the maintainers if the issue is valid._

  3. Line 92 says "leave this section untouched", but the actual template uses a stronger warning:

    > [!CAUTION]  
> If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Since line 60 indicates this documentation guides PR generation, the mismatch could cause AI-generated PRs to omit these important callouts, reducing clarity for human reviewers.

📋 Consider aligning with the actual template structure

Either update the documentation to reflect the actual template's GitHub callout blocks, or add a note that this is a simplified reference and the actual template in .github/pull_request_template.md contains additional formatting and warnings.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/commit/semantic-pr-validator.mdc around lines 74 - 98, The PR
template docs in semantic-pr-validator.mdc do not match the real
.github/pull_request_template.md; update the markdown under the
Description/Automation/Communication sections to either mirror the GitHub
callout blocks (include the > [!TIP] TL;DR guidance, > [!WARNING] instruction
about creating an issue, and > [!CAUTION] note about Cypress results) or add a
prominent note that this is a simplified reference and link to the canonical
.github/pull_request_template.md; ensure the "TL;DR" guidance, the "Fixes
#<issue>" behavior, and the "Cypress test results" warning are present and use
the same callout syntax so automated PR generation will include the same
warnings.


### Content Rules by PR Type

| Type | Required Content |
|---|---|
| `feat` | Motivation, what's new, user-facing behavior, how to verify |
| `fix` | Root cause, what was broken, reproduction steps, how it's fixed |
| `perf` | What was slow, what changed, expected improvement |
| `build` / `chore` | What changed, why (e.g., vulnerability, compatibility), version details |
| `refactor` | What was refactored, why, no behavior change confirmation |
| `docs` / `style` / `ci` / `test` | Brief summary of what changed |

### Additional Rules

- **TL;DR**: Include a TL;DR at the top of the Description section when the body exceeds ~500 words or is highly technical.
- **Links**: Include links to Notion, Figma, or other design docs when they exist and are relevant.
- **Screenshots**: Include screenshots or recordings for UI changes.
- **Cypress section**: Never modify the Cypress auto-generated comment block — CI manages it.
- **Communication checkbox**: Leave unchecked by default. Check "Yes" only for user-facing features or breaking changes.
Loading
Loading