docs: Update custom modes documentation and add new interface image

[hannesrudolph]

Important

Updates custom-modes.md to simplify explanations, add a new interface image, and reorganize content for clarity.

• Documentation Update:
  • Simplifies explanation of custom modes in custom-modes.md.
  • Adds new interface image custom-modes-1.png.
  • Removes redundant sections about mode-specific instruction file locations.
• Content Reorganization:
  • Consolidates information on creating and configuring custom modes.
  • Clarifies JSON property details and regex usage for file restrictions.
  • Provides example configurations for common use cases.

^{This description was created by for 2f96ea2. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
roo-code-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 12, 2025 10:00pm

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 2f96ea2 in 2 minutes and 25 seconds. Click for details.

• Reviewed 449 lines of code in 1 files
• Skipped 1 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. docs/features/custom-modes.md:5

• Draft comment:
  Admonition syntax: Consider using three colons (e.g. :::tip) instead of four. Verify that your Markdown parser supports the quadruple-colon syntax used here.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 50% <= threshold 50% The comment suggests a change in syntax for Markdown admonitions and asks the author to verify parser support. This is a specific suggestion related to code style and syntax, which aligns with the rules for making code suggestions. However, the part about verifying parser support is asking the author to double-check something, which is against the rules.

2. docs/features/custom-modes.md:294

• Draft comment:
  The negative lookahead regex example seems incorrect. It likely should allow preceding characters (e.g. using '.*' after the negative lookahead) so filenames like 'app.js' match.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The current pattern ^(?!.*(test|spec))\.(js|ts)$ starts with ^ (beginning of string), then has a negative lookahead to exclude anything containing test/spec, then matches .js or .ts at the end. This pattern would correctly match app.js and utils.ts while excluding test files. The commenter suggests adding .* but that's not necessary since the negative lookahead already allows for any characters before the extension. Could there be edge cases where the current pattern fails that I haven't considered? Should I test the pattern with more complex file paths? After considering edge cases, the current pattern correctly handles both simple and complex paths. The negative lookahead (?!.*(test|spec)) already allows for any characters before the extension while ensuring "test" or "spec" don't appear anywhere in the path. The regex pattern in the documentation is actually correct as-is. It properly matches the intended files and excludes test files.

3. docs/features/custom-modes.md:5

• Draft comment:
  It appears that the admonition blocks (e.g., the one starting on line 5) use four colons (e.g., '::::tip') instead of the typically expected three (e.g., ':::tip'). This is likely a typographical error. Please verify and adjust the number of colons in the opening and closing markers for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The comment claims there are four colons being used, but looking at the actual file content, all admonition blocks consistently use three colons. The comment is making an incorrect observation. Since the comment is factually wrong, it should be deleted. Could there be other parts of the file I haven't noticed that do use four colons? Could the rendering behavior be different between three and four colons in a way I don't understand? I've carefully checked every admonition block in the file (lines 5, 128, 256, 266) and they all consistently use three colons. Even if there were rendering differences, the file is already using the standard three-colon syntax throughout. The comment should be deleted because it incorrectly claims four colons are being used when the file consistently uses three colons for all admonition blocks.

Workflow ID: wflow_lYCiLIUbiA4UaokQ

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}