Advanced usage refactor: Stage 1

[hannesrudolph]

• Auto-Approving Actions
• API Configuration Profiles
• Custom Modes
• Custom Instructions

---

Important

Refactor advanced usage docs to enhance API Configuration Profiles, Custom Instructions, and Custom Modes with detailed setup and management guidance.

• API Configuration Profiles:
  • Expanded to include more providers and models in api-configuration-profiles.md.
  • Detailed steps for creating, switching, editing, and deleting profiles.
  • Profiles can be linked to modes for workflow efficiency.
  • API keys stored securely in VSCode's Secret Storage.
• Custom Instructions:
  • custom-instructions.md now explains global and workspace-level instructions.
  • Instructions can be set via UI or .rules files.
  • Instructions are combined in a specific order in the system prompt.
• Custom Modes:
  • custom-modes.md details creating global or project-specific modes.
  • Modes include role definitions, custom instructions, tool access, and file restrictions.
  • JSON format for mode configuration with examples provided.
  • Regex patterns explained for file restrictions.
  • Modes can be created via prompts, UI, or manual JSON editing.

^{This description was created by for 0f0f6e5. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 0f0f6e5 in 1 minute and 58 seconds

More details

• Looked at 480 lines of code in 3 files
• Skipped 15 files when reviewing.
• Skipped posting 10 drafted comments based on config settings.

1. docs/advanced-usage/api-configuration-profiles.md:11

• Draft comment:
  Good update to API providers; ensure the list stays current if more providers are added. Consider verifying that bullet list styling remains consistent across different sections.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative and does not provide a specific actionable suggestion or point out a specific issue in the code. It also asks the author to ensure something without providing a concrete suggestion or identifying a specific problem.

2. docs/advanced-usage/custom-instructions.md:8

• Draft comment:
  The info block for 'Rules Files' is clear; ensure spacing and block marker consistency for optimal Markdown rendering.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative and does not provide a specific code suggestion or highlight a potential issue. It does not align with the rules for making comments, as it does not ask for a specific change or improvement.

3. docs/advanced-usage/custom-modes.md:247

• Draft comment:
  The regex explanation is clear. Consider adding one example of a negative lookahead pattern for completeness.
• 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 appears to have missed that there is already a negative lookahead example in the table. Not only that, but the pattern is also listed in the "Pattern Building Blocks" section on line 268. Having multiple examples would be redundant and potentially confusing.
  Could there be value in having multiple different examples of negative lookahead to show different use cases?
  While multiple examples can be helpful, the existing example is clear and practical, showing how to exclude test files. Adding more could make the documentation more complex without adding significant value.
  The comment should be deleted since the document already includes a negative lookahead pattern example and explanation.

4. docs/advanced-usage/api-configuration-profiles.md:5

• Draft comment:
  Consider standardizing the admonition block markers to use three colons (e.g., :::info) rather than four for consistency across the documentation.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

5. docs/advanced-usage/custom-instructions.md:8

• Draft comment:
  The info block marker on this line uses four colons (::::info Rules Files); please standardize it (e.g., :::info Rules Files) to maintain consistency with other sections.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. docs/advanced-usage/custom-modes.md:279

• Draft comment:
  The tip block marker here uses four colons (::::tip); for consistency with other admonition blocks, consider using three colons (:::tip).
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

7. docs/advanced-usage/custom-modes.md:231

• Draft comment:
  For branding consistency, change 'Roo-Code' to 'Roo Code' as used elsewhere throughout the documentation.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

8. docs/advanced-usage/api-configuration-profiles.md:5

• Draft comment:
  Typographical error: It appears that the admonition block starting at line 5 is using '::::info' instead of the correct ':::info'. Please update both the starting and ending markers to use three colons instead of four.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

9. docs/advanced-usage/custom-modes.md:257

• Draft comment:
  Typographical error: In the Common Pattern Examples table, the regex pattern \.(css\|scss)$ appears to be incorrectly escaped. The vertical bar in a regex does not need a backslash. Consider changing it to \.(css|scss)$.
• 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%

1. The comment is technically incorrect - in JSON strings, backslashes must be doubled, so the pattern is actually correct as shown. 2. The documentation itself explains this rule in multiple places (lines 247, 275). 3. The pattern works correctly as written and matches the escaping convention used throughout the examples.
   Could the pattern be written differently in the non-JSON context? Am I sure about JSON string escaping rules?
   Yes, I am confident. The documentation explicitly states that backslashes must be doubled in JSON, and this is a consistent pattern throughout all examples. The comment author may have confused regex syntax outside of JSON context with JSON string escaping requirements.
   The comment should be deleted because it is incorrect - the pattern is properly escaped for JSON strings as required and documented.

10. docs/advanced-usage/custom-modes.md:259

• Draft comment:
  Typographical error: In the Common Pattern Examples table, the regex pattern ^(?!.*(test\|spec)).*\.js$ seems to have an unnecessary backslash before the pipe. It should likely be ^(?!.*(test|spec)).*\.js$ to correctly represent the alternation without escaping the pipe.
• 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%

1. The comment is incorrect - in JSON strings, backslashes must be escaped with another backslash. 2. This is explicitly mentioned in the document under "Important Rules" section. 3. The pattern is actually correct as shown because it's meant to be used in JSON configuration. 4. The document even provides examples of proper escaping throughout.
   Could there be a case where unescaped pipes would work in this context? Am I certain about JSON string escaping rules?
   No - JSON string escaping rules are well-defined and consistent. The document correctly shows and explains the required double escaping for JSON configuration.
   The comment should be deleted because it is incorrect - the backslash before the pipe is necessary in JSON configuration, as explicitly explained in the document.

Workflow ID: wflow_kJWGmf4bHz8Nwz8S

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

There's a typographical error in the admonition syntax on line 8: ::::info Rules Files should likely be :::info Rules Files (using three colons, not four).

Suggested change

	:::info Rules Files
	:::info Rules Files

[ellipsis-dev]

There appears to be a typographical error in the tip admonition block starting on line 90 (::::tip Pro Tip: File-Based Team Standards) and ending on line 92. It should use three colons instead of four (i.e., :::tip ...), to maintain consistency with other admonition blocks.

Suggested change

	:::tip Pro Tip: File-Based Team Standards
	:::tip Pro Tip: File-Based Team Standards

[mrubens]

🏴‍☠️