Supporting/integrating project-specific prompts

[3ZsForInsomnia]

Like many CodeCompanion users, I write software for a living. And like a lot of teams probably are doing these days, my team and I want to be able to share prompts easily. I am not sure if this is something that CodeCompanion itself should have support for, and I am 100% fine with creating a solution within my own dotfiles. If the latter, I would like some input on a hopefully more-optimal-than-naive solution for doing so.

As an example, right now my team has a PR up for a file to support VS Code's chat mode, in .github/chatmodes/golang.chatmode.md. There are some potentially VSC/MCP server specific things in this file (we have a list of tools in ours, tools: ['codebase', 'usages', 'vscodeAPI', 'problems', 'changes', ...etc, along with a description), but the rest of the file is a prompt that I figure I could make available for myself in CodeCompanion. I also figure the description and tools list could be converted into a format I could use in a prompt for CodeCompanion.

I figure there are a few ways I could do this without anything depending on functionality or behavior within CodeCompanion, and a couple ways that might well depend on behavior in CodeCompanion.

Approaches

First Option, the simplest

I could simply copy/paste the prompt and add the tools manually in a string in my config.

This is not ideal as any changes to prompts or new prompts must be handled manually. Not terrible, but it would absolutely work as expected.

Second option, more automatic

I add code to detect matching *.md files within .github to my config function for the CodeCompanion plugin, extract the prompt section, and add that to my config.

This is pretty doable, and avoids the manual-ness of the first option. Converting the prompting format from VSC's to CodeCompanions is trivial with a little Lua code.

However I figure there are ~3 ways to handle updating and loading the config from there:

First

I could run this search + conversion on plugin load, using the config function in Lazy.

Second

I could let the plugin load normally, and then grab the config as it currently is using require("codecompanion.config"), add the converted VSC prompts to the custom prompts in the config object, and call setup again with the result. It appears I get an error about using a config that contains constants when I try this locally, however if I just set that to nil before calling setup again, it seems fine.

I could also use project config setups like exrc, neoconf, etc to help support this.

The one issue I see is, I am not aware of potential issues with calling setup a second time after the plugin loads, but that doesn't mean side effects don't exist. This might be fine, it seems fine, for now at least.

Third

If there was a command to add a prompt to the currently available custom prompts, that could also work. That would feel like a more "officially supported" way to add prompts from a specific project than patching the config object and re-calling setup. This could also totally sidestep concerns over calling setup a second time.

Fourth

I am sure there are other ways to do this that I haven't thought of or am not aware of yet! I tried searching the docs, issues and other discussions for information on how to approach repo-specific prompts, but didn't see anything - but obviously, that doesn't mean it isn't there or that others haven't solved this problem already.

[olimorris]

I can't say I've ever seen what VS Code chatmode looks like. So if you can share what you're working with or the structure, that would be great.

We could Tree-sitter to parse the file and add it to the prompt library list or simply have a slash command to add it to the chat buffer.

[3ZsForInsomnia]

I haven't personally used it myself either, but it is basically just a preconfigured combination of model+tools+prompt for working with AI (GH Copilot specifically, in VS Code).

A chatmode definition can optionally specify a list of tools, optionally specify a model, and must provide a use-case specific prompt. For example, such a prompt might be setup specifically better guide AI when working with your team's backend golang code. So, not too dissimilar from a prompt in CodeCompanion's prompt library.

https://code.visualstudio.com/docs/copilot/chat/chat-modes#_chat-mode-file-structure for more detailed information.

I am primarily interested in the prompt portion currently, given that that feels like the "core" thing here that, at least in my particular case, is what I and my team want to share. I am not 100% sure about if the full set of tools available in VS Code is available outside of VS Code.

I love the idea(s) of parsing with Tree-sitter and adding the prompts automatically or by command.

Example Chatmode definition:

