Skip to content

Commit db3cbd2

Browse files
sondermanishsondermanish
authored
chore(cursor-rules): simplify and reorganize cursor rules for CE (#41691)
## Description Reorganize and simplify `.cursor/rules/` for the CE codebase: - **Added** focused domain rules: `agent-behavior.mdc`, `backend.mdc`, `frontend.mdc`, `infra.mdc` - **Simplified** existing rules (`index.mdc`, `semantic-pr-validator.mdc`, `performance-optimizer.mdc`, `test-generator.mdc`, `bug-fix-verifier.mdc`, `feature-verifier.mdc`, `workflow-validator.mdc`) — reduced verbosity and removed redundant content - **Removed** obsolete/redundant rules: `semantic-pr.md`, `index.md`, `pre-commit-checks.mdc`, `task-list.mdc`, `feature-implementation-validator.mdc` Net result: **+443 / -3,764 lines** — leaner, more actionable rules. ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [x] No Made with [Cursor](https://cursor.com) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added comprehensive stack and infrastructure documentation for backend, frontend, and infra. * Added agent behavior, task-management, and workflow guidance. * Replaced previously automated validation rules with static reference checklists for PRs, testing, bug fixes, feature implementation, performance, and workflow reviews. * Consolidated and restructured rule indexing into an architecture-oriented overview. * **Chores** * Removed legacy executable rule implementations and activation hooks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- This is an auto-generated comment: Cypress test results --> > [!WARNING] > Tests have not run on the HEAD e6c3b70 yet > <hr>Fri, 03 Apr 2026 10:55:16 UTC <!-- end of auto-generated comment: Cypress test results -->
1 parent 7f10885 commit db3cbd2

16 files changed

Lines changed: 442 additions & 3764 deletions

‎.cursor/rules/agent-behavior.mdc‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
description: Agent workflow orchestration, task management, and core principles for all interactions
3+
globs:
4+
alwaysApply: true
5+
---
6+
7+
# Agent Behavior
8+
9+
## Workflow Orchestration
10+
### 1. Plan Node Default
11+
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
12+
- If something goes sideways, STOP and re-plan immediately - don't keep pushing
13+
- Use plan mode for verification steps, not just building
14+
- Use subagents to build in plan mode when tasks are independent
15+
- Write detailed specs upfront to reduce ambiguity
16+
### 2. Subagent Strategy
17+
- Use subagents liberally to keep main context window clean
18+
- Offload research, exploration, and parallel analysis to subagents
19+
- For complex problems, throw more compute at it via subagents
20+
- One tack per subagent for focused execution
21+
### 3. Self-Improvement Loop
22+
- After ANY correction from the user: update `.cursor/lessons.md` with the pattern
23+
- Add the learning in `.claude/lessons.md` incrementally
24+
- Write rules for yourself that prevent the same mistake
25+
- Ruthlessly iterate on these lessons until mistake rate drops
26+
- Review lessons at session start for relevant project
27+
### 4. Verification Before Done
28+
- Never mark a task complete without proving it works
29+
- Diff behavior between main and your changes when relevant
30+
- Ask yourself: "Would a staff engineer approve this?"
31+
- Run tests, check logs, demonstrate correctness
32+
### 5. Demand Elegance (Balanced)
33+
- For non-trivial changes: pause and ask "is there a more elegant way?"
34+
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
35+
- Skip this for simple, obvious fixes - don't over-engineer
36+
- Challenge your own work before presenting it
37+
### 6. Autonomous Bug Fixing
38+
- When given a bug report: just fix it. Don't ask for hand-holding
39+
- Point at logs, errors, failing tests - then resolve them
40+
- Zero context switching required from the user
41+
- Go fix failing CI tests without being told how
42+
## Task Management
43+
1. **Plan First**: Write plan to `.cursor/todo.md` with checkable items
44+
2. **Verify Plan**: Check in before starting implementation
45+
3. **Track Progress**: Mark items complete as you go
46+
4. **Explain Changes**: High-level summary at each step
47+
5. **Document Results**: Add review section to `.cursor/todo.md`
48+
6. **Capture Lessons**: Update `.cursor/lessons.md` after corrections
49+
## Core Principles
50+
- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
51+
- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
52+
- **No Trigger Happy**: Don't start write actions and long plans without confirming intent from user explicitly
53+
- **Minimat Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

‎.cursor/rules/backend.mdc‎

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
description: Java backend — Spring Boot server, Maven modules, key packages, entry points, and build commands
3+
globs:
4+
alwaysApply: false
5+
---
6+
# Backend — `app/server/`
7+
8+
- **Stack:** Java 17, Spring Boot 3.x (Reactive WebFlux), MongoDB
9+
- **Build:** Maven (`pom.xml`) — run with `mvn` or `./mvnw`
10+
- **Entry point:** `appsmith-server/src/main/java/com/appsmith/server/ServerApplication.java`
11+
12+
## Maven Modules
13+
14+
| Module | Purpose |
15+
|---|---|
16+
| `appsmith-server` | Core app — controllers, services, domains, repositories, migrations, Git, exports/imports |
17+
| `appsmith-interfaces` | Shared DTOs, models, constants, plugin interfaces (contract layer) |
18+
| `appsmith-plugins` | ~28 datasource plugins (Postgres, Mongo, MySQL, REST API, GraphQL, S3, Snowflake, Redis, Oracle, Google Sheets, OpenAI, Anthropic, etc.) |
19+
| `appsmith-git` | Git integration — file handlers, converters, services for app version control |
20+
| `appsmith-ai` | AI features module |
21+
| `reactive-caching` | Custom reactive caching library |
22+
23+
## Key Packages
24+
25+
`controllers/`, `services/`, `domains/`, `repositories/`, `dtos/`, `configurations/`, `git/`, `authentication/`, `exports/`, `imports/`, `workflows/`, `modules/`, `migrations/`
26+
27+
## EE Pattern
28+
29+
Community and enterprise code coexist. Look for `ce/` and `ee/` sub-packages within each module. Enterprise logic extends or overrides CE implementations.
30+
31+
## Testing
32+
33+
- **Framework:** JUnit
34+
- **Unit tests:** `**/*Test.java`
35+
- **Integration tests:** `**/*IntegrationTest.java`
36+
- **Style check:** Spotless (`./mvnw spotlessCheck`)

‎.cursor/rules/commit/semantic-pr-validator.mdc‎

Lines changed: 102 additions & 159 deletions
Original file line numberDiff line numberDiff line change
@@ -1,174 +1,117 @@
11
---
2-
description:
2+
description: Conventional Commits format for PR titles and structured PR descriptions
33
globs:
4-
alwaysApply: true
4+
alwaysApply: false
55
---
6-
# Semantic PR Validator
7-
8-
```yaml
9-
name: Semantic PR Validator
10-
description: Validates that PR titles follow the Conventional Commits specification
11-
author: Cursor AI
12-
version: 1.0.0
13-
tags:
14-
- git
15-
- pull-request
16-
- semantic
17-
- conventional-commits
18-
activation:
19-
always: true
20-
event:
21-
- pull_request
22-
- pull_request_title_edit
23-
- command
24-
triggers:
25-
- pull_request.created
26-
- pull_request.edited
27-
- command: "validate_pr_title"
28-
```
6+
# Semantic PR Guidelines
7+
8+
## Part 1: PR Title
9+
10+
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).
11+
12+
### Format
2913

