- Add Skill type to ContextMenuOptionType enum
- Implement $ trigger detection anywhere after whitespace
- Add insertSkill function for $skill-name insertion with metadata
- Add skill-related message types (ExtensionMessage and WebviewMessage)
- Update ChatTextArea to handle skill autocomplete (request/receive/display)
- Update handleMentionSelect to use insertSkill for skill selection
- Update ContextMenu component to render skill suggestions
- Add requestSkills handler in ClineProvider to provide mode-filtered skills
- Add send-time skill resolution to include SKILL.md content in prompts
- Update highlight layer to visually highlight valid $skill-name tokens
- Add comprehensive tests for skill autocomplete functionality
- Skills are filtered by current mode and resolved at message send time
- Skill content is attached as structured metadata for extension processing
* feat: add optional mode field to slash command front matter
- Add mode field to Command interface
- Update command parsing to extract mode from frontmatter
- Modify RunSlashCommandTool to automatically switch mode when specified
- Add comprehensive tests for mode field parsing and switching
- Update existing tests to include mode field
* Make it work for manual slash commands too
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Co-authored-by: Matt Rubens <mrubens@users.noreply.github.com>
* Add support for skills
* fix: use type-only import for ClineProvider and relative paths in skills section
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Implements grace retry error handling for 'no assistant messages' API
errors, following the same pattern as PR #10196 for 'no tools used'.
- Add consecutiveNoAssistantMessagesCount counter to Task.ts
- First failure: silent retry (grace retry)
- After 2+ consecutive failures: show MODEL_NO_ASSISTANT_MESSAGES error
- Add UI handling in ChatRow.tsx with ErrorRow component
- Add localized strings to all 18 locale files
- Add comprehensive tests for the grace retry behavior
* feat: add error details modal with on-demand display
- Add errorDetails prop to ErrorRow component
- Show Info icon on hover in error header when errorDetails is provided
- Display detailed error message in modal dialog on Info icon click
- Add Copy to Clipboard button in error details modal
- Update generic error case to show localized message with details on demand
- Add i18n translations for error details UI
* UI Tweaks
* Properly handles error details
* i18n
* Lighter visual treatment for errors
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Co-authored-by: Bruno Bergher <bruno@roocode.com>
When tools are called in parallel (e.g., update_todo_list + new_task),
the tool results accumulate in userMessageContent but aren't saved to
API history until all tools complete. When new_task triggers delegation,
the parent is disposed before these pending results are saved, causing
400 errors when the parent resumes (missing tool_result for tool_use).
This fix:
- Adds flushPendingToolResultsToHistory() method in Task.ts that saves
pending userMessageContent to API history
- Calls this method in delegateParentAndOpenChild() before disposing the
parent task
- Safe for both native/XML protocols and sequential/parallel execution
(returns early if there's nothing to flush)
* feat: add model-specific tool customization via excludedTools and includedTools
- Add excludedTools and includedTools to ModelInfo schema
- Implement applyModelToolCustomization helper to filter tools based on model config
- Integrate model tool filtering into filterNativeToolsForMode for native protocol
- Add comprehensive tests for tool customization functionality
- Wire up modelInfo through buildNativeToolsArray and Task.ts
This allows providers to override which native tools are available on a per-model basis via MODEL_DEFAULTS, enabling better control over tool selection for models with specific needs.
* feat: add customTools for opt-in only tools
- Add customTools array to ToolGroupConfig for defining opt-in only tools
- Update getToolsForMode() to exclude customTools from default tool set
- Modify applyModelToolCustomization() to include customTools only via includedTools
- Add tests for customTools functionality
- Add comprehensive documentation with usage examples
customTools allows defining tools that are NOT available by default,
even when a mode includes their group. These tools are only available
when explicitly included via a model's includedTools configuration.
This enables:
- Gradual rollout of experimental tools
- Model-specific specialized capabilities
- Safe experimentation without affecting default tool sets
* Add assertions for customTools tests per review feedback
* test: add tests for including customTools via includedTools
* Update src/core/prompts/tools/__tests__/filter-tools-for-mode.spec.ts
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* feat: store reasoning in conversation history for all providers
* refactor: address review feedback
- Move comments inside else block
- Combine reasoning checks into single if block
- Make comments more concise
* refactor: make comments more concise
* Fix preserveReasoning flag to control API reasoning inclusion
Changes:
1. Removed hardcoded <think> tag logic in streaming
- Previously hardcoded reasoning into assistant message text
- Now passes reasoning to addToApiConversationHistory as parameter
2. Updated buildCleanConversationHistory to respect preserveReasoning flag
- When preserveReasoning: true → reasoning block included in API requests
- When preserveReasoning: false/undefined → reasoning stripped from API
- Reasoning stored in history for all cases
3. Added temporary debug logs to base-openai-compatible-provider.ts
- Shows preserveReasoning flag value
- Logs reasoning blocks in incoming messages
- Logs <think> tags in converted messages sent to API
* Fix: Use api.getModel() directly instead of cachedStreamingModel
Addresses review comment: cachedStreamingModel is set during streaming but
buildCleanConversationHistory is called before streaming starts. Using the
cached value could cause stale model info when switching models between requests.
Now directly uses this.api.getModel().info.preserveReasoning to ensure we
always check the current model's flag, not a potentially stale cached value.
* Clean up comments in Task.ts
Removed outdated comment regarding model's preserveReasoning flag.
* fix: remove unnecessary reasoningBlock variable in task reasoning logic
- Filter out complete environment_details blocks before appending fresh ones
- Check for both opening and closing tags to ensure we're matching complete blocks
- Prevents stale environment data from being kept during task resume
- Add tests to verify deduplication logic and edge cases
