Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Aug 8, 2025

Summary

This PR implements the feature requested in #6839 to add an optional config parameter to the new_task tool, allowing users to specify different API configuration profiles when creating sub-tasks.

Changes

Core Implementation

  • Tool Description: Updated src/core/prompts/tools/new-task.ts to include the new optional config parameter with clear documentation and examples
  • Tool Handler: Modified src/core/tools/newTaskTool.ts to:
    • Accept and validate the config parameter
    • Check if the specified configuration exists
    • Pass the config to the task initialization
    • Provide graceful fallback if config doesn't exist
  • Task Initialization: Updated src/core/webview/ClineProvider.ts to:
    • Accept config name as a parameter in initClineWithTask
    • Load and apply the specified configuration profile
    • Apply profile-specific settings (diff, fuzzy match threshold)
    • Handle errors gracefully with fallback to default config

Type System Updates

  • Added config to toolParamNames in src/shared/tools.ts
  • Updated NewTaskToolUse interface to include the config parameter

Testing

  • Added comprehensive test coverage for the new functionality
  • Tests verify config validation, error handling, and backward compatibility
  • All existing tests updated to work with the new signature

Benefits

Enhanced Flexibility: Users can optimize model selection per task
Cost Control: Use appropriate models for different task types
Workflow Efficiency: No need to interrupt workflow to change global settings
Backward Compatibility: Optional parameter doesn't break existing usage
Leverages Existing Infrastructure: Uses the established configuration management system

Testing

  • ✅ All tests passing (npx vitest run core/tools/__tests__/newTaskTool.spec.ts)
  • ✅ TypeScript compilation successful
  • ✅ Linting checks passed

Example Usage

<new_task>
<mode>code</mode>
<message>Write unit tests for the authentication module</message>
<config>fast-model</config>
</new_task>

Fixes #6839


Important

Adds optional config parameter to new_task tool for specifying API configuration profiles, enhancing flexibility and efficiency.

  • Behavior:
    • Adds optional config parameter to new_task tool in new-task.ts for specifying API configuration profiles.
    • Updates newTaskTool.ts to handle config parameter, validate existence, and apply it during task initialization.
    • Modifies ClineProvider.ts to load and apply configuration profiles in initClineWithTask().
  • Type System:
    • Adds config to toolParamNames in tools.ts.
    • Updates NewTaskToolUse interface to include config parameter.
  • Testing:
    • Adds tests in newTaskTool.spec.ts for config validation, error handling, and backward compatibility.

This description was created by Ellipsis for e73e20d. You can customize this summary. It will automatically update as commits are pushed.

- Add optional config parameter to new_task tool description
- Update newTaskTool.ts to handle config parameter validation
- Modify initClineWithTask to accept and apply config profiles
- Add comprehensive tests for new functionality
- Maintain backward compatibility for existing usage

Fixes #6839
@roomote roomote bot requested review from cte, jr and mrubens as code owners August 8, 2025 08:52
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. enhancement New feature or request labels Aug 8, 2025
cline.emit(RooCodeEventName.TaskSpawned, newCline.taskId)

pushToolResult(`Successfully created new task in ${targetMode.name} mode with message: ${unescapedMessage}`)
const successMessage = configName
Copy link
Contributor

Choose a reason for hiding this comment

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

User-facing success messages are constructed as plain strings. Consider using the translation function (e.g., t()) for these messages to support internationalization.

This comment was generated because it violated a code review rule: irule_C0ez7Rji6ANcGkkX.

Copy link
Contributor Author

@roomote roomote bot left a comment

Choose a reason for hiding this comment

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

Reviewing my own code feels like debugging in a mirror - everything's backwards but somehow still broken.

| "experiments"
>
>,
) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The overloaded function signature accepting configNameOrOptions as either a string or options object could be confusing. Consider splitting into two methods or using a more explicit parameter structure for better clarity?

This works but might trip up future maintainers (including myself in 3 months).

}
} catch (error) {
// Log error but continue with default config
this.log(`Failed to load config '${configName}' for new task: ${error}`)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

When a config fails to load, we log the error but continue silently. Should we notify the user that the requested config couldn't be loaded and we're falling back to the default? This could prevent confusion when a task doesn't use the expected model.

Parameters:
- mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect").
- message: (required) The initial user message or instructions for this new task.
- config: (optional) The slug/name of the API configuration profile to use for this task (e.g., "claude-3-5-sonnet", "gpt-4-debug", "fast-model"). If not specified, uses the default configuration for the mode.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The tool description could mention that invalid configs fall back to default gracefully. This would set proper expectations for users.

// Verify initClineWithTask was NOT called for partial message
expect(mockInitClineWithTask).not.toHaveBeenCalled()
})
})
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great test coverage for the main functionality! Consider adding edge case tests for:

  • Config loading errors (network failures, corrupted config)
  • Config names with special characters
  • Race conditions when switching configs rapidly

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Aug 8, 2025
@daniel-lxs
Copy link
Member

Not planned

@daniel-lxs daniel-lxs closed this Aug 11, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Aug 11, 2025
@github-project-automation github-project-automation bot moved this from Triage to Done in Roo Code Roadmap Aug 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. size:L This PR changes 100-499 lines, ignoring generated files.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Feature: Add configuration parameter to new_task tool

4 participants