docs: add keyboard shortcuts documentation and v3.12.x release notes

[hannesrudolph]

• Add comprehensive keyboard shortcuts documentation page explaining the roo.acceptInput command
• Update suggested-responses documentation to reference keyboard shortcut option
• Add keyboard shortcut tip to tips-and-tricks page
• Add release notes for versions 3.12.0, 3.12.1, and 3.12.2
• Update sidebar configuration to include new pages
• Update update-notes index to include v3.12.x releases

---

Important

Add keyboard shortcuts documentation and v3.12.x release notes, updating sidebar configuration accordingly.

• Documentation:
  • Add keyboard-shortcuts.md detailing roo.acceptInput command and setup in docs/features/.
  • Update suggested-responses.md to include roo.acceptInput keyboard shortcut option.
  • Add keyboard shortcut tip to tips-and-tricks.md.
  • Add release notes for v3.12.0, v3.12.1, and v3.12.2 in docs/update-notes/.
• Sidebar:
  • Update sidebars.ts to include new keyboard shortcuts and release notes pages.

^{This description was created by for dfad28a. 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	💬 3 unresolved	Apr 16, 2025 10:30pm

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 67275a2 in 1 minute and 44 seconds

More details

• Looked at 315 lines of code in 8 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. docs/features/keyboard-shortcuts.md:56

• Draft comment:
  The JSON snippet includes an inline comment (e.g., on line 58) which isn’t valid JSON. Consider removing or annotating that these comments are for demonstration purposes only, to avoid copy‐paste issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This is a documentation file showing users how to configure keyboard shortcuts. The inline comment actually serves a useful purpose by explaining what the "key" value represents. While technically the JSON would be invalid with the comment, this is clearly an educational example and the comment helps readability. Most developers would understand to exclude the comment when actually implementing it.
  The comment raises a valid point about JSON syntax, but may be overly pedantic for documentation purposes. The inline comment actually makes the example more helpful for users.
  The benefits of having the explanatory inline comment outweigh the minor technical inaccuracy, especially in documentation meant to help users understand the configuration.
  The comment should be deleted. The inline comment in the JSON example, while technically invalid JSON, serves a useful educational purpose in the documentation context.

2. docs/features/keyboard-shortcuts.md:56

• Draft comment:
  The JSON snippet includes an inline comment (e.g., '// or your preferred key combination'). Since comments aren't valid JSON, consider adding a note clarifying this is for demonstration only, or remove the comment to avoid confusion when copying.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While technically correct that comments aren't valid JSON, this is documentation meant to teach users. The inline comment helps explain the purpose of the value. VS Code's keybindings.json actually does support comments, so this isn't even incorrect for the specific use case. The suggested fix would make the documentation less helpful.
  The comment is technically accurate about pure JSON syntax. Perhaps unclear documentation could confuse users who try to copy-paste.
  This is specifically about VS Code's keybindings.json which does support comments. The inline comment adds valuable context for users learning the feature.
  The comment should be deleted. The inline comment in the docs is intentional and helpful, and works correctly in VS Code's keybindings.json.

3. docs/update-notes/v3.12.0.md:38

• Draft comment:
  A trailing newline is missing at the end of this file. Please add one for consistency with our code style guidelines.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While having a trailing newline is generally considered good practice, this is exactly the kind of thing that should be handled by automated tooling like EditorConfig, Prettier, or pre-commit hooks. It's a trivial formatting issue that doesn't affect functionality. Making comments about such minor formatting issues creates noise in the PR review process.
  The comment is technically correct - having a trailing newline is a common convention. Some tools might have issues with files that don't end in newlines.
  While technically correct, this is precisely the kind of formatting issue that should be automatically enforced by tooling rather than manual review comments. It adds unnecessary noise to the review process.
  Delete this comment as it addresses a trivial formatting issue that should be handled by automated tooling rather than manual review.

4. docs/update-notes/v3.12.1.md:7

• Draft comment:
  Consider adding a trailing newline at the end of this file to meet our formatting standards.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While having trailing newlines is generally good practice, this kind of formatting issue should be handled automatically by ESLint/Prettier which should be set up as pre-commit hooks according to our standards. Making manual comments about formatting is not useful since it should be automated.
  Perhaps the ESLint/Prettier setup is not properly configured to enforce trailing newlines, making this a valid concern?
  Even if that's the case, the solution would be to fix the linter configuration, not to manually review and comment on formatting issues.
  This comment should be deleted as formatting issues should be handled by automated tools, not manual review comments.

5. docs/update-notes/v3.12.2.md:12

• Draft comment:
  A trailing newline is missing at the end of this file. Please add one to maintain consistency with our project guidelines.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
  The comment is about a missing trailing newline, which is a code style issue. However, the rules do not explicitly mention enforcing trailing newlines, and this comment seems to be purely informative without suggesting a specific code improvement or addressing a potential issue. Therefore, it might not be necessary to keep this comment.

6. sidebars.ts:142

• Draft comment:
  Sidebar configuration updated to include new docs and release notes looks well organized. Please double-check that the version ordering (latest first) meets our intended navigation structure.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

7. docs/update-notes/v3.12.1.md:7

• Draft comment:
  The file is missing a trailing newline at the end. While this isn't a functional bug, adding a newline at the end of the file is a common best practice and helps avoid issues with some tools.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 30% <= threshold 50%
  The comment is about a missing trailing newline, which is a common best practice in coding. However, it doesn't directly relate to functionality or the specific rules provided. It seems more like a style preference, which might be covered by tools like ESLint or Prettier. Since the rules emphasize enforcing code style rules through tools, this comment might not be necessary if those tools are in place.

Workflow ID: wflow_CFDIBpVn9l0Vlsje

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 9481e45 in 2 minutes and 2 seconds

More details

• Looked at 152 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. docs/features/keyboard-shortcuts.md:159

• Draft comment:
  Ensure the file ends with a newline for consistency with best practices.
• Reason this comment was not posted:
  Comment was on unchanged code.

2. docs/update-notes/v3.12.0.md:17

• Draft comment:
  Consider maintaining a consistent thanking style; 'thanks axkirillov!' could be aligned with other thank you notes for uniformity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

3. docs/features/keyboard-shortcuts.md:15

• Draft comment:
  Review Note: The 'roo.openChat' command row has been removed from the keyboard commands table. Ensure that this removal is intentional and that any related functionality in the codebase/documentation is updated accordingly.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. docs/features/keyboard-shortcuts.md:45

• Draft comment:
  Review Note: The image illustrating keybinding setup was removed. If this was an intentional update (e.g., due to outdated visuals), please confirm that any necessary visual guidance is provided elsewhere in the documentation.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

5. docs/update-notes/v3.12.0.md:1

• Draft comment:
  Review Note: The release notes header specifies a release date of '2025-04-15'. Please verify that this future date is correct and intentional as part of the release planning.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_wlkdUQJNZhZwxviR

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 5d208ce in 2 minutes and 54 seconds

More details

• Looked at 130 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. docs/features/api-configuration-profiles.md:16

• Draft comment:
  Consider adding a version note (e.g., 'v3.12+') next to 'Diff editing configuration' to clarify that this feature is available from version 3.12 onward.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
  The comment suggests adding a version note to clarify the availability of a feature from a specific version onward. This is a suggestion for improving documentation clarity, which is not strictly related to code quality or functionality. It doesn't align with the rules provided, which focus on code quality, testing, and adherence to development standards.

2. docs/update-notes/v3.12.0.md:1

• Draft comment:
  Verify that the release date and version are consistent with the overall release strategy, especially if similar information appears in the new release notes file.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

3. docs/update-notes/v3.12.md:1

• Draft comment:
  Confirm that having both 'v3.12.0.md' and 'v3.12.md' is intentional, as they appear to contain nearly identical content.
• Reason this comment was not posted:
  Comment was on unchanged code.

4. docs/features/api-configuration-profiles.md:97

• Draft comment:
  The added bullet for diff editing configuration is clear, but consider linking to more detailed documentation (if available) for consistency with other profile settings.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

5. docs/update-notes/v3.12.0.md:1

• Draft comment:
  The release note title now says '3.12 Release Notes' while the file is named v3.12.0.md. Consider aligning the version number in the title with the file name for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While there is a minor inconsistency, version numbers in release note titles are often simplified for readability. The file name needs the full semantic version for technical reasons, but the title can be more reader-friendly. This seems like a stylistic choice rather than a technical issue. None of our provided rules specifically require semantic versioning in titles.
  The comment might be pointing out a legitimate consistency issue that could affect version tracking or documentation standards. Some organizations do require strict version number consistency.
  However, this appears to be a purely cosmetic issue in documentation. There's no evidence that this inconsistency violates any project standards or causes any technical problems.
  This comment should be removed as it suggests a change that is not clearly required and falls into the category of being purely informative rather than identifying a clear problem.

6. docs/update-notes/v3.12.md:1

• Draft comment:
  This new file appears to duplicate content already present in v3.12.0.md. Ensure that maintaining two similar release note files is intentional (e.g., for aggregated notes) to avoid confusion.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the PR author to ensure that maintaining two similar release note files is intentional. This falls under asking the author to confirm their intention, which is against the rules. The comment does not provide a specific code suggestion or ask for a specific test to be written. Therefore, it should be removed.

7. docs/features/api-configuration-profiles.md:5

• Draft comment:
  The info block marker on line 5 uses '::::info'. Usually, this should be ':::info' to match common markdown syntax for admonitions. Please double-check if the extra colon was intentional.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

8. docs/features/api-configuration-profiles.md:15

• Draft comment:
  The term 'Thinking budgets' on line 15 might be a typographical error. If you intended to write 'Token budgets' or another phrase, please update it for clarity.
• Reason this comment was not posted:
  Comment was on unchanged code.

Workflow ID: wflow_9WRzZ9ZT1k2tXTg9

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 031ea44 in 38 seconds

More details

• Looked at 57 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. docs/update-notes/v3.12.md:1

• Draft comment:
  The entire v3.12 release notes file was removed. Please ensure that the release notes for versions 3.12.0, 3.12.1, and 3.12.2 are available in the new documentation and that all references (e.g., sidebar, update-notes index) have been updated accordingly.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. docs/update-notes/v3.12.md:1

• Draft comment:
  The entire v3.12 release notes file has been removed. According to the PR description, release notes for versions 3.12.0, 3.12.1, and 3.12.2 should be added. Please ensure that either this content is relocated to new files or that references (e.g., in the sidebar and update-notes index) are updated accordingly.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_RTOBpvAu7vGEfSzb

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on dfad28a in 45 seconds

More details

• Looked at 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. docs/update-notes/v3.12.0.md:24

• Draft comment:
  The documentation is comprehensive and well-structured; however, ensure that the version date format (YYYY-MM-DD) is consistent with our other release notes. Also, consider linking to the Keyboard Shortcuts documentation more explicitly in the Keyboard Shortcuts section for clarity. This follows our Development Standards.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. docs/update-notes/v3.12.0.md:1

• Draft comment:
  Verify that the release date '2025-04-16' is accurate and intended.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

3. docs/update-notes/v3.12.0.md:41

• Draft comment:
  Consider standardizing bullet punctuation for consistency across all list items.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

4. docs/update-notes/v3.12.0.md:7

• Draft comment:
  Ensure that internal links (e.g., '/providers/xai' and '/features/keyboard-shortcuts') are valid and up-to-date.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_ghTFTcQegtiLbK70

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[mrubens]

Does this work?