// .github/chatmodes/golang.chatmode.md
---
description: 'This mode is for developing Go services.'
tools: ['codebase', 'usages', 'vscodeAPI', 'problems', 'changes', 'testFailure', 'terminalSelection', 'terminalLastCommand', 'fetch', 'findTestFiles', 'searchResults', 'githubRepo', 'extensions', 'runTests', 'editFiles', 'search', 'runCommands', 'runTasks']
---

Context
- Monorepo is migrating to Nx. Prefer new apps in `src/libs/backend` and libraries in `src/libs/backend` (some legacy code remains outside).
- The primary database is <database>.
- Azure Service Bus is used for messaging across systems, while the database is used for internal queuing.
- Auth0 is used for authentication and nginx ingress controller routes to the auth service for token validation.
- There are integrations with <integration x>, <integration y>,  and <integration z>.

Coding Instructions
- Keep functions small, well-named, and focused; favor readability, maintainability, and modularity.
- Keep `api.go` and `endpoints.go` limited to route wiring and minimal glue code.
  - Do not add new handlers/utilities directly to those files; create focused files/packages and reference them.
  - If adding significant logic to existing functions there, extract into separate functions/packages.
- Observability and errors: use the logger in `src/libs` with structured fields; surface safe errors; integrate Datadog when appropriate.
- Feature flags: use the in-house <feature flag tool> client.
- Security: validate all external inputs; avoid sensitive data in logs; use safe DB operations.
- Lint: pass `golangci-lint` with no new issues.
- Tests: add/update unit/integration tests as appropriate; keep them small and fast.
- Write modular, reusable code with clear boundaries.
- Maintain proper use of Gin and Gorm.
- Avoid deprecated tools/patterns (e.g., `tkt`, `ecologger`).
- Do NOT add comments that are obvious or redundant.

[3ZsForInsomnia]

As a heads up, I might try creating an extension (or at least, an MVP of one) that can do this over the next week or two, depending on the time I have available.

My current plan is to use either Treesitter or yaml.nvim (or just simple Lua patterns maybe) to get the model/tools/description values for parsing. It'll allow a configurable list of directories to search off of the git root for the current repo, search those directories, and ingest them as chat strategies by directly updating the codecompanion.config.prompt_library. I'll expose a command users can use in an autocommand or run manually.

Any objections or suggestions? Partly I am just doing this for fun and games, but maybe it'll turn out nicely enough to be useful.

[olimorris]

Sounds great. I will be very keen to test out what you build with a view to putting into core CodeCompanion at some point.

Configurable directories sounds very sensible. From a UX perspective, would it be better to have a slash command that adds the definitions to the message stack in the chat buffer? I imagine you could do /modes in the chat buffer, a vim.ui.select could appear listing the files in the directories, you could multi-select them if required (like you can with /buffers or /files etc) and add them to the message stack. That way, you don't need to revert to the prompt library and creating a new chat everytime. You'll also have the benefit of being able to share all of the existing slash commands with an LLM and get it to build out an MVP super quickly.

[3ZsForInsomnia]

Ok, here is a rough (second draft?) MVP: https://github.com/3ZsForInsomnia/vs-code-companion. So far it seems to work quite well, I really like using it :)

But there are a couple caveats:

1. Tools do not map 1:1 between VS Code and CodeCompanion, so right now I'm just adding full_stack_dev whenever there are tools listed in the VS Code prompt found/selected.
2. I probably need to fix the model names mapping.

However as said, I really liked using it so far. I have both Neovim commands and CodeCompanion slash commands to import all prompts found in the configured directories or to allow searching + selecting from the prompts in those directories. Right now it auto-adds the selected prompt when using the selection setup, and creates slash commands prefixed with vsc_ when using the import setup.

Thoughts?

Separately, I am wondering about extracting the Telescope/picker setup as a way to preview prompts into its own "thing" since I am finding it is actually a pretty nice UX to be able to see the prompt before selecting it. E.g. I might create something that shows markdown file of prompts, and a similarly styled representation of prompts the user has configured within CodeCompanion itself, within the preview of Telescope and other pickers.

[georgeharker]

I just found this whilst considering writing something similar - and this is fantastic!!