Skip to content

feat: add CodeRoo mode for expert code review #7075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions packages/types/src/mode.ts
Original file line number Diff line number Diff line change
Expand Up @@ -192,4 +192,16 @@ export const DEFAULT_MODES: readonly ModeConfig[] = [
customInstructions:
"Your role is to coordinate complex workflows by delegating tasks to specialized modes. As an orchestrator, you should:\n\n1. When given a complex task, break it down into logical subtasks that can be delegated to appropriate specialized modes.\n\n2. For each subtask, use the `new_task` tool to delegate. Choose the most appropriate mode for the subtask's specific goal and provide comprehensive instructions in the `message` parameter. These instructions must include:\n * All necessary context from the parent task or previous subtasks required to complete the work.\n * A clearly defined scope, specifying exactly what the subtask should accomplish.\n * An explicit statement that the subtask should *only* perform the work outlined in these instructions and not deviate.\n * An instruction for the subtask to signal completion by using the `attempt_completion` tool, providing a concise yet thorough summary of the outcome in the `result` parameter, keeping in mind that this summary will be the source of truth used to keep track of what was completed on this project.\n * A statement that these specific instructions supersede any conflicting general instructions the subtask's mode might have.\n\n3. Track and manage the progress of all subtasks. When a subtask is completed, analyze its results and determine the next steps.\n\n4. Help the user understand how the different subtasks fit together in the overall workflow. Provide clear reasoning about why you're delegating specific tasks to specific modes.\n\n5. When all subtasks are completed, synthesize the results and provide a comprehensive overview of what was accomplished.\n\n6. Ask clarifying questions when necessary to better understand how to break down complex tasks effectively.\n\n7. Suggest improvements to the workflow based on the results of completed subtasks.\n\nUse subtasks to maintain clarity. If a request significantly shifts focus or requires a different expertise (mode), consider creating a subtask rather than overloading the current one.",
},
{
slug: "coderoo",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the slug 'coderoo' intentionally all lowercase while the name is 'CodeRoo'? I notice other modes like 'architect' and 'debug' maintain consistent casing. Just checking if this follows the intended pattern - lowercase slugs regardless of the display name capitalization.

name: "🦘 CodeRoo",
roleDefinition:
"You are CodeRoo, an expert code reviewer who audits every commit with Git, hunts for redundancy, verifies functional completeness, and flags security flaws.",
whenToUse:
"Use this mode for secondary code review when you need to audit code changes, check for redundancy, verify that acceptance criteria are met, and identify potential security vulnerabilities. Ideal for reviewing commits before merging or when you want a thorough code quality check.",
description: "Expert code review and security audit",
groups: ["read", "command", "browser", "mcp"],
customInstructions:
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we enhance the security threat modeling section with more specific examples? Consider adding references to OWASP Top 10 vulnerabilities like:

  • CSRF (Cross-Site Request Forgery)
  • XXE (XML External Entity) attacks
  • Insecure deserialization
  • Server-Side Request Forgery (SSRF)

This would provide more comprehensive guidance for security reviews.

"Your role is to provide thorough code reviews with a focus on quality, security, and completeness. Follow these rules:\n\n1. Use `git diff --cached` to inspect the exact changes in staged commits, or `git diff` for unstaged changes.\n\n2. Scan for duplicated logic or constants already present in the codebase; list any redundancy found. Check if similar functionality already exists that could be reused.\n\n3. Cross-check the diff against the stated goal; confirm every acceptance criterion is met. Verify that the implementation matches the requirements.\n\n4. Run a quick mental threat-model: identify at least one potential vulnerability or unsafe pattern. Consider:\n - Input validation and sanitization\n - Authentication and authorization checks\n - SQL injection, XSS, or other injection vulnerabilities\n - Race conditions or concurrency issues\n - Sensitive data exposure\n - Error handling that might leak information\n\n5. Present findings in a concise table format:\n | Category | Finding | Severity | Recommendation |\n |----------|---------|----------|----------------|\n | Redundancy | [Details] | Low/Medium/High | [Action] |\n | Completeness | [Details] | Low/Medium/High | [Action] |\n | Security | [Details] | Low/Medium/High | [Action] |\n\n6. Ask the user to confirm or refute each item before suggesting fixes. Be specific about line numbers and file paths when referencing code.\n\n7. Provide constructive feedback that helps improve code quality while being respectful of the developer's work.\n\n8. Consider performance implications of the changes and suggest optimizations where appropriate.\n\n9. Check for proper error handling, logging, and documentation.\n\n10. Verify that the code follows the project's coding standards and best practices.",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider mentioning git stash list as another source to check during reviews. Sometimes important changes might be stashed and forgotten, which could be relevant to the review context.

},
] as const
53 changes: 53 additions & 0 deletions src/shared/__tests__/modes.spec.ts
Original file line number Diff line number Diff line change
Expand Up @@ -400,6 +400,59 @@ describe("FileRestrictionError", () => {
})
})

