Add Cursor AI rules for consistent development assistance #3437
Conversation
This adds a comprehensive set of Cursor AI rules to provide: - Core rules: Project context, coding standards, common commands - File-specific rules: React, TypeScript, SCSS, testing, i18n patterns - Agent personas: Developer, UX, QE, Security, KubeVirt expert - Workflows: Component creation, PR prep, debugging, Jira, Playwright - Documentation: AI_README.md and GETTING_STARTED_AI.md guides - MCP integrations: Jira ticket management, interactive browser testing Rules are automatically loaded when opening the project in Cursor IDE, providing consistent coding assistance across the team. Personal rules (personal-*.mdc) are gitignored for individual customization. Co-authored-by: Cursor <[email protected]>
📝 WalkthroughWalkthroughAdds many new Cursor AI rule and project documentation files (agent specs, coding standards, workflows, testing/i18n/style/type guidance, onboarding docs) plus a small .gitignore update and removal of the legacy Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Suggested labels
Suggested reviewers
🚥 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)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.cursor/rules/typescript.mdc:
- Around line 367-368: The summary line in the "Don't" section currently reads
"Use `any` type anywhere" which contradicts the intent; update that phrase to
"Don't use `any` type anywhere" (or "Never use `any` type") so the rule aligns
with the rest of the document and clearly forbids the `any` type in the
TypeScript best-practices block.
🧹 Nitpick comments (10)
GETTING_STARTED_AI.md (1)
88-415: Add language tags to fenced code blocks to satisfy MD040.markdownlint reports multiple fenced blocks without a language. Please annotate them (e.g.,
text for prompt examples,bash for shell commands).AI_README.md (1)
69-214: Add language tags to fenced code blocks to satisfy MD040.markdownlint reports fenced blocks without a language. Please annotate them (e.g.,
text for prompt examples,bash for shell commands)..cursor/rules/typescript.mdc (1)
3-3: Consider expanding the glob pattern to include.tsxfiles.The current glob pattern
"**/*.ts"only matches TypeScript files without JSX. However, based on learnings, many TypeScript conventions (avoidingany, explicit return types, preferringtypeoverinterface, etc.) also apply to.tsxfiles. Consider using"**/*.{ts,tsx}"to ensure these guidelines are active when working with React components.📝 Suggested adjustment to glob pattern
-globs: "**/*.ts" +globs: "**/*.{ts,tsx}".cursor/rules/agents/security-reviewer.mdc (1)
215-220: Consider adding npm audit reference for dependency security.The dependency security section (lines 215-220) mentions known vulnerabilities, outdated packages, and supply chain concerns. Consider adding a reference to
npm auditas a practical tool for identifying these issues, especially since the project includes this as part of the quality check workflow.🔧 Suggested addition
**Dependency Security** - Known vulnerabilities in dependencies - Outdated packages - Typosquatting risk - Supply chain attacks - Lock file integrity +- Run `npm audit` regularly +- Check GitHub security advisories.cursor/rules/agents/qe-agent.mdc (1)
188-213: Consider adding mobile/responsive testing to environment variations.The Environment & Configuration section comprehensively covers browsers, network, cluster, and user variations. However, given that the project uses PatternFly (which supports responsive design) and line 182 mentions "Responsive design tested" in E2E coverage, consider explicitly adding mobile/responsive testing guidance here.
📱 Suggested addition
**Browser Variations** - Different browsers (Chrome, Firefox, Safari, Edge) - Different browser versions - Private/incognito mode - Browser extensions interfering - Different screen sizes +- Mobile viewport sizes +- Touch vs mouse interactions +- Responsive breakpoint transitions.cursor/rules/workflows/new-component.mdc (1)
23-31: Consider adding Error Boundary guidance to component types.The component types section comprehensively covers Page, Container, Presentational, Modal, and Form components. Based on learnings, class components are used for specific lifecycle methods like
componentDidCatch. Consider adding an Error Boundary component type to this list, as it's a distinct pattern used for catching and handling errors in the component tree.🛡️ Suggested addition
### Form Components - Use react-hook-form - Validation and error display - Loading/submitting states - Accessible labels and errors + +### Error Boundary Components +- Catch errors in child component tree +- Use class component with componentDidCatch +- Provide fallback UI for errors +- Log errors for debugging.cursor/rules/agents/ux-reviewer.mdc (1)
299-315: Add a prompt for visual evidence on UX changes.Consider extending the Output Format or checklist to request screenshots/video when UI changes are reviewed. Based on learnings: Add a main PR comment explaining referenced links, Jira, doc, use cases, and current/required state. When there are visual changes, add videos and/or screenshots.
.cursor/rules/agents/developer.mdc (1)
254-261: Explicitly require peer review before merge.Consider adding a line in the Review Approach or a checklist item stating merges should not occur without a peer review. Based on learnings: Encourage peer code reviews to ensure consistency, catch errors, and improve code quality. No merges without a review.
.cursor/rules/team-review.mdc (1)
221-237: Add an explicit “no merge without review” item.Recommend adding a checklist item under “After Review” (or “Before”) requiring peer review approval prior to merge. Based on learnings: Encourage peer code reviews to ensure consistency, catch errors, and improve code quality. No merges without a review.
.cursor/rules/workflows/pr-preparation.mdc (1)
210-262: Add an explicit “main PR comment” instruction with required link/context details.The workflow covers links and demo artifacts but doesn’t explicitly instruct a main PR comment explaining referenced links/Jira/docs, use cases, and current/required state. Consider adding a short checklist item or template note.
Based on learnings: “Add a main PR comment explaining referenced links, Jira, doc, use cases, and current/required state. When there are visual changes, add videos and/or screenshots.”
|
I read that all and for me its great |
| // ❌ Split strings lose context | ||
| {t('Click')} {t('here')} {t('to continue')} | ||
|
|
||
| // ❌ Hardcoded strings |
There was a problem hiding this comment.
Maybe we can add a bad pattern for pluralization (and issue I have encountered last week with Cursor and also discussed with @adamviktora):
"{{count}} virtual machine are available_plural": "{{count}} virtual machine are available" will be translated into {{count}} virtual machine are availables
In this case we need to explicitly distinguish the plural / singular use cases via the code.
There was a problem hiding this comment.
@galkremer1 @adamviktora we have our custom scripts that do the magic and sometimes they get it wrong. Check
CC: @upalatucci
There was a problem hiding this comment.
Yes i suggest removing the script that does the pluralization in English and do it by ourselves or let cursor translate it. Only for the English as we can verify it. For other languages, we have human translators
There was a problem hiding this comment.
why not letting cursor write one working script? :)
But this can be done in a follow up , pr, Could one of oyu guys open a ticket for it?
avivtur
left a comment
avivtur
left a comment
There was a problem hiding this comment.
added some suggestions to improve
| - Template parameters and defaults | ||
| - Template validation rules | ||
| - Instance types and preferences | ||
|
|
.cursor/rules/agents/qe-agent.mdc
Outdated
| - User interactions work | ||
| - Accessibility requirements met | ||
|
|
||
| **Integration Test Coverage** |
There was a problem hiding this comment.
do we plan to add integration tests as well?
.cursor/rules/coding-standards.mdc
Outdated
| @@ -0,0 +1,245 @@ | |||
| --- | |||
| description: Coding standards and best practices for this project | |||
| alwaysApply: true | |||
There was a problem hiding this comment.
that means all files would be impacted? also config files? can we glob it?
There was a problem hiding this comment.
depend on which files it edits/adds. Can also be configs, but if nothing should be changed there, it won't change.
.cursor/rules/agents/ux-reviewer.mdc
Outdated
|
|
||
| # UX Reviewer Agent | ||
|
|
||
| Invoke with: *"as ux"*, *"review ux"*, *"accessibility review"*, *"a11y check"*, *"usability review"* |
There was a problem hiding this comment.
maybe we should use a consistent way to invoke each agent, something like review:ux or @ux this would make easier to remember if they all triggered the same.
I was also suggested by cursor as could be a conflict with built-in cursor prompts
There was a problem hiding this comment.
hmm we can add, i will let you add it in a follow up pr :) will give you some ability to play with it and extend it :)
|
|
||
| # Team Review Agent | ||
|
|
||
| When reviewing code or implementing features, automatically consider all team perspectives to ensure quality, usability, testability, and security. |
There was a problem hiding this comment.
I think it would be better if we can choose which agents to run, there are some PRs that won't need all agents that would be just an overkill something like team-review:all or team-review:dev,qe or just review:dev
There was a problem hiding this comment.
you can just promt it, " this is the tickect XXX , dont use team review but only qe review"
| - Handles cloning, importing, uploading | ||
| - Check DataVolume.status.phase for completion | ||
| - DataVolume creates and manages underlying PVC | ||
| - Boot order and disk attachment configuration |
rszwajko
left a comment
rszwajko
left a comment
There was a problem hiding this comment.
Very useful and interesting work! There are however some points that we need to address before wider adoption.
My concerns:
- we need explicit security guidelines regarding jira/gh MCP or cluster usage with
oc. - the instructions duplicate existing information from other sources (package.json, CODING_STANDARDS.md, etc) which will be impossible to maintain/sync in the long run
- some messages were not clear to me - I consider the instructions also valuable for onboarding/general knowledge sharing so they should be easy to follow.
- IMHO we should not expose test workflows to the agents when we have insufficient infrastructure
- it seems we are tight coupling with the Cursor ecosystem - how can we ensure that agent skills follow the open standards ( https://github.com/agentskills/agentskills)?
- some of the workflows are inherently downstream-only (i.e. jira) - maybe we should consider treating the entire configuration as optional and keep it in a separate repository? this way both personal and team-scope skills would be treated in the same way (ignored by git).
Note that:
- I was able to check only first part of the instructions (30%?)
- see also my comments in #3382
.cursor/rules/agents/developer.mdc
Outdated
|
|
||
| ### 3. React Patterns | ||
|
|
||
| **Hooks Best Practices** |
There was a problem hiding this comment.
the entire section lists/presents actually bad practices - where do we say that agent should actually NOT do those things?
.cursor/rules/agents/developer.mdc
Outdated
| - Wrong nullability (undefined vs null vs optional) | ||
| - Enum vs union type choices |
There was a problem hiding this comment.
unclear what's the recommended approach
.cursor/rules/agents/developer.mdc
Outdated
| - Overly complex generic types | ||
| - Missing discriminated unions for state | ||
| - Interface vs type inconsistency |
There was a problem hiding this comment.
unclear instructions - IMHO we should be explicit in our expectation
|
|
||
| --- | ||
|
|
||
| ### 4. TypeScript Quality |
There was a problem hiding this comment.
can we redirect to our eslint/prettier setup?
There was a problem hiding this comment.
TS quality is the right place for it? ESLint is mentioned in different places, such as coding standards
| - State updates causing cascade re-renders | ||
| - Missing Suspense boundaries | ||
|
|
||
| **Bundle Size** |
There was a problem hiding this comment.
we should also redirect here to console-extensions.md to explain plugin-specific bundle config (i.e. shared modules)
There was a problem hiding this comment.
not extensions but the plugin-sdk, shared modules, added
| **Component Usage** | ||
| - Using appropriate PatternFly components | ||
| - Not recreating existing components | ||
| - Consistent with OpenShift Console patterns | ||
| - Following PatternFly design guidelines | ||
|
|
||
| **Layout Patterns** | ||
| - Page structure consistent with console |
There was a problem hiding this comment.
We are re-directing to the Console patterns and PF guidelines without providing proper resources preferably local files in *.md format.
There was a problem hiding this comment.
Ive edit it with right links, its a lot of info i dont want ot include it locally as this proably only on new feauter is used, so agent can catch info then
|
|
||
| **Check Permissions** | ||
| - User has get/list/watch permissions | ||
| - Run: `oc auth can-i list virtualmachines` |
There was a problem hiding this comment.
- how we plan to separate bot-trafic on test clusters from human testing? i.e. I'm concerned about agents deleting a VM that I use for some dev work/testing. By convention we use named namespaces for that (i.e.
radek) - how to ensure that agent won't go wild on a prod env - we do sometimes log to such clusters.
There was a problem hiding this comment.
- ugo added something for NS
- we never have access to prod env. sometimes we might have access to customer testing clusters
| - **Jira MCP**: Ticket management, status updates | ||
| - **Playwright MCP**: Interactive testing | ||
| - **GitHub MCP**: PR creation (if enabled) |
There was a problem hiding this comment.
we should be explicit about risk involved with using those services:
- jira (as for now) doesn't support granular tokens so agent is operating with full permission - for admin roles this involves significant risk if the agent goes wild
- playwright which is e2e testing requires a backend - either we need separate clusters or we should remove those instructions as automated high traffic will block the environments
- GH supports granular tokens and it's recommended to limit the scope to the minimum (and secure the full permission token for authorized use only)
There was a problem hiding this comment.
Should we add this in a separate md file? With all the risks we can find?
There was a problem hiding this comment.
- i refer to this issue in the general answer about pr
- i dont see the issue here.
- same as 1.
rszwajko
requested review from
Pedro-S-Abreu,
adamviktora,
aviavissar,
avivtur,
batyana,
galkremer1,
gouyang,
pcbailey,
rszwajko,
sjd78 and
vojtechszocs
- typescript.mdc: fix 'Don\'t' typo (Never use any), add tsx to glob, clarify Don't section - coding-standards.mdc: scope with globs (src, cypress, tests) instead of alwaysApply - kubevirt-expert.mdc: add DataSources, Networks; k8sPatch test op; console-extensions ref - qe-agent.mdc: add integration tests note - team-review.mdc: document review:dev/ux/qe and team-review:all dev,qe; no merge without review - ux-reviewer.mdc: review:ux/@ux invocation; PatternFly + Coding Standards refs - developer.mdc: defer to Coding Standards, eslint ref, anti-patterns note, console-extensions, no merge without review - debugging.mdc: clarify investigation steps, Chrome DevTools MCP, safety/env (namespaces, prod) - feature-development.mdc: add MCP/agent risks (Jira, Playwright, GitHub) Co-authored-by: Cursor <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.cursor/rules/agents/developer.mdc:
- Line 198: The manifest references a non-existent documentation file
"console-extensions.md"; either add a new docs file named
"console-extensions.md" containing the plugin shared modules and bundle
configuration guidance referenced by the rule, or change the reference in
.cursor/rules/agents/developer.mdc to point to an existing documentation file
that covers plugin shared modules and bundle configuration (update the link
text/string "console-extensions.md" accordingly and ensure the referenced
document includes the required content).
🧹 Nitpick comments (3)
.cursor/rules/agents/developer.mdc (1)
106-106: Consider making anti-pattern warnings more prominent.The note at line 106 clarifies that sections 3–6 list anti-patterns to avoid, but this guidance appears only once between sections 2 and 3. Readers skimming directly to sections 4, 5, or 6 might miss this context and misinterpret the lists as recommended practices.
💡 Consider one of these options to improve clarity
Option 1: Add the anti-pattern clarification to each section header:
-### 3. React Patterns +### 3. React Patterns (Anti-patterns to Avoid)Option 2: Repeat a brief reminder at the start of each subsequent section:
### 4. TypeScript Quality +**Note:** The items below are anti-patterns. Flag these and advise against them. + **Type Safety**.cursor/rules/agents/qe-agent.mdc (1)
170-176: Consider referencing specific E2E testing tools.The E2E Test Coverage section mentions cross-browser testing and responsive design but doesn't specify which tools to use. Based on learnings, the project uses Cypress or Playwright for E2E testing. Adding an explicit reference would help align this document with established practices.
🔧 Suggested enhancement
**E2E Test Coverage** +- Use Playwright or Cypress for end-to-end testing - Critical user journeys covered - Happy path scenarios - Common error scenariosBased on learnings: Use Cypress or Playwright for end-to-end (E2E) testing with comprehensive UI coverage.
.cursor/rules/workflows/feature-development.mdc (1)
376-379: Security guidance for MCP integrations is valuable but could be more prominent.Lines 376-379 provide important security guidance about token permissions and usage limitations for Jira, Playwright, and GitHub MCPs. This is particularly critical for the Jira MCP recommendation to exclude
jira_delete_issueandjira_update_issuefrom the allowlist.However, this guidance appears late in the document (section 10 out of 10) and might be missed by users who skim or jump directly to specific phases.
💡 Consider making security guidance more discoverable
Option 1: Add a brief security callout earlier in the workflow overview (section 1):
## 1. Workflow Overview +> **⚠️ Security Note**: This workflow uses MCP integrations (Jira, Playwright, GitHub). +> See section 10 for important token permission and usage guidance. +┌─────────────────────────────────────────────────────────────┐
**Option 2**: Add inline security reminders in relevant phases: ```diff ### Get the Ticket"Start working on CNV-12345"
+> **Security**: Jira MCP uses your account permissions. Avoid granting admin roles. + I will:
rszwajko
dismissed
their stale review
the agent skills definitions have been updated
|
Check per lines comments in my review above. In general:
|
- Auto-trigger on Jira ticket URLs (start immediately, no confirmation) - Add todo tracking for agents and subtasks - Run Developer Agent first for implementation - Run review agents (UX, QE, Security, KubeVirt) sequentially - Prompt to implement recommendations after each agent - Add complete workflow documentation in Section 11 Co-authored-by: Cursor <[email protected]>
…erage - Merge CODING_STANDARDS.md into coding-standards.mdc (single source of truth) - Split team-review.mdc into lean always-apply core + on-demand ticket-workflow.mdc - Set common-commands.mdc to on-demand (alwaysApply: false) - Expand kubevirt-expert.mdc with 16+ missing resource types (DataSource, DataImportCron, MigrationPolicy, NNCP, HCO, etc.) - Fix developer.mdc: clarify anti-patterns, nullability, enums, bundle size, shared modules - Add design resource links to ux-reviewer.mdc (PatternFly, UXD Hub, WCAG) - Trim debugging.mdc, jira-workflow.mdc, reduce overlap with feature-development.mdc - Fix broken references (testing.mdc, AI_README.md, PR template) - Add port labels in playwright-testing.mdc ~80% reduction in always-injected context tokens. Co-authored-by: Cursor <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.cursor/rules/coding-standards.mdc (1)
255-267:⚠️ Potential issue | 🟡 MinorSection 10 appears incomplete.
The "AI-Specific Guidance" section ends abruptly at line 267 ("Ensure no
console.logor debug code is left in") without proper closure. Verify this section is complete or add any missing guidance.
🤖 Fix all issues with AI agents
In @.cursor/rules/workflows/jira-workflow.mdc:
- Around line 110-122: Add a "Security & Safe Operations" section to the MCP
tool reference that warns about destructive Jira operations and limits
recommended automation to create/fetch actions: explicitly mark jira_search and
jira_get_issue as read-only, jira_add_comment as safe, flag jira_add_worklog as
"use with care", and mark jira_transition_issue and jira_update_issue as "use
with caution" (review required), and state that jira_delete_issue must not be
allowlisted; align wording with feature-development.mdc and the PR objective
(metalice) to restrict Jira MCP to create/fetch operations and explain that Jira
tokens are broad and agents run with full account permissions.
In @.cursor/rules/workflows/playwright-testing.mdc:
- Around line 33-38: Insert an "Environment Considerations" warning block
immediately under the "## 2. Getting Started" / "### Prerequisites" section: add
a "### ⚠️ Environment Considerations" heading and the four bullet points
recommending dedicated test environments, limiting automation frequency,
checking cluster capacity, and coordinating with the team so readers know not to
run heavy browser automation on shared/staging/production clusters; ensure the
language mirrors the PR guidance about bot traffic blocking resources and
avoiding exposing test workflows to agents when infrastructure is limited.
🧹 Nitpick comments (5)
.cursor/rules/coding-standards.mdc (1)
40-42: Consider clarifying or relaxing the 150-line file size limit.The strict 150-line maximum may be impractical for legitimate complex components (e.g., comprehensive forms, feature-rich tables, multi-step wizards with validation). This could force artificial splitting that reduces cohesion.
Consider:
- Adding exceptions for specific cases (e.g., "excluding type definitions and constants")
- Raising to 200-250 lines as a soft guideline rather than a hard limit
- Clarifying this is a guideline, not a blocker
.cursor/rules/workflows/playwright-testing.mdc (1)
242-262: Add resource cleanup guidance to testing workflows.The VM creation and action workflows don't mention cleanup. Automated testing that creates resources without cleanup can exhaust cluster capacity, especially on shared test environments.
Add cleanup steps:
### Cleanup After Testing "Delete the test VM after verification" "Clean up test resources created during this session".cursor/rules/workflows/feature-development.mdc (1)
376-379: Good security guidance, but consider making it more prominent.The security guidance addresses key concerns from PR feedback (Jira token scope, Playwright infrastructure impact, GitHub permissions). However:
- This guidance is buried in section 10 - consider moving it to section 1 (Workflow Overview) or creating a dedicated security section at the top
- Add guidance for
occluster access mentioned in PR feedback:- **oc/kubectl**: Use dedicated test clusters with limited RBAC; never use production credentials for automation.cursor/rules/workflows/ticket-workflow.mdc (1)
14-23: Add reference to MCP security guidance.This workflow orchestrates automated Jira operations but doesn't reference security considerations. Add a note referencing the security guidance:
**Security Note**: When working with Jira tickets, follow MCP security guidelines in `feature-development.mdc` section 10. Use limited-permission tokens and restrict to create/fetch operations..cursor/rules/workflows/jira-workflow.mdc (1)
126-133: Consider adding security best practice to tips.Add a tip about safe Jira operations:
- Limit automation to read and comment operations; review before modifying ticketsThis reinforces the security guidance and promotes safe usage patterns.
| ## 5. MCP Tool Reference | ||
|
|
||
| | Tool | Purpose | | ||
| |------|---------| | ||
| | `jira_search` | Find tickets with JQL | | ||
| | `jira_get_issue` | Get ticket details | | ||
| | `jira_add_comment` | Add comments | | ||
| | `jira_transition_issue` | Change status | | ||
| | `jira_add_worklog` | Log time | | ||
| | `jira_update_issue` | Update fields | | ||
| | `jira_get_sprint_issues` | Get sprint issues | | ||
|
|
||
| Tools are called automatically when you make requests. Just describe what you want in natural language. |
There was a problem hiding this comment.
Add security guidance for Jira MCP operations.
The tool reference lists all operations including jira_update_issue and jira_transition_issue without security warnings. Per feature-development.mdc, Jira MCP should be limited to create/fetch operations to prevent mistakes or misuse.
Add a security section:
## Security & Safe Operations
⚠️ **Recommended Safe Operations**:
- ✅ `jira_search` - Find tickets (read-only)
- ✅ `jira_get_issue` - Get details (read-only)
- ✅ `jira_add_comment` - Add comments (safe)
- ⚠️ `jira_add_worklog` - Log time (use with care)
⚠️ **Use With Caution**:
- ⚠️ `jira_transition_issue` - Changes status (review required)
- ⚠️ `jira_update_issue` - Modifies fields (review required)
❌ **Not Recommended for Automation**:
- Do not add `jira_delete_issue` to allowlist
- Limit automation to minimize impact of errors
**Rationale**: Jira tokens are not granular; agents run with full account permissions. Limiting to create/fetch operations reduces risk.Based on PR objectives: metalice requested "explicit security guidelines for Jira/GitHub MCP" and feature-development.mdc includes guidance to "Use the Jira MCP only to create and fetch tickets; do not use it to delete or modify existing tickets."
🤖 Prompt for AI Agents
In @.cursor/rules/workflows/jira-workflow.mdc around lines 110 - 122, Add a
"Security & Safe Operations" section to the MCP tool reference that warns about
destructive Jira operations and limits recommended automation to create/fetch
actions: explicitly mark jira_search and jira_get_issue as read-only,
jira_add_comment as safe, flag jira_add_worklog as "use with care", and mark
jira_transition_issue and jira_update_issue as "use with caution" (review
required), and state that jira_delete_issue must not be allowlisted; align
wording with feature-development.mdc and the PR objective (metalice) to restrict
Jira MCP to create/fetch operations and explain that Jira tokens are broad and
agents run with full account permissions.
| ## 2. Getting Started | ||
|
|
||
| ### Prerequisites | ||
| - Development server running: `npm run dev` (port 9001) | ||
| - Console running: `npm run start-console` (port 9000) | ||
| - Or a deployed environment URL |
There was a problem hiding this comment.
Add infrastructure impact and environment selection warnings.
The prerequisites don't warn about infrastructure impact from automated browser testing. Per PR feedback, bot traffic on shared test clusters can block resources.
Add warnings:
### ⚠️ Environment Considerations
- **Use dedicated test environments** - avoid shared staging/production
- **Limit automation frequency** - manual verification, not CI loops
- **Check cluster capacity** - ensure sufficient resources before heavy testing
- **Coordinate with team** - communicate when running extensive test sessionsBased on PR objectives: rszwajko warned "Bot traffic on test clusters could block resources; warns about exposing test workflows to agents when infrastructure is limited" and metalice stated "Prefer not exposing test workflows to agents if infrastructure is insufficient."
🤖 Prompt for AI Agents
In @.cursor/rules/workflows/playwright-testing.mdc around lines 33 - 38, Insert
an "Environment Considerations" warning block immediately under the "## 2.
Getting Started" / "### Prerequisites" section: add a "### ⚠️ Environment
Considerations" heading and the four bullet points recommending dedicated test
environments, limiting automation frequency, checking cluster capacity, and
coordinating with the team so readers know not to run heavy browser automation
on shared/staging/production clusters; ensure the language mirrors the PR
guidance about bot traffic blocking resources and avoiding exposing test
workflows to agents when infrastructure is limited.
| - Internal implementation details exposed | ||
| - Inconsistent folder structure | ||
|
|
||
| **Note:** Sections 3–6 below list **anti-patterns and bad practices**. Flag these and advise the author **not** to do them; do not suggest or generate code that follows these patterns. |
There was a problem hiding this comment.
Are we sure the AI understands this? Or maybe take just part of this document and think some of those chapters are describing best practices?
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: metalice, upalatucci The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
openshift-merge-bot
bot
merged commit 7acd7f2
into
kubevirt-ui:main
5 participants
Description
Adds a comprehensive set of Cursor AI rules to provide consistent, project-aware coding assistance across the team. Also consolidates
CODING_STANDARDS.mdinto the cursor rules as the single source of truth.What's Included
Core Rules (Always Active)
project-contextcoding-standardsCODING_STANDARDS.md)team-reviewFile-Specific Rules (Activate When Relevant Files Open)
react-components*.tsxtypescript*.tstesting*.test.ts,cypress/**styles*.scssi18nlocales/**Agent Personas (Deep-Dive Reviews)
developerux-reviewerqe-agentsecurity-reviewerkubevirt-expertWorkflows (On-Demand)
common-commandsnew-componentpr-preparationdebuggingjira-workflowticket-workflowplaywright-testingfeature-developmentKey Design Decisions
Context Efficiency
alwaysApply: true(project-context, coding-standards, team-review) -- everything else is on-demandcommon-commandsmoved from always-apply to on-demand to save tokensteam-reviewsplit into lean core (123 lines) + separateticket-workflowfor detailed agent trackingSingle Source of Truth
CODING_STANDARDS.mdfrom project root -- all coding standards now live incoding-standards.mdccoding-standards.mdcSection 8, referenced bypr-preparation.mdcAccuracy Over Assumptions
kubevirt-expert.mdcexpanded with all 20+ resource types actually used in the codebase (DataSource, DataImportCron, MigrationPolicy, NNCP, HCO, StorageProfile, etc.)developer.mdcdocuments actual project conventions (string enums,undefinedovernull,typeoverinterface)ux-reviewer.mdcincludes real links to PatternFly 6, UXD Design Hub, WCAG, and virtualization design team contactsFile Structure
Links
Test Plan
npm run check-typespassesnpm run lintpasses (no new warnings)