Open StructByLightning opened 2 weeks ago
+1 to all the problems you've mentioned with writing a system message in JSON. It's pretty painful.
Implementing a system prompt file could be quite straightforward with the existing prompt files format we have: https://docs.continue.dev/customize/deep-dives/prompt-files
There's a few ways I think we could identify that a particular prompt file should be used as the system message:
Any reasons you'd lean towards one or the other?
I have a minor preference towards #3; the rest of the default config goes in config.json and it makes sense to me that there would at least be a reference to the system prompt from there?
But if you guys think #1 or #2 is better that'd be fine too. My only concern with is that can use multiple models and have separate prompts for them. So if there was a system
field in the preamble, it should be like: system: sonnet
or system: codestral
. Same for the filename.
Validations
Problem
Advanced prompts tend to be extremely long, especially with how cheap inference has gotten. For software engineering in particular, prompts often have double quotes in them as part of code examples. All of this makes it difficult and tedious to use JSON to define the system prompt — I have to replace all the double quotes with escaped quotes, remove all the newlines, and copy/paste the new prompt into the JSON (and if I ever want to edit it, I have to reverse the process and then do it all over again).
Solution
Prompt files already solve all of these problems and are a much cleaner way to organize prompts than JSON fields. A field called
systemPrompt
could be added that overridessystemMessage
and is just the path to the prompt file.