chore(cursor-rules): simplify and reorganize cursor rules for CE#41691
Open
sondermanish wants to merge 2 commits intoreleasefrom
Open
chore(cursor-rules): simplify and reorganize cursor rules for CE#41691sondermanish wants to merge 2 commits intoreleasefrom
sondermanish wants to merge 2 commits intoreleasefrom
Conversation
Made-with: Cursor
Contributor
WalkthroughRefactors Cursor AI rules from executable automation into documentation and checklists. Adds new architecture and agent-behavior docs and removes multiple rule scripts that previously provided automated validation, test generation, and pre-commit checks. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (4)
.cursor/rules/commit/semantic-pr-validator.mdc (2)
1-5: Consider removing vestigial metadata or clarifying file purpose.The metadata includes
alwaysApply: false, which is typically used to control when executable rule logic is triggered. However, this file now contains only documentation—no JavaScript validation logic remains.Consider either:
- Removing the activation metadata since there's no logic to apply
- Adding a comment explaining this is AI-instruction documentation, not executable logic
- Renaming to
.mdif it's purely documentationBased on learnings,
.mdcfiles should contain metadata, logic (JavaScript), and documentation, but this file now lacks the logic component.🤖 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 1 - 5, The file .cursor/rules/commit/semantic-pr-validator.mdc contains only documentation but still includes the metadata key alwaysApply: false; either remove the vestigial activation metadata (delete the alwaysApply line and any unused front-matter), or convert the file to a pure Markdown doc by renaming to .md and adding a short comment at the top clarifying it’s AI/documentation-only, or restore the intended JS logic to make the metadata meaningful—update the file so the presence of alwaysApply: false matches actual executable rule logic or is removed/annotated to avoid confusion.
60-70: Consider clarifying the target audience.The language here is AI-oriented ("ask the user once", "gather all needed information in a single prompt", "do not ask again"), suggesting these are instructions for Cursor AI to follow when generating PR descriptions. This is consistent with the PR's goal of converting from executable validators to static guidelines.
However, the file format (documentation without executable logic) creates a slight mismatch—it reads like imperative instructions for an automated agent but has no code to execute them.
For maintainability, consider adding a header comment clarifying this file's purpose: e.g., "Instructions for Cursor AI when assisting with PR creation" vs "Human-facing developer guidelines."
🤖 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 60 - 70, This doc reads like imperative agent instructions but lacks a header clarifying its intended audience; add a brief top-of-file header in .cursor/rules/commit/semantic-pr-validator.mdc stating the purpose and target audience (e.g., "Instructions for Cursor AI when assisting with PR creation — machine-readable agent guidance" or "Human-facing developer guidelines") and indicate whether the rules are meant for automated agents or humans, so consumers of the file know how to interpret the "Information Gathering" section..cursor/rules/agent-behavior.mdc (1)
38-39: Resolve conflicting autonomy vs intent-confirmation guidance.Line 38 says to “just fix it,” while Line 52 requires explicit intent confirmation before write actions. Please reconcile this so behavior is deterministic.
Also applies to: 52-52
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/rules/agent-behavior.mdc around lines 38 - 39, Reconcile the conflicting rules by making behavior deterministic: update the guideline "When given a bug report: just fix it. Don't ask for hand-holding" to include a conditional exception that matches the rule "explicit intent confirmation before write actions" — specifically, treat clearly scoped bug reports (identified by the phrase "When given a bug report: just fix it. Don't ask for hand-holding") as implicit consent to perform fixes and log/announce changes, but require explicit confirmation for any ambiguous, high-impact, or multi-step write actions per the "explicit intent confirmation" rule; ensure both rule texts are edited so they reference each other and define the threshold for "clearly scoped" vs "ambiguous/high-impact" to make behavior deterministic..cursor/rules/verification/feature-verifier.mdc (1)
16-16: "No TODO comments" might be overly strict.The guideline prohibits TODO comments, but these can be valuable for tracking known work items during development. Consider allowing TODO comments in feature branches while enforcing their removal before merging to main/release branches (via CI or PR review).
🔧 Suggested refinement
-- No console.log, TODO comments, or commented-out code +- No console.log or commented-out code in committed code +- Resolve or track all TODO comments before merging to release branches🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/rules/verification/feature-verifier.mdc at line 16, The rule line "No console.log, TODO comments, or commented-out code" is too strict for feature branches; update the rule in feature-verifier to allow TODO comments in non-main branches by changing the text to permit TODOs during development and add guidance that TODOs must be removed before merging to main/release, and ensure enforcement is shifted to CI/PR checks (e.g., a branch-protection or linter job) so that the verifier still rejects TODOs on main/release but not on feature branches.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.cursor/rules/agent-behavior.mdc:
- 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.
In @.cursor/rules/commit/semantic-pr-validator.mdc:
- Around line 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.
In @.cursor/rules/verification/workflow-validator.mdc:
- Line 3: Update the workflow-glob string "globs: .github/workflows/**/*.yml" to
also match .yaml files by expanding it (for example to "globs:
.github/workflows/**/*.{yml,yaml}" or adding an additional pattern) so
workflow-validator.mdc covers both .yml and .yaml workflow filenames.
---
Nitpick comments:
In @.cursor/rules/agent-behavior.mdc:
- Around line 38-39: Reconcile the conflicting rules by making behavior
deterministic: update the guideline "When given a bug report: just fix it. Don't
ask for hand-holding" to include a conditional exception that matches the rule
"explicit intent confirmation before write actions" — specifically, treat
clearly scoped bug reports (identified by the phrase "When given a bug report:
just fix it. Don't ask for hand-holding") as implicit consent to perform fixes
and log/announce changes, but require explicit confirmation for any ambiguous,
high-impact, or multi-step write actions per the "explicit intent confirmation"
rule; ensure both rule texts are edited so they reference each other and define
the threshold for "clearly scoped" vs "ambiguous/high-impact" to make behavior
deterministic.
In @.cursor/rules/commit/semantic-pr-validator.mdc:
- Around line 1-5: The file .cursor/rules/commit/semantic-pr-validator.mdc
contains only documentation but still includes the metadata key alwaysApply:
false; either remove the vestigial activation metadata (delete the alwaysApply
line and any unused front-matter), or convert the file to a pure Markdown doc by
renaming to .md and adding a short comment at the top clarifying it’s
AI/documentation-only, or restore the intended JS logic to make the metadata
meaningful—update the file so the presence of alwaysApply: false matches actual
executable rule logic or is removed/annotated to avoid confusion.
- Around line 60-70: This doc reads like imperative agent instructions but lacks
a header clarifying its intended audience; add a brief top-of-file header in
.cursor/rules/commit/semantic-pr-validator.mdc stating the purpose and target
audience (e.g., "Instructions for Cursor AI when assisting with PR creation —
machine-readable agent guidance" or "Human-facing developer guidelines") and
indicate whether the rules are meant for automated agents or humans, so
consumers of the file know how to interpret the "Information Gathering" section.
In @.cursor/rules/verification/feature-verifier.mdc:
- Line 16: The rule line "No console.log, TODO comments, or commented-out code"
is too strict for feature branches; update the rule in feature-verifier to allow
TODO comments in non-main branches by changing the text to permit TODOs during
development and add guidance that TODOs must be removed before merging to
main/release, and ensure enforcement is shifted to CI/PR checks (e.g., a
branch-protection or linter job) so that the verifier still rejects TODOs on
main/release but not on feature branches.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4330bb22-cbf2-4742-b4cd-ec41763dbe21
📒 Files selected for processing (16)
.cursor/rules/agent-behavior.mdc.cursor/rules/backend.mdc.cursor/rules/commit/semantic-pr-validator.mdc.cursor/rules/commit/semantic-pr.md.cursor/rules/frontend.mdc.cursor/rules/index.md.cursor/rules/index.mdc.cursor/rules/infra.mdc.cursor/rules/quality/performance-optimizer.mdc.cursor/rules/quality/pre-commit-checks.mdc.cursor/rules/task-list.mdc.cursor/rules/testing/test-generator.mdc.cursor/rules/verification/bug-fix-verifier.mdc.cursor/rules/verification/feature-implementation-validator.mdc.cursor/rules/verification/feature-verifier.mdc.cursor/rules/verification/workflow-validator.mdc
💤 Files with no reviewable changes (5)
- .cursor/rules/task-list.mdc
- .cursor/rules/index.md
- .cursor/rules/commit/semantic-pr.md
- .cursor/rules/verification/feature-implementation-validator.mdc
- .cursor/rules/quality/pre-commit-checks.mdc
| - **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. No newline at end of file |
Contributor
There was a problem hiding this comment.
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.
Comment on lines
+74
to
+98
| ```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 | ||
| ``` |
Contributor
There was a problem hiding this comment.
Template documentation doesn't match actual .github/pull_request_template.md.
The simplified template structure omits important GitHub-specific callouts from the actual template:
-
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..._
-
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._
-
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.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.cursor/rules/verification/workflow-validator.mdc:
- Around line 5-23: The commit replaced executable validation with a passive
checklist, removing the exported activate() and validateWorkflows() functions
that the validation framework expects; restore executable behavior by
reintroducing the rule metadata and the exported functions (activate and
validateWorkflows) so the framework can load and run the checker, or if you
intentionally made it docs-only, add metadata signaling a non-executable rule
and update the framework integration to skip it; while restoring logic,
incorporate Appsmith-specific guidance (e.g., valid custom runners like
ubuntu-22.04-8core) into the validation logic or checklist to prevent false
positives and ensure validateWorkflows enforces runs-on and other required
fields.
- Around line 2-3: The change set flips alwaysApply: false which disables
automatic enforcement of this workflow-validator rule (globs:
.github/workflows/**/*.{yaml,yml}), turning it into passive documentation;
restore the prior behavior by setting alwaysApply: true or, if intentional to
keep manual mode, reintroduce the executable validation logic that used to run
automatically so teams still get automatic checks—update the rule by changing
alwaysApply back to true or by adding the validation hook (the
workflow-validator rule's executable/validation entry) so GitHub Actions file
edits are automatically validated.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 71e2379b-1977-4305-816e-cf5b37531e53
📒 Files selected for processing (1)
.cursor/rules/verification/workflow-validator.mdc
Comment on lines
+2
to
+3
| globs: .github/workflows/**/*.{yaml,yml} | ||
| alwaysApply: false |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if any other workflow validation mechanisms exist in the codebase
echo "=== Searching for alternative workflow validation logic ==="
rg -n --type=yaml --type=json --type=js --type=ts -C2 'workflow.*validat|validateWorkflow' -g '!node_modules' -g '!.cursor/rules/verification/workflow-validator.mdc'
echo ""
echo "=== Checking .cursor/settings.json for validation config ==="
fd -t f 'settings.json' .cursor/ --exec cat {}Repository: appsmithorg/appsmith
Length of output: 1806
Behavioral change: alwaysApply: false disables automatic rule triggering.
The glob pattern fix is addressed (both .yaml and .yml now covered). However, setting alwaysApply: false combined with removing the executable validation logic means this rule transitions from active enforcement to passive documentation. Developers must now manually invoke the rule or rely on Cursor AI's contextual application.
Confirm this aligns with your workflow quality assurance strategy, particularly if teams previously relied on automated validation when editing GitHub Actions files.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.cursor/rules/verification/workflow-validator.mdc around lines 2 - 3, The
change set flips alwaysApply: false which disables automatic enforcement of this
workflow-validator rule (globs: .github/workflows/**/*.{yaml,yml}), turning it
into passive documentation; restore the prior behavior by setting alwaysApply:
true or, if intentional to keep manual mode, reintroduce the executable
validation logic that used to run automatically so teams still get automatic
checks—update the rule by changing alwaysApply back to true or by adding the
validation hook (the workflow-validator rule's executable/validation entry) so
GitHub Actions file edits are automatically validated.
Comment on lines
+5
to
+23
| # GitHub Actions Workflow Validation | ||
|
|
||
| ```yaml | ||
| name: Workflow Configuration Validator | ||
| description: Validates GitHub workflow files before commits and pushes | ||
| author: Cursor AI | ||
| version: 1.0.0 | ||
| tags: | ||
| - ci | ||
| - workflows | ||
| - quality-checks | ||
| - validation | ||
| activation: | ||
| always: true | ||
| events: | ||
| - pre_commit | ||
| - pre_push | ||
| - command | ||
| triggers: | ||
| - pre_commit | ||
| - pre_push | ||
| - command: "validate_workflows" | ||
| ``` | ||
| When editing workflow files, ensure: | ||
|
|
||
| ## Rule Definition | ||
| ## Required Structure | ||
|
|
||
| This rule ensures that GitHub workflow configuration files (especially `.github/workflows/quality-checks.yml`) are valid before allowing commits or pushes. | ||
| Every workflow YAML must have: | ||
| - `name` — descriptive workflow name | ||
| - `on` — trigger configuration (push, pull_request, etc.) | ||
| - `jobs` — at least one job defined | ||
| - Each job must have `runs-on` specified | ||
|
|
||
| ## Validation Logic | ||
| ## Common Mistakes | ||
|
|
||
| ```javascript | ||
| const yaml = require('js-yaml'); | ||
| const fs = require('fs'); | ||
| const { execSync } = require('child_process'); | ||
|
|
||
| /** | ||
| * Main function to validate GitHub workflow files | ||
| * @param {Object} context - The execution context | ||
| * @returns {Object} Validation results | ||
| */ | ||
| function validateWorkflows(context) { | ||
| const results = { | ||
| isValid: true, | ||
| errors: [], | ||
| warnings: [] | ||
| }; | ||
|
|
||
| // Primary focus: quality-checks.yml | ||
| const qualityChecksPath = '.github/workflows/quality-checks.yml'; | ||
|
|
||
| try { | ||
| // Check if file exists | ||
| if (!fs.existsSync(qualityChecksPath)) { | ||
| results.errors.push(`${qualityChecksPath} file does not exist`); | ||
| results.isValid = false; | ||
| return results; | ||
| } | ||
|
|
||
| // Check if file is valid YAML | ||
| try { | ||
| const fileContents = fs.readFileSync(qualityChecksPath, 'utf8'); | ||
| const parsedYaml = yaml.load(fileContents); | ||
|
|
||
| // Check for required fields in workflow | ||
| if (!parsedYaml.name) { | ||
| results.warnings.push(`${qualityChecksPath} is missing a name field`); | ||
| } | ||
|
|
||
| if (!parsedYaml.jobs || Object.keys(parsedYaml.jobs).length === 0) { | ||
| results.errors.push(`${qualityChecksPath} doesn't contain any jobs`); | ||
| results.isValid = false; | ||
| } | ||
|
|
||
| // Check for common GitHub Actions workflow validation | ||
| if (context.hasCommand('gh')) { | ||
| try { | ||
| // Use GitHub CLI to validate workflow if available | ||
| execSync(`gh workflow view ${qualityChecksPath} --json`, { stdio: 'pipe' }); | ||
| } catch (error) { | ||
| results.errors.push(`GitHub CLI validation failed: ${error.message}`); | ||
| results.isValid = false; | ||
| } | ||
| } else { | ||
| // Basic structural validation if GitHub CLI is not available | ||
| const requiredKeys = ['on', 'jobs']; | ||
| for (const key of requiredKeys) { | ||
| if (!parsedYaml[key]) { | ||
| results.errors.push(`${qualityChecksPath} is missing required key: ${key}`); | ||
| results.isValid = false; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| // Check for other workflows | ||
| const workflowsDir = '.github/workflows'; | ||
| if (fs.existsSync(workflowsDir)) { | ||
| const workflowFiles = fs.readdirSync(workflowsDir) | ||
| .filter(file => file.endsWith('.yml') || file.endsWith('.yaml')); | ||
|
|
||
| // Validate all workflow files | ||
| for (const file of workflowFiles) { | ||
| if (file === 'quality-checks.yml') continue; // Already checked | ||
|
|
||
| const filePath = `${workflowsDir}/${file}`; | ||
| try { | ||
| const contents = fs.readFileSync(filePath, 'utf8'); | ||
| yaml.load(contents); // Just check if it's valid YAML | ||
| } catch (e) { | ||
| results.errors.push(`${filePath} contains invalid YAML: ${e.message}`); | ||
| results.isValid = false; | ||
| } | ||
| } | ||
| } | ||
| } catch (e) { | ||
| results.errors.push(`Failed to parse ${qualityChecksPath}: ${e.message}`); | ||
| results.isValid = false; | ||
| } | ||
| } catch (error) { | ||
| results.errors.push(`General error validating workflows: ${error.message}`); | ||
| results.isValid = false; | ||
| } | ||
|
|
||
| return results; | ||
| } | ||
|
|
||
| /** | ||
| * Check if workflow files have been modified in the current changes | ||
| * @param {Object} context - The execution context | ||
| * @returns {boolean} Whether workflow files have been modified | ||
| */ | ||
| function haveWorkflowsChanged(context) { | ||
| try { | ||
| const gitStatus = execSync('git diff --name-only --cached', { encoding: 'utf8' }); | ||
| const changedFiles = gitStatus.split('\n').filter(Boolean); | ||
|
|
||
| return changedFiles.some(file => | ||
| file.startsWith('.github/workflows/') && | ||
| (file.endsWith('.yml') || file.endsWith('.yaml')) | ||
| ); | ||
| } catch (error) { | ||
| // If we can't determine if workflows changed, assume they did to be safe | ||
| return true; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Run the validation when triggered | ||
| * @param {Object} context - The execution context | ||
| * @returns {Object} The action result | ||
| */ | ||
| function onTrigger(context, event) { | ||
| // For pre-commit and pre-push, only validate if workflow files have changed | ||
| if ((event === 'pre_commit' || event === 'pre_push') && !haveWorkflowsChanged(context)) { | ||
| return { | ||
| status: 'success', | ||
| message: 'No workflow files changed, skipping validation' | ||
| }; | ||
| } | ||
|
|
||
| const results = validateWorkflows(context); | ||
|
|
||
| if (!results.isValid) { | ||
| return { | ||
| status: 'failure', | ||
| message: 'Workflow validation failed', | ||
| details: results.errors.join('\n'), | ||
| warnings: results.warnings.join('\n') | ||
| }; | ||
| } | ||
|
|
||
| return { | ||
| status: 'success', | ||
| message: 'All workflow files are valid', | ||
| warnings: results.warnings.length ? results.warnings.join('\n') : undefined | ||
| }; | ||
| } | ||
|
|
||
| /** | ||
| * Register command and hooks | ||
| * @param {Object} context - The cursor context | ||
| */ | ||
| function activate(context) { | ||
| // Register pre-commit hook | ||
| context.on('pre_commit', (event) => { | ||
| return onTrigger(context, 'pre_commit'); | ||
| }); | ||
|
|
||
| // Register pre-push hook | ||
| context.on('pre_push', (event) => { | ||
| return onTrigger(context, 'pre_push'); | ||
| }); | ||
|
|
||
| // Register command for manual validation | ||
| context.registerCommand('validate_workflows', () => { | ||
| return onTrigger(context, 'command'); | ||
| }); | ||
| } | ||
|
|
||
| module.exports = { | ||
| activate, | ||
| validateWorkflows | ||
| }; | ||
| ``` | ||
|
|
||
| ## Usage | ||
|
|
||
| This rule runs automatically on pre-commit and pre-push events. You can also manually trigger it with the command `validate_workflows`. | ||
|
|
||
| ### Pre-Commit Hook | ||
|
|
||
| When committing changes, this rule will: | ||
| 1. Check if any workflow files were modified | ||
| 2. If so, validate that `.github/workflows/quality-checks.yml` is properly formatted | ||
| 3. Block the commit if validation fails | ||
|
|
||
| ### Examples | ||
|
|
||
| **Valid Workflow:** | ||
| ```yaml | ||
| name: Quality Checks | ||
| on: | ||
| push: | ||
| branches: [ main ] | ||
| pull_request: | ||
| branches: [ main ] | ||
| jobs: | ||
| lint: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - name: Run linters | ||
| run: | | ||
| npm ci | ||
| npm run lint | ||
| ``` | ||
|
|
||
| **Invalid Workflow (Will Fail Validation):** | ||
| ```yaml | ||
| on: | ||
| push: | ||
| jobs: | ||
| lint: | ||
| # Missing "runs-on" field | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - name: Run linters | ||
| run: npm run lint | ||
| ``` No newline at end of file | ||
| - Missing `runs-on` in a job definition | ||
| - Invalid YAML syntax (bad indentation, missing colons) | ||
| - Referencing non-existent secrets or variables | ||
| - Using deprecated action versions (prefer `@v4` for checkout, setup-node, etc.) | ||
| - Missing `permissions` block when workflow needs write access |
Contributor
There was a problem hiding this comment.
Functional change: executable validation replaced with static checklist.
This file previously exported activate() and validateWorkflows() functions that performed automated validation. It's now a passive markdown checklist with no executable logic.
The change creates a disconnect with retrieved learnings that state:
- "Development workflows must be validated according to 'workflow-validator.mdc'"
- ".mdc rules must have metadata, logic (JavaScript), and documentation"
While the simplification aligns with the PR's stated goal (-3,764 lines), teams expecting automated workflow validation will no longer have it. Based on learnings, this rule was part of a validation framework.
Consider adding Appsmith-specific guidance to the checklist, such as valid custom runners (e.g., ubuntu-22.04-8core per learnings) to reduce false positives when developers reference this documentation.
Optional: Enhance checklist with Appsmith-specific context
## Common Mistakes
- Missing `runs-on` in a job definition
+- Using invalid runner (valid custom runners for Appsmith: `ubuntu-22.04-8core`)
- Invalid YAML syntax (bad indentation, missing colons)
- Referencing non-existent secrets or variables
- Using deprecated action versions (prefer `@v4` for checkout, setup-node, etc.)
- Missing `permissions` block when workflow needs write access🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.cursor/rules/verification/workflow-validator.mdc around lines 5 - 23, The
commit replaced executable validation with a passive checklist, removing the
exported activate() and validateWorkflows() functions that the validation
framework expects; restore executable behavior by reintroducing the rule
metadata and the exported functions (activate and validateWorkflows) so the
framework can load and run the checker, or if you intentionally made it
docs-only, add metadata signaling a non-executable rule and update the framework
integration to skip it; while restoring logic, incorporate Appsmith-specific
guidance (e.g., valid custom runners like ubuntu-22.04-8core) into the
validation logic or checklist to prevent false positives and ensure
validateWorkflows enforces runs-on and other required fields.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Reorganize and simplify
.cursor/rules/for the CE codebase:agent-behavior.mdc,backend.mdc,frontend.mdc,infra.mdcindex.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 contentsemantic-pr.md,index.md,pre-commit-checks.mdc,task-list.mdc,feature-implementation-validator.mdcNet result: +443 / -3,764 lines — leaner, more actionable rules.
Communication
Should the DevRel and Marketing teams inform users about this change?
Made with Cursor
Summary by CodeRabbit
Warning
Tests have not run on the HEAD e6c3b70 yet
Fri, 03 Apr 2026 10:55:16 UTC