Enhance system prompt flexibility options

[kvokka]

What problem does this proposed feature solve?

System prompt is written in a generic way, which is a good default solution, but it can not be the best for the current SOTA LLMs and for older small local LLMs at the same time.

Currently, it's possible to adjust it, but it's painful

Also, global settings (like Open tabs context limit) pollute the context of subtasks for some modes and may consume up to 1k tokens for nothing. And it's not the only example.

Good solutions might be later easier included in Roo from/by the community. Win-win

Describe the proposed solution in detail

In Roo 3.17.2, when system prompt overriding is more challenging than it should be because:

1. The user still gets some leftovers from Roo, like language settings. It's excessive for the English language, but there is no way to cut it
2. Let the user use templating with the system prompt. Mustache lib or any other templating engine will work, passing the same context as the system prompt has now

Technical considerations or implementation details (optional)

No response

Describe alternatives considered (if any)

I'm ok to make a Roo Code plugin for this purpose, but #3770 is a blocker. Of course, it's possible to copy-paste a bunch of code from Roo, but it's best to go with this option and keep all in 1 place.

Additional Context & Mockups

No response

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Yes, I would like to contribute to implementing this feature.

[KJ7LNW]

See also #3482 but it does not yet handle models, only modes.

[daniel-lxs]

Since we are giving the user a lot of control with the Footgun prompt, it seems reasonable to clean up the remaining segments that Roo Code always sends, whether or not the user is using Footgun.

However, this might require some sort of templating system and could probably break every existing Footgun prompt.

Note: This is not an approval of this feature request. Please wait for a dev team member to approve it.

[KJ7LNW]

However, this might require some sort of templating system and could probably break every existing Footgun prompt.

Last year I wrote exactly the type of template system you might be looking for in Cline, but it was rejected outright even though it did follow best programming practices for flexibility over things like system prompts. Several other users were interested but it did not get off the ground:

cline/cline#845

Most of the implementation was targeted at having directory-based file name overrides for each tool:

• each tool had a system prompt template in a file in the project tree (assets/system-instructions.d/12-read_file.md
• that 12-read_file.md file name could be directly over written by a user in their home directory or in their project workspace

It was very similar to what .roo/rules/ is today, with the following additions that Roo does not (yet?) support:

• it supported a global user-level override directory (eg, $HOME/.roo/rules/)
• it supported template content and conditional variables to include/exclude based on configuration flags (// @condition: ${supportsComputerUse}) and had the capability of executing type script from the templates using dynamically scoped data structures.
• the project itself stored prompt templates in assets/system-instructions.d/ so modifying prompts was the same as modifying a single text file. this had the benefit of not having to escape backticks in system prompt rules:

	toolPrompt = `use the \`foo_tool\` when you wish to...`

the implementation is very concise if you would like to browse the tree:

• https://github.com/cline/cline/pull/845/files

I am not saying that you should try and pull this Cline PR in, because Roo's code bases substantially different, but all of the ideas are there any would give users:

• granular control for overrides over each tool
• total control over the entire system prompt
• template-based extensibility (though realistically we should probably use a real npm package for conditional template content handling)

[kvokka]

I like the idea. The implementation I wanted to make is very similar to this. And it feels strange not to accept that, coz there is enough space for improvements. The prompts didn't change for a while, but LLMs have undergone significant evolution in the last six months. Maintaining own fork seems to be too much for most developers.

From what i noticed, the system prompt might be cut significantly.

In the last few weeks, i opened several discussions and issues in Roo and didn't get any response from maintainers in even one, even the rejection.

[KJ7LNW]

"discussions" - where? In Discord or in Github?

Issues and PRs get a lot more attention, and contributors have a dedicated Discord area if you are planning to contribute.

[KJ7LNW]

Also the Roo devs are great, they are very open to improvement