Improvements to custom system_prompt

[gleachkr]

If you use Neovim for everything, it's easy to imagine using CodeCompanion for tasks other than coding—for example proofreading emails, brainstorming in note-taking contexts, revising GitHub issues for clarity, etc.

What I've found myself doing is overriding the system prompt like so:

require"codecompanion".setup{
    opts = {
        system_prompt = function(adapter)
            return adapter.system_prompt or main_system_prompt
        end
    },
}

And including special-purpose adapters like so:

proofreader = function()
    return require"codecompanion.adapters".extend("ollama", {
        name = "proofreader",
        system_prompt = [[You are an AI writing coach named "ProofReader".
            You are currently plugged in to the Neovim text editor on a user's machine.

            You can give advice about writing style. You favor clear, precise, and direct writing.
        ]]
    })
end,

This is a bit awkward because I need to duplicate the default CodeCompanion prompt as a local variable main_system_prompt in my config, in order to fall back on a generic coding prompt.

I wonder if it might help to either:

1. Fall back on the default CodeCompanion prompt if the system_prompt callback returns nil, OR

2. Expose the ordinary CodeCompanion prompt somehow in the plugin, so users can fall back on it manually within their system_prompt callback, OR

3. Change the default behavior to check if the adapter has a system_prompt field and use that if it's available.

These changes are, I think, independent of one another, so you could implement any subset of them. However, if both 2 and 3 are implemented, you'd need to decide what happens if the adapter has a system_prompt field AND there's a system_prompt function in place. I think it would make sense to have the adapter's system_prompt preempt the function.

[mystilleef]

Why don't you just create a custom prompt in the prompt-library and use that? Or am I missing something?

[gleachkr]

Ah - OK, I didn't realize that the prompt library had an ignore_system_prompt option. I thought of it as just a way to add to the existing system prompt. Using the prompt-library would be a pretty good alternative option here.

There's one thing that I don't think prompt-library approach covers, which is switching between different adapters. From what I can tell, switching adapters will clobber an initial system prompt:

codecompanion.nvim/lua/codecompanion/keymaps.lua

Line 431 in c0b8c25

-- Update the system prompt

, whereas if the system prompt is set at the adapter level then you can switch back and forth between initial system prompts in mid-conversation by switching adapters.

Maybe change_adapter should inspect whether the chat has ignore_system_prompt set before overwriting the system prompt, and not change the initial system prompt in that case? That wouldn't let you switch prompts, but it would at least avoid removing a prompt that you included intentionally by using the prompt library.

[olimorris]

The RECIPES.md file is up to date. One of my favourite workflows these days is to open a chat buffer and use the /fetch slash command to send a plugin's README or raw init.lua file and then proceed to ping the LLM a tonne of questions about how it works. You can specify an adapter and model for a prompt in the prompt library. You could also look to use vim.g.codecompanion_adapter to set the adapter and check the value of that in the prompt you've created.

If you use Neovim for everything, it's easy to imagine using CodeCompanion for tasks other than coding—for example proofreading emails, brainstorming in note-taking contexts, revising GitHub issues for clarity, etc.

Btw, this is awesome to read. Let me know if you have any ideas for how the plugin could be adapter to better allow for these types of use cases.

[gleachkr]

It already works extremely well for email and revising draft text 🙂 . The main thing that would be helpful (maybe just to me) would be a sense for the "right way" to customize the system prompt for non-coding usage. I see now that the prompt library is probably the way to go, rather than opts.system_prompt, but maybe an example in the documentation of non-coding usage would be helpful for new users?

[mystilleef]

Ah - OK, I didn't realize that the prompt library had an ignore_system_prompt option. I thought of it as just a way to add to the existing system prompt. Using the prompt-library would be a pretty good alternative option here.

There's one thing that I don't think prompt-library approach covers, which is switching between different adapters. From what I can tell, switching adapters will clobber an initial system prompt:

codecompanion.nvim/lua/codecompanion/keymaps.lua

Line 431 in c0b8c25

-- Update the system prompt

, whereas if the system prompt is set at the adapter level then you can switch back and forth between initial system prompts in mid-conversation by switching adapters.

Maybe change_adapter should inspect whether the chat has ignore_system_prompt set before overwriting the system prompt, and not change the initial system prompt in that case? That wouldn't let you switch prompts, but it would at least avoid removing a prompt that you included intentionally by using the prompt library.

You can use different adapters for each prompt you create. Then create a cmd abbreviation or keymap to launch them. That's what I currently do. It's better because it separates concerns and you can even compare the responses of different adapters by switching chat windows. For example, I always have Gemini and Copilot-Claude Chat windows on the ready. And I switch between them at will to compare and contrast responses. The only caveat you need to know is that closing a chat window destroys it forever, while hiding it keeps it running in the background. So map those actions wisely.