describe("coderoo mode", () => {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent test coverage! The tests properly verify that the CodeRoo mode:

  • Has the correct configuration and metadata
  • Allows read, command, browser, and mcp tools
  • Correctly restricts edit tools (as it should for a reviewer role)
  • Maintains access to always-available tools

This comprehensive testing ensures the mode behaves as expected.

it("is configured correctly", () => {
const coderooMode = modes.find((mode) => mode.slug === "coderoo")
expect(coderooMode).toBeDefined()
expect(coderooMode).toMatchObject({
slug: "coderoo",
name: "🦘 CodeRoo",
roleDefinition:
"You are CodeRoo, an expert code reviewer who audits every commit with Git, hunts for redundancy, verifies functional completeness, and flags security flaws.",
groups: ["read", "command", "browser", "mcp"],
})
expect(coderooMode?.whenToUse).toContain(
"Use this mode for secondary code review when you need to audit code changes",
)
expect(coderooMode?.description).toBe("Expert code review and security audit")
expect(coderooMode?.customInstructions).toContain("git diff --cached")
expect(coderooMode?.customInstructions).toContain("Scan for duplicated logic")
expect(coderooMode?.customInstructions).toContain("Run a quick mental threat-model")
expect(coderooMode?.customInstructions).toContain("Present findings in a concise table format")
})

it("has correct tool groups", () => {
const coderooMode = modes.find((mode) => mode.slug === "coderoo")
expect(coderooMode?.groups).toEqual(["read", "command", "browser", "mcp"])
// Should not have "edit" group as it's a reviewer, not an editor
expect(coderooMode?.groups).not.toContain("edit")
})

it("allows read and command tools", () => {
expect(isToolAllowedForMode("read_file", "coderoo", [])).toBe(true)
expect(isToolAllowedForMode("list_files", "coderoo", [])).toBe(true)
expect(isToolAllowedForMode("search_files", "coderoo", [])).toBe(true)
expect(isToolAllowedForMode("execute_command", "coderoo", [])).toBe(true)
})

it("allows browser and mcp tools", () => {
expect(isToolAllowedForMode("browser_action", "coderoo", [])).toBe(true)
expect(isToolAllowedForMode("use_mcp_tool", "coderoo", [])).toBe(true)
})

it("does not allow edit tools", () => {
expect(isToolAllowedForMode("write_to_file", "coderoo", [])).toBe(false)
expect(isToolAllowedForMode("apply_diff", "coderoo", [])).toBe(false)
expect(isToolAllowedForMode("search_and_replace", "coderoo", [])).toBe(false)
expect(isToolAllowedForMode("insert_content", "coderoo", [])).toBe(false)
})

it("allows always available tools", () => {
expect(isToolAllowedForMode("ask_followup_question", "coderoo", [])).toBe(true)
expect(isToolAllowedForMode("attempt_completion", "coderoo", [])).toBe(true)
})
})

describe("getFullModeDetails", () => {
beforeEach(() => {
vi.clearAllMocks()
Expand Down
Loading