30-
## Rule Definition
31-
32-
This rule ensures that pull request titles follow the [Conventional Commits](mdc:https:/www.conventionalcommits.org) specification.
33-
34-
## Validation Logic
35-
36-
```javascript
37-
// Function to validate PR titles against Conventional Commits spec
38-
function validatePRTitle(title) {
39-
// Regular expression for conventional commits format
40-
const conventionalCommitRegex = /^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\([a-z0-9-_]+\))?(!)?: [a-z0-9].+$/i;
41-
42-
if (!conventionalCommitRegex.test(title)) {
43-
return {
44-
valid: false,
45-
errors: [
46-
"PR title doesn't follow the Conventional Commits format: type(scope): description",
47-
"Example valid titles:",
48-
"- feat(widget): add new table component",
49-
"- fix: resolve login issue",
50-
"- docs(readme): update installation instructions"
51-
]
52-
};
53-
}
54-
55-
// Check for empty scope in parentheses
56-
if (title.includes('()')) {
57-
return {
58-
valid: false,
59-
errors: [
60-
"Empty scope provided. Either include a scope value or remove the parentheses."
61-
]
62-
};
63-
}
64-
65-
// Extract parts
66-
const match = title.match(/^([a-z]+)(?:\(([a-z0-9-_]+)\))?(!)?:/i);
67-
68-
if (!match || !match[1]) {
69-
return {
70-
valid: false,
71-
errors: [
72-
"Failed to parse PR title format. Please follow the pattern: type(scope): description"
73-
]
74-
};
75-
}
76-
77-
const type = match[1].toLowerCase();
78-
79-
// Validate type
80-
const validTypes = ["feat", "fix", "docs", "style", "refactor",
81-
"perf", "test", "build", "ci", "chore", "revert"];
82-
83-
if (!validTypes.includes(type)) {
84-
return {
85-
valid: false,
86-
errors: [
87-
`Invalid type "${type}". Valid types are: ${validTypes.join(', ')}`
88-
]
89-
};
90-
}
91-
92-
return { valid: true };
93-
}
94-
95-
// Triggered when a PR is created or the title is changed
96-
function onPRTitleChange(prTitle) {
97-
const validation = validatePRTitle(prTitle);
98-
99-
if (!validation.valid) {
100-
return {
101-
status: "failure",
102-
message: "PR title doesn't follow Conventional Commits format",
103-
details: validation.errors.join('\n'),
104-
suggestions: [
105-
{
106-
label: "Fix PR title format",
107-
description: "Update title to follow type(scope): description format"
108-
}
109-
]
110-
};
111-
}
112-
113-
return {
114-
status: "success",
115-
message: "PR title follows Conventional Commits format"
116-
};
117-
}
118-
119-
// Run on activation
120-
function activate(context) {
121-
// Register event handlers
122-
context.on('pull_request.created', (event) => {
123-
const prTitle = event.pull_request.title;
124-
return onPRTitleChange(prTitle);
125-
});
126-
127-
context.on('pull_request.edited', (event) => {
128-
const prTitle = event.pull_request.title;
129-
return onPRTitleChange(prTitle);
130-
});
131-
132-
context.registerCommand('validate_pr_title', (args) => {
133-
const prTitle = args.title || context.currentPR?.title;
134-
if (!prTitle) {
135-
return {
136-
status: "error",
137-
message: "No PR title provided"
138-
};
139-
}
140-
return onPRTitleChange(prTitle);
141-
});
142-
}
143-
144-
// Export the functions
145-
module.exports = {
146-
activate,
147-
onPRTitleChange,
148-
validatePRTitle
149-
};
15014
```
15+
type(scope): description
16+
```
17+
18+
### Valid Types
15119

152-
## When It Runs
20+
- `feat` — new feature
21+
- `fix` — bug fix
22+
- `docs` — documentation only
23+
- `style` — formatting, no logic change
24+
- `refactor` — neither fix nor feature
25+
- `perf` — performance improvement
26+
- `test` — adding or fixing tests
27+
- `build` — build process or dependencies
28+
- `ci` — CI configuration
29+
- `chore` — other non-source changes
30+
- `revert` — reverts a previous commit
15331

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

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

161-
To validate a PR title before submitting:
36+
### Title Description
16237

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

168-
## Examples of Valid PR Titles
42+
### Title Examples
16943

44+
Valid:
17045
- `feat(widgets): add new table widget capabilities`
17146
- `fix(auth): resolve login redirect issue`
172-
- `docs: update README with setup instructions`
47+
- `docs: update README with new setup instructions`
17348
- `refactor(api): simplify error handling logic`
174-
- `chore: update dependencies to latest versions`
49+
- `chore: update dependencies to latest versions`
50+
51+
Invalid:
52+
- `Added new feature` — missing type
53+
- `fix - login bug` — wrong format
54+
- `feat(client): Added new component.` — capital letter, trailing period, past tense
55+
56+
---
57+
58+
## Part 2: PR Description Body
59+
60+
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.
61+
62+
### Information Gathering
63+
64+
Before writing the description, ask the user **once** for anything you don't already know. Combine all questions into a single message:
65+
- **Issue link** — "Do you have an issue number or URL to link? (optional)"
66+
- **Cypress tags** — "Any Cypress test tags to run? (optional, leave blank for none)"
67+
- For `feat` PRs — motivation, user-facing behavior, how to test (if not already clear from context)
68+
- For `fix` PRs — root cause, reproduction steps (if not already clear from context)
69+
70+
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.
71+
72+
### Description Structure
73+
74+
```markdown
75+
## Description
76+
<!-- TL;DR required if description exceeds ~500 words or is highly technical -->
77+
78+
<concise summary of what changed and why>
79+
80+
<for feat: motivation, what's new, user-facing impact>
81+
<for fix: root cause, what was broken, how it's fixed>
82+
<for build/chore/refactor: what changed, why, compatibility notes>
83+
84+
Fixes #<issue> or Fixes <URL>
85+
<!-- omit if no issue exists and user chose not to provide one -->
86+
87+
## Automation
88+
89+
/ok-to-test tags="<tags>"
90+
91+
### :mag: Cypress test results
92+
<!-- leave this section untouched — CI auto-populates it -->
93+
94+
## Communication
95+
Should the DevRel and Marketing teams inform users about this change?
96+
- [ ] Yes
97+
- [ ] No
98+
```
99+
100+
### Content Rules by PR Type
101+
102+
| Type | Required Content |
103+
|---|---|
104+
| `feat` | Motivation, what's new, user-facing behavior, how to verify |
105+
| `fix` | Root cause, what was broken, reproduction steps, how it's fixed |
106+
| `perf` | What was slow, what changed, expected improvement |
107+
| `build` / `chore` | What changed, why (e.g., vulnerability, compatibility), version details |
108+
| `refactor` | What was refactored, why, no behavior change confirmation |
109+
| `docs` / `style` / `ci` / `test` | Brief summary of what changed |
110+
111+
### Additional Rules
112+
113+
- **TL;DR**: Include a TL;DR at the top of the Description section when the body exceeds ~500 words or is highly technical.
114+
- **Links**: Include links to Notion, Figma, or other design docs when they exist and are relevant.
115+
- **Screenshots**: Include screenshots or recordings for UI changes.
116+
- **Cypress section**: Never modify the Cypress auto-generated comment block — CI manages it.
117+
- **Communication checkbox**: Leave unchecked by default. Check "Yes" only for user-facing features or breaking changes.

0 commit comments

Comments
 (0)