Add Ruby Copilot chat agent with domain driven design command

[vinistock]

Motivation

Add a Ruby Copilot chat agent with a domain driven design command (/design for short). The idea of the command is to assist the user in designing a concept into the model and database implementation.

For example, they can ask the following: I'm working on a school web application. How can I model courses? And how do they relate to students?. The chat will then reply with a suggested schema and buttons to run the Rails generate command for the proposed solution. Users can continue chatting back and forth until they arrive at the desired state.

Implementation

The first commit only bumps the VS Code engine and @types package to v1.90, which is the first to include the chat related types we need.

The second commit includes the chat agent implementation. I will add comments in the PR explaining each part.

Manual Tests

copilot_chat_ddd.mov

[isidorn]

Hi VS Code PM here 👋

This is super cool to see 🎉

I am curios if having a @ruby participant is too broad. Imagine the following: I am a new user, and I am interacting with Copilot Chat. I want to learn about Ruby and I ask “How do I create a new Rails application”. This question can get well answered by GH Copilot, but how does the user know if they should use @ruby.
Or - we will have intent detection, and we might decide to forward some user queries to your participant. How do we make sure that we do not "over-send” some questions which you participant does not want to handle.

For example, none of our 1st party language teams are not contributing their participants @python, @java...

So, I would think more about the scenarios, and I like the current /design one. To make sure that the participant is an expert in a specific area where the default GH Copilot sucks.

Just my thinking, curious to hear other thoughts.

[vinistock]

@isidorn this is a really good point and to be honest, I'm not sure where the right balance lies exactly.

The guidelines mention this:

To have a great user experience, we discourage extensions from contributing multiple chat participants

So my rationale was that we would create a @ruby participant with several commands that are related to the Ruby language. To "put it all in one place" if you will.

This PR introduces the Rails domain driven design command, but we could also add things like

• @ruby /ask_rails a command to ask Rails specific questions that pulls in the context from the Rails guides
• @ruby /ask_sorbet a command to ask Sorbet (Ruby's gradual type checker) specific questions pulling context from the docs
• @ruby /ask_workspace a command that would pull all indexed declarations from the language server and then answer questions about the codebase
• @ruby /create_gem a command that would take a bunch of specifications from the user and then expose a button for the user to generate the gem (a package in the Ruby world). This would involve first invoking Ruby's dependency manager (Bundler) to create the basic skeleton and then applying the user desired changes to the specific files

However, for chat interactions that are less specific or that do not require any information about the user's codebase, the regular chat is indeed more than enough to satisfy the user's needs.

How are the Python and Java teams organizing their chat participants? Do you have suggestions on how to organize ours with these possible use cases?

[isidorn]

Thanks for sharing the thinking process. I love some of the ideas you are outlining.

How are the Python and Java teams organizing their chat participants? Do you have suggestions on how to organize ours with these possible use cases?

They do not contribute a chat participant. They are all experimenting with different approaches. I want to brainstorm more with the team next week on the recommended approach for language extensions on extending GH Copilot. But it might be something like:

• Improve the Inline Completions experience (similar to what C++ did in this blog). For this we need to have nicer pluggable story for GH Copilot inline completions.
• (still in discussion) Contribute #ruby variable, that we would automatically append to user queries based on the current file / intent detection. Then you would resolve that variable. This would cover your ask_rails, ask_sorbet, ask_workspace scenarios. Basically you could dynamically resolve it based on the question and provide proper context.
• Help us improve the core Copilot experience for your specific language. Example (we need a cross platform docker-based Ruby diagnostics provider, and tree-sitter queries for ruby that we need for summarisastion of files). The downside here is that Copilot extension is closed source, so I do not know if you want to contribute.
• Only contribute a participant if there is still some functionality that is not improved by the above

Having said this, things are still in the air, and from our side you can go ahead with your current approach to learn and get user feedback.

fyi @roblourens @aeschli

[vinistock]

Awesome! Thank you for context. The idea was always to start with this as an experimental feature anyway, so we'd be happy to change the implementation based on your guidelines.

[dirceu]

Thanks for pushing this forward! This is a worthwhile experiment to run 👍