fix: resolve newTaskRequireTodos setting not working correctly

[hannesrudolph]

Description

This PR fixes the newTaskRequireTodos VSCode setting that wasn't working correctly, particularly for the nightly build.

Problem

The newTaskRequireTodos setting was not enforcing the requirement for the todos parameter in the new_task tool when set to true. This was due to:

1. Configuration namespace mismatch: The code was checking hardcoded namespaces (roo-cline.newTaskRequireTodos and roo-code-nightly.newTaskRequireTodos) but the actual namespace varies between builds
2. Tool description issue: The todos parameter was completely hidden when the setting was false, instead of being shown as optional
3. Hardcoded example: The shared tool use section had a static new_task example that always included todos, causing confusion

Solution

1. Dynamic Configuration Namespace

• Now using Package.name from src/shared/package.ts which dynamically gets the correct package name based on the build
• This eliminates the need for hardcoded namespace values and works for both regular and nightly builds

2. Improved Tool Description

• The todos parameter is now always visible in the tool description
• It's marked as (optional) when newTaskRequireTodos is false
• It's marked as (required) when newTaskRequireTodos is true
• This provides clear guidance to the AI about parameter requirements

3. Removed Hardcoded Example

• Removed the static new_task example from the shared tool use section to avoid confusion

Changes Made

• src/core/tools/newTaskTool.ts - Use dynamic Package.name for configuration
• src/core/prompts/tools/new-task.ts - Show todos as optional/required based on setting
• src/core/prompts/sections/tool-use.ts - Remove hardcoded new_task example
• src/core/tools/__tests__/newTaskTool.spec.ts - Update tests to use Package.name
• src/core/prompts/tools/__tests__/new-task.spec.ts - Update tests for new behavior

Testing

• ✅ All existing tests pass (14 tests in newTaskTool.spec.ts, 5 tests in new-task.spec.ts)
• ✅ Type checking passes
• ✅ Linting passes
• ✅ The setting now works correctly for both regular and nightly builds

Verification

To verify this fix:

1. Set newTaskRequireTodos to true in VSCode settings
2. The AI should now require todos when using the new_task tool
3. Set it to false and the todos parameter becomes optional
4. Works correctly in both regular and nightly builds

---

Important

Fixes newTaskRequireTodos setting in VSCode by using dynamic configuration namespace and adjusting tool descriptions and examples.

• Behavior:
  • Fixes newTaskRequireTodos setting in VSCode to correctly enforce todos parameter requirement in new_task tool.
  • Uses Package.name from package.ts for dynamic configuration namespace, supporting both regular and nightly builds.
  • Adjusts todos parameter visibility in new_task tool description based on setting.
  • Removes hardcoded new_task example from shared tool use section.
• Code Changes:
  • newTaskTool.ts: Implements dynamic namespace and checks newTaskRequireTodos setting.
  • new-task.ts: Updates prompt to show todos as optional/required.
  • tool-use.ts: Removes static new_task example.
• Testing:
  • Updates tests in newTaskTool.spec.ts and new-task.spec.ts to cover new behavior and dynamic namespace usage.
  • Ensures backward compatibility and correct handling of missing parameters.

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

[Copilot]

Pull Request Overview

This PR fixes the newTaskRequireTodos VSCode setting that wasn't working correctly due to hardcoded configuration namespaces and improves the tool description clarity.

• Replaces hardcoded configuration namespaces with dynamic Package.name to work across different builds
• Updates tool description to always show the todos parameter with clear optional/required indicators
• Removes confusing hardcoded example from shared tool use section

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/core/tools/newTaskTool.ts	Uses dynamic Package.name for VSCode configuration access
src/core/tools/__tests__/newTaskTool.spec.ts	Adds Package module mock and updates test descriptions
src/core/prompts/tools/new-task.ts	Refactors tool description to always show todos parameter with appropriate labeling
src/core/prompts/tools/__tests__/new-task.spec.ts	Updates tests to verify new optional/required parameter behavior
src/core/prompts/sections/tool-use.ts	Removes hardcoded new_task example to eliminate confusion

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The conditional logic for the example message and todos section creates complex template literal nesting that's difficult to read and maintain. Consider extracting the example generation into separate helper functions or variables to improve readability.

[Copilot]

[nitpick] The additional conditional example section further complicates the template literal structure. This nested conditional logic makes the function harder to understand and maintain. Consider restructuring to use a more straightforward approach with separate string building or helper functions.

Suggested change

	: ""
	}`
	}
	const description = [
	"## new_task",
	`Description: This will let you create a new task instance in the chosen mode using your provided message${todosRequired ? " and initial todo list" : ""}.`,
	"",
	"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.",
	getTodosParamDescription(todosRequired),
	"",
	"Usage:",
	"<new_task>",
	"<mode>your-mode-slug-here</mode>",
	"<message>Your initial instructions here</message>" + getTodosUsageBlock(todosRequired),
	"</new_task>",
	"",
	"Example:",
	"<new_task>",
	"<mode>code</mode>",
	`<message>${todosRequired ? "Implement user authentication" : "Implement a new feature for the application"}</message>` + getTodosExampleBlock(todosRequired),
	"</new_task>",
	"",
	getOptionalTodosExampleBlock(todosRequired)
	].join("\n");
	return description;

[roomote]

Thank you for your contribution! I've reviewed the changes and the fix correctly addresses the newTaskRequireTodos setting issue. The implementation successfully resolves the namespace mismatch problem and improves the tool description clarity.

Review Findings

✅ What works well:

• The use of Package.name for dynamic namespace resolution is an excellent solution that handles different build variants
• Tests are comprehensive and cover the main functionality
• The change to always show the todos parameter with clear optional/required indicators improves clarity

💡 Suggestions for improvement:

1. Code readability in src/core/prompts/tools/new-task.ts
I agree with Copilot's existing feedback - the nested template literals with multiple ternary operators (lines 18-61) create complex, hard-to-maintain code. Consider refactoring this into helper functions or building the string incrementally.

2. Potential race condition in src/core/tools/newTaskTool.ts (line 136)
The hardcoded 500ms delay after mode switching might not be sufficient in all cases. Consider implementing a more robust wait mechanism that checks for completion rather than using a fixed delay.

3. Documentation improvement for src/core/tools/newTaskTool.ts (line 61-62)
Consider adding a comment explaining why Package.name is used instead of hardcoded values to help future maintainers understand the dynamic namespace requirement for different build variants.

4. Test coverage enhancement in src/core/tools/__tests__/newTaskTool.spec.ts
Consider adding test cases with different Package.name values (e.g., 'roo-code-nightly') to ensure the dynamic namespace resolution works correctly for all build variants.

Overall, this is a solid fix that addresses the core issue effectively. The suggestions above would further improve code maintainability and robustness.