🔧 AI Rules and Agents - #634
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 55 minutes and 4 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds onboarding docs, Cursor configuration, multiple Cursor agent prompts, and coding/workflow rule files for the OSIM Vue 3 frontend; plus AI assistant guideline documents and a short Claude-specific guideline. All changes are documentation/configuration only. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 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}
There was a problem hiding this comment.
🧹 Nitpick comments (5)
.cursor/agents/feature-scaffolder.md (1)
37-37: Consider clarifying that the composable pattern is structural, not prescriptive.Line 37 describes composables as returning
{ data, isLoading, error, actions }, but actual codebase composables (e.g.,useFetchFlaw.ts) use more descriptive, context-specific names. While the agent instructions (lines 11-16) correctly tell it to read and match existing patterns, the generic pattern here might be misread as a naming prescription.💡 Suggested clarification
-- Composables return `{ data, isLoading, error, actions }` pattern +- Composables return state + actions (e.g., `{ flaw, isFetching, fetchFlaw }`) — match existing naming🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/agents/feature-scaffolder.md at line 37, The doc currently states composables return a `{ data, isLoading, error, actions }` pattern which can be misread as a naming prescription; update the wording in .cursor/agents/feature-scaffolder.md to clarify this is a structural example only (not a required naming convention) and reference that existing composables like useFetchFlaw.ts may use more descriptive, context-specific names—adjust the sentence to say "structure/example" and add a short note telling agents to follow the codebase's existing names when scaffolding..cursor/agents/code-reviewer.md (4)
31-34: Consider softening the function length guideline.The 40-line limit for functions is a reasonable heuristic for encouraging focused, maintainable code. However, some functions legitimately need to be longer (e.g., complex business logic with necessary steps). Consider phrasing this as a guideline rather than a hard rule to allow for justified exceptions.
📝 Optional: Soften the function length guideline
**Code quality** -- Functions are focused and <40 lines +- Functions are focused and typically <40 lines (flag longer functions for possible refactoring) - Error states handled (not swallowed) - Loading states reflected in UI🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/agents/code-reviewer.md around lines 31 - 34, Update the hard rule "Functions are focused and <40 lines" to a softer guideline (e.g., "Prefer functions <40 lines; allow justified exceptions for complex business logic with clear rationale") so reviewers can accept longer functions when warranted; locate and modify the guideline text "Functions are focused and <40 lines" in the code-review checklist to reflect the new phrasing and add a short note about documenting justification for exceptions.
8-12: Consider documenting the rationale for skipping automated checks.The instruction to skip
yarn type-check,yarn lint, and tests unless explicitly requested is clear and aligns with the "implement-first, validate-on-request" pattern mentioned in the PR. However, this trade-off (faster reviews vs. potential missed issues from static analysis) might not be immediately obvious to new team members.📝 Optional: Add a brief rationale comment
## When invoked 1. Run `git diff HEAD` to see recent changes 2. Focus review on modified `.vue`, `.ts` files -3. **Do NOT run** `yarn type-check`, `yarn lint`, or tests — only run these when the user explicitly asks +3. **Do NOT run** `yarn type-check`, `yarn lint`, or tests — only run these when the user explicitly asks + - Rationale: Focus on architectural/logical review; developer runs validation tools separately🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/agents/code-reviewer.md around lines 8 - 12, Add a brief rationale next to the "Do NOT run `yarn type-check`, `yarn lint`, or tests" guidance under the "When invoked" section: explain that skipping automated checks speeds up iterative/implement-first reviews and prevents CI noise, but note the trade-off that static/type/lint issues may be missed and recommend requesting those checks when ready; update the adjacent bullet or add a one-sentence parenthetical so future reviewers see why this rule exists.
16-19: Consider clarifying fallback for OpenAPI client edge cases.The requirement to use the generated OpenAPI client from
@/generated/is excellent practice and aligns with the codebase patterns. However, the agent doesn't provide guidance for edge cases (e.g., new endpoints not yet in the OpenAPI spec, or issues with code generation).📝 Optional: Add guidance for OpenAPI client edge cases
**TypeScript safety** - No `any`; proper use of `unknown` + type guards - Zod schemas used for API response validation (`ZodFlaw*` types) -- Generated OpenAPI client used — no hand-rolled fetch calls +- Generated OpenAPI client used from `@/generated/` — no hand-rolled fetch calls + - If endpoint missing from generated client, update OpenAPI spec first🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/agents/code-reviewer.md around lines 16 - 19, Clarify fallback guidance for using the generated OpenAPI client from "@/generated/" by adding concrete steps: when an endpoint is missing or generation fails, first update the OpenAPI spec and re-run the generator; if that’s not immediately possible, implement a small typed fallback using fetch + Zod validation (reusing existing Zod schemas like ZodFlaw* or creating a temporary Zod schema) and wrap it in the same call-signature as the generated client so callers (and tests) remain unchanged; ensure the fallback logs a clear warning/error and includes a TODO comment referencing regeneration, and add tests for both the generated client path and the fallback path so behavior is covered until the generator is fixed.
36-43: Consider adding guidance for empty diff or no-issues case.The output format is well-structured with clear severity levels and requirements for file references. However, it doesn't specify what the agent should output when the diff is empty or when no issues are found. Adding this guidance would make the agent's behavior more predictable.
📝 Optional: Add guidance for no-issues scenario
## Output format Organize feedback as: - 🔴 **Critical** — must fix before merge - 🟡 **Suggestion** — should address - 🟢 **Minor** — optional improvement Include specific file + line reference and a concrete fix for each 🔴 item. + +If no issues found, respond with: "✅ No issues found in the reviewed changes."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/agents/code-reviewer.md around lines 36 - 43, The "## Output format" section lacks guidance for an empty diff or no-issues result; update the "## Output format" block (the header and its bullet list) to include a clear rule for no-issues/empty-diff cases—for example add a bullet or subheading that instructs the agent to output a single line like "🟢 No issues found" (or similar) and to still return the standard structure (severity headers) with a short confirmation message and no file refs; ensure the new text is concise and consistent with the existing severity labels so the agent's behavior is deterministic when no findings are present.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.cursor/agents/code-reviewer.md:
- Around line 31-34: Update the hard rule "Functions are focused and <40 lines"
to a softer guideline (e.g., "Prefer functions <40 lines; allow justified
exceptions for complex business logic with clear rationale") so reviewers can
accept longer functions when warranted; locate and modify the guideline text
"Functions are focused and <40 lines" in the code-review checklist to reflect
the new phrasing and add a short note about documenting justification for
exceptions.
- Around line 8-12: Add a brief rationale next to the "Do NOT run `yarn
type-check`, `yarn lint`, or tests" guidance under the "When invoked" section:
explain that skipping automated checks speeds up iterative/implement-first
reviews and prevents CI noise, but note the trade-off that static/type/lint
issues may be missed and recommend requesting those checks when ready; update
the adjacent bullet or add a one-sentence parenthetical so future reviewers see
why this rule exists.
- Around line 16-19: Clarify fallback guidance for using the generated OpenAPI
client from "@/generated/" by adding concrete steps: when an endpoint is missing
or generation fails, first update the OpenAPI spec and re-run the generator; if
that’s not immediately possible, implement a small typed fallback using fetch +
Zod validation (reusing existing Zod schemas like ZodFlaw* or creating a
temporary Zod schema) and wrap it in the same call-signature as the generated
client so callers (and tests) remain unchanged; ensure the fallback logs a clear
warning/error and includes a TODO comment referencing regeneration, and add
tests for both the generated client path and the fallback path so behavior is
covered until the generator is fixed.
- Around line 36-43: The "## Output format" section lacks guidance for an empty
diff or no-issues result; update the "## Output format" block (the header and
its bullet list) to include a clear rule for no-issues/empty-diff cases—for
example add a bullet or subheading that instructs the agent to output a single
line like "🟢 No issues found" (or similar) and to still return the standard
structure (severity headers) with a short confirmation message and no file refs;
ensure the new text is concise and consistent with the existing severity labels
so the agent's behavior is deterministic when no findings are present.
In @.cursor/agents/feature-scaffolder.md:
- Line 37: The doc currently states composables return a `{ data, isLoading,
error, actions }` pattern which can be misread as a naming prescription; update
the wording in .cursor/agents/feature-scaffolder.md to clarify this is a
structural example only (not a required naming convention) and reference that
existing composables like useFetchFlaw.ts may use more descriptive,
context-specific names—adjust the sentence to say "structure/example" and add a
short note telling agents to follow the codebase's existing names when
scaffolding.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ec292286-f2ad-41c6-80e7-aa3e70a925ab
📒 Files selected for processing (9)
.cursor/ONBOARDING.md.cursor/README.md.cursor/agents/code-reviewer.md.cursor/agents/feature-scaffolder.md.cursor/agents/pr-description.md.cursor/rules/git-workflow.mdc.cursor/rules/vue-typescript.mdcAI_GUIDELINES.mdCLAUDE.md
|
It looks like a great idea. I like for all our projects 😃 |
|
Using CLAUDE to review this it recommends this improvements. Weaknesses / Areas to Improve 🟡 Duplication between files
🟡 Agent boundaries could be clearer
🟡 Missing validation
🟡 Onboarding assumptions
|
Made-with: Cursor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.cursor/README.md (2)
97-105: Add an explicit confirmation gate before push/PR actionsLines 103–105 perform high-impact GitHub actions. Add a required confirmation step before pushing/opening PR to reduce accidental release automation.
Suggested safeguard
6. Commits with `🔖 release v{YYYY.M.Z}` -7. Pushes branch and opens a PR with label `Internal`, reviewers `osim-devs`, and the release changelog as description +7. Shows a summary of planned changes and asks for explicit confirmation +8. Pushes branch and opens a PR with label `Internal`, reviewers `osim-devs`, and the release changelog as description🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/README.md around lines 97 - 105, The release workflow currently performs high-impact actions in steps "Pushes branch" and "opens a PR" (steps 6–7) without a confirmation; add an explicit interactive confirmation gate before executing the push and PR creation so the user must approve the final release details. Modify the script/README instructions around the "Commits with `🔖 release v{YYYY.M.Z}`", "Pushes branch" and "opens a PR" steps to prompt for and validate a yes/no confirmation (or require typing the release version) and abort if not confirmed, and document the new confirmation requirement in the README.
51-53: Make file-selection heuristics deterministic forfeature-scaffolderLine 51 is too open-ended (“Reads 2–3 similar existing files”), which can cause inconsistent scaffolds. Add explicit selection rules (same directory/module, same pattern, most recently modified, etc.).
Suggested enhancement
-1. Reads 2–3 similar existing files to match conventions +1. Reads 2–3 similar existing files using this order: + - same feature/module directory first + - same artifact type (component/composable/service) + - most recently modified files when multiple matches exist🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/README.md around lines 51 - 53, The README line describing "Reads 2–3 similar existing files" is ambiguous; update the feature-scaffolder's file-selection logic and README to use deterministic rules: select candidates from the same directory/module and matching filename patterns (e.g., component, composable, service, Zod type names related to <Name>), rank by most-recently-modified and pick the top 3, and use a stable lexical tie-breaker if timestamps match; if no matches, fall back to a defined pattern-based default list. Apply this change to the feature-scaffolder file-selection routine and update the documentation near the Generated files list (components/<Name>/<Name>.vue, composables/use<Name>Model.ts, optional service + Zod type) to describe the exact selection rules and fallback behavior.
🤖 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/README.md:
- Around line 23-27: The fenced code blocks in the README that show example
snippets for "Review my changes to CommentList.vue and useFlawCommentFilter.ts"
and other examples (blocks around the quoted ranges: the initial snippet and the
blocks at 43-47, 63-68, 71-81, 90-95, 110-127) are missing language identifiers;
update each triple-backtick fence to include an appropriate language tag (e.g.,
```text, ```md, or ```bash) so the markdown linter (MD040) is satisfied and the
snippets clearly indicate their language/context.
- Line 3: The README line "Local-only config (not tracked by git)." is
misleading because the file is actually committed; update that sentence in
.cursor/README.md to accurately describe its tracking and purpose (for example:
"Local-focused config — committed to the repo but intended for local/SDLC use;
override per-environment as needed") so onboarding readers aren't confused;
ensure the edited sentence preserves the note about covering the full SDLC for
the osim Vue 3 frontend and uses neutral phrasing like "committed but intended
for local/SDLC use" or "local-focused, tracked in repo" to clarify intent.
---
Nitpick comments:
In @.cursor/README.md:
- Around line 97-105: The release workflow currently performs high-impact
actions in steps "Pushes branch" and "opens a PR" (steps 6–7) without a
confirmation; add an explicit interactive confirmation gate before executing the
push and PR creation so the user must approve the final release details. Modify
the script/README instructions around the "Commits with `🔖 release
v{YYYY.M.Z}`", "Pushes branch" and "opens a PR" steps to prompt for and validate
a yes/no confirmation (or require typing the release version) and abort if not
confirmed, and document the new confirmation requirement in the README.
- Around line 51-53: The README line describing "Reads 2–3 similar existing
files" is ambiguous; update the feature-scaffolder's file-selection logic and
README to use deterministic rules: select candidates from the same
directory/module and matching filename patterns (e.g., component, composable,
service, Zod type names related to <Name>), rank by most-recently-modified and
pick the top 3, and use a stable lexical tie-breaker if timestamps match; if no
matches, fall back to a defined pattern-based default list. Apply this change to
the feature-scaffolder file-selection routine and update the documentation near
the Generated files list (components/<Name>/<Name>.vue,
composables/use<Name>Model.ts, optional service + Zod type) to describe the
exact selection rules and fallback behavior.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9d4ee477-ad9b-4254-8cbb-ed292e8a3544
📒 Files selected for processing (1)
.cursor/README.md
| @@ -0,0 +1,140 @@ | |||
| # Cursor Agentic Config — osim | |||
|
|
|||
| Local-only config (not tracked by git). Covers the full SDLC for the osim Vue 3 frontend. | |||
There was a problem hiding this comment.
Fix misleading git-tracking statement
Line 3 says this config is “not tracked by git,” but this file is committed in the repo. Please reword to avoid onboarding confusion.
Suggested wording
-Local-only config (not tracked by git). Covers the full SDLC for the osim Vue 3 frontend.
+Cursor-focused config and usage guide for the osim Vue 3 frontend.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Local-only config (not tracked by git). Covers the full SDLC for the osim Vue 3 frontend. | |
| Cursor-focused config and usage guide for the osim Vue 3 frontend. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.cursor/README.md at line 3, The README line "Local-only config (not tracked
by git)." is misleading because the file is actually committed; update that
sentence in .cursor/README.md to accurately describe its tracking and purpose
(for example: "Local-focused config — committed to the repo but intended for
local/SDLC use; override per-environment as needed") so onboarding readers
aren't confused; ensure the edited sentence preserves the note about covering
the full SDLC for the osim Vue 3 frontend and uses neutral phrasing like
"committed but intended for local/SDLC use" or "local-focused, tracked in repo"
to clarify intent.
| ``` | ||
| Review my changes to CommentList.vue and useFlawCommentFilter.ts | ||
| ``` | ||
| ``` | ||
| @code-reviewer — what issues do you see in the flaw form changes? |
There was a problem hiding this comment.
Add language identifiers to fenced code blocks
Markdown lint warnings (MD040) are valid here. Add explicit fence languages (text, md, bash) to keep docs lint-clean.
Example fix pattern
-```
+```text
Review my changes to CommentList.vue and useFlawCommentFilter.ts
Apply the same pattern to each affected fenced block.
</details>
Also applies to: 43-47, 63-68, 71-81, 90-95, 110-127
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.0)</summary>
[warning] 23-23: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
[warning] 26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against the current code and only fix it if needed.
In @.cursor/README.md around lines 23 - 27, The fenced code blocks in the README
that show example snippets for "Review my changes to CommentList.vue and
useFlawCommentFilter.ts" and other examples (blocks around the quoted ranges:
the initial snippet and the blocks at 43-47, 63-68, 71-81, 90-95, 110-127) are
missing language identifiers; update each triple-backtick fence to include an
appropriate language tag (e.g., text, md, or ```bash) so the markdown
linter (MD040) is satisfied and the snippets clearly indicate their
language/context.
</details>
<!-- fingerprinting:phantom:triton:hawk:da776b53-e5db-47a5-b3c1-66d44523a883 -->
<!-- This is an auto-generated comment by CodeRabbit -->
Made-with: Cursor
2 participants
Summary:
Establishes a shared Cursor agentic development config for the osim team, covering rules, AI agents, and public guidelines for all AI tools.
Changes:
release-manageragent for automated release branch preparationConsiderations:
.cursor/is Cursor-specific — no impact on devs not using Cursorrelease-managerautomates: version derivation, branch creation, CHANGELOG update, misplaced entry check, commit, push, and PR creation withInternallabel andosim-devsreviewers