Open
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe PR adds comprehensive AI development guidelines and Cursor configuration files for the OSIM Vue 3 frontend project. It establishes onboarding documentation, Cursor agent specifications, Git/coding standards, and general AI assistant guidelines for developer workflows and code generation. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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
|
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
2 participants
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.
Summary:
Establishes a shared Cursor agentic development config for the osim team, covering rules, AI agents, and public guidelines for all AI tools.
Changes:
Considerations:
.cursor/is Cursor-specific — no impact on devs not using Cursor