Clean up logic for tool definitions

[worksofliam]

What specific problem does this solve?

The logic which makes up a tool (instructions, parameters, implementation, group) is spread across multiple files. Let's use write_file as an example:

• Implementation defined src/core/tools/writeToFileTool.ts
• Prompt defined in src/core/prompts/tools/write-to-file.ts
• Groups defined in src/shared/tools.ts

This doesn't seem right. Would it not be better if everything that made up a tool belong in a single class or interface?

Additional context (optional)

At the same time, I think it might be worth uncoupling some of the hardcoded values for the sake of typing, like ToolName and toolParamNames.

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

• Implement a new base class for a RooTool with abstractions for getting the prompts, groups, parameters, and invocating
• Re-work all existing tools into a class (extending RooTool)
• Remove any likeness of tool maps for individual values (like toolDescriptionMap) or switch statements (src/core/assistant-message/presentAssistantMessage.ts)
• Frontend logic would not be touch as part of this pull-request.

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

• Existing test cases need to continue passing, or updated based on signature changes.
• UX should not change at all.

Technical considerations (REQUIRED if contributing, optional otherwise)

The goal is this should simplify the maintenance of tools instead of having all this logic spread out across many files.

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

No response

[roomote]

I'm exploring a potential fix for this issue and will open a PR to share progress. Since you expressed interest in implementing this yourself, please feel free to provide feedback or take over if you prefer. The refactoring to consolidate tool logic into a base RooTool class makes a lot of sense for maintainability.

[worksofliam]

Happy to help wherever you see fit. I will be on the office hours tomorrow too. I will keep an eye out for your PR.

[roomote]

I've opened PR #7824 with an initial implementation of the tool consolidation architecture.

The PR introduces:

• A base class that consolidates all tool logic
• A for centralized tool management
• A for backward compatibility during migration
• An example implementation with

This approach allows for gradual migration without breaking existing functionality. The CI checks are currently running.

Feedback welcome!

[worksofliam]

I just had a look at the PR and it's looking almost identical to the branch I was working on. The timing of my opening of the issue and you creating your PR is hilarious and I am glad you're diving into this. Thanks. I am not sure where I can help at this point since you're already going for it, but I do think this is a great move.

[worksofliam]

I will add, since I was testing this with some random tool I implemented, I think the frontend could do with a way to ask a question without having to add new logic to handle a specific tool. In ChatRowContent, in the default block, I had this logic:

if (tool.query) {
	return (
		<>
			<div style={headerStyle}>
				{toolIcon("file-code")}
				<span style={{ fontWeight: "bold" }}>{tool.query}</span>
			</div>
			{tool.content ? (
				<ToolUseBlock>
					<ToolUseBlockHeader>
						<span className="whitespace-nowrap overflow-hidden text-ellipsis text-left mr-2 rtl">
							{tool.content}
						</span>
					</ToolUseBlockHeader>
				</ToolUseBlock>
			) : (
				<></>
			)}
		</>
	)
}

[worksofliam]

Last remark: honestly, seems like the logic to handle block.partial should be taken out of the tool invocation, or at least made optional. The majority of tools don't support partial messages (for example, readFileTool.ts does support partial messages, but insertContentTool.ts, runSlashCmmandTool.ts, simpleReadFileTool and many more), so each of them having to write this logic seems annoying.

In my implementation of RooTool, I had two ways of invoking the tool:

1. Through the standard way like it is today (your execute method)
2. A more abstracted method on the tool - which I named call below - which didn't support partial messages, but did a majority of the ugly work of building the parameters object.

This logic might exist in your adapter class, or even part of the executeTool method.

const tool: RooTool = toolToCall;

if (!tool.call) {
	throw new Error(`Call not defined for tool ${tool.getId()}`)
}

const sharedMessageProps: ClineSayTool = {
	tool: tool.getId(),
}

if (block.partial) {
	const partialMessage = JSON.stringify({
		...sharedMessageProps,
		content: undefined,
	} satisfies ClineSayTool)
	await cline.ask("tool", partialMessage, block.partial).catch(() => {})
	return
}

cline.consecutiveMistakeCount = 0

let parameters: RooCallParameters = {}

if (tool.parameters) {
	for (const p of tool.parameters) {
		parameters[p.name] = removeClosingTag(p.name, block.params[p.name])
	}
}

await tool.call({parameters})