Standardizing Copilot Workflows: Combining Prompts, Instructions, Tools, and Chat Modes

[joshkurz]

As I work more with agentic IDEs, especially VS Code, I’ve noticed more use cases that require combining multiple built-in primitives.

These primitives on their own enable powerful automations that can be shared across teams. However, there’s currently no built-in mechanism to combine these primitives into a single module.

For example, if I have a series of prompts that depend on a specific set of custom tools, how can I easily package and distribute them to users?

I’m trying to introduce a more standardized way to package incremental chat customizations into what I’m calling a “workflow.”
A workflow would represent a composable module that includes prompts, tools, instructions, and chat modes, bundled together to achieve a higher-order use case.

Example

Suppose I have a custom chat mode that includes tools, custom scripts, and integrations with third-party systems or APIs. Within that chat mode, I want to provide prompts for the user to run specific tasks, along with instructions for how the agent should behave.
Right now, there’s no straightforward way to package these components together and share them as a single reusable unit.

Proposal

I’d like to propose a new primitive in this repo:

/workflows

Each folder under /workflows could represent a real-world use case composed of any combination of incremental chat customizations.

Each workflow would include:

• A README explaining the use case and installation instructions in standard setup steps. Each workflow should have the same or similar setup instructions.
• The associated prompts, tools, instructions, and chat modes needed to complete it.

This structure would make it easier for teams to implement, share, and integrate complex workflows directly within agentic IDEs like VS Code.

This idea aligns closely with step 5 of the VS Code Copilot customization guide:

“5. Create specialized workflows — For advanced usage, build custom chat modes that combine specific tools, instructions, and context for particular roles or project phases.”
(Reference: [VS Code Copilot Customization Docs](https://code.visualstudio.com/docs/copilot/customization/overview))

[aaronpowell]

I've converted this to a discussion as I think it makes more sense as a discussion that we may generate issues to implement from than being an issue directly.

Part of what you're describing here is what I'd argue we're aiming to achieve with Collections in the repo - having a way to create a correlation between the various types of customisations available to GitHub Copilot through the agentic tools we use it with.

It doesn't cover all the scenarios you mention, particularly arbitrary scripts, but that's something I'd really want to delve into the use cases for as it's the kind of thing that can open up for an attack vector by malicious actors.

As for more of an overarching tool, have you seen Spec Kit? It does have more of a workflow basis in which a series of prompts are used to guide through a workflow that needs to be done to achieve a task. Something like that could be achieved as an external tool that uses customisation files from the Awesome Copilot repo as another approach.

[jeremiah-snee-openx]

@joshkurz Checkout

• Collections Improvement with Tasks Collection POC #270

[joshkurz]

So I actually didn't know collections existed until after I posted this. I was searching for the workflow keyword. Apologies for that, It does seem they are fairly new so I don't feel too bad. 1 month late. Nice job @aaronpowell for noticing the need and adding it in.

I think collections are good and do handle the majority of what i'm trying to solve for. It's a great step for sure.

I think what @jeremiah-snee-openx has added helps as well and makes them more usable from a use case perspective vs just having them collected in one place.

Knowing that I would have probably framed what Im trying to do around two things:

1. How can we bundle scripts and custom tools with our collections?
2. How can we simplify the distribution of a collection?

1: Script and Tool Bundling with Collections

In my experience I have seen a lot of value when I can call scripts from prompts and use my terminal to perform tasks. Our terminals are the ultimate tool, that allows us to do virtually anything. By leveraging the terminal in connection to our prompts we can perform tasks that were not possible before and we can iterate on ideas quicker without having to build another server or integration for every single tool call we want to make.

Example:

If i have a collection that helps engineers debug live production issues. I might have a script that formats logs in a certain way to help make reading the logs easier for the llm. It could do a number of other things but I just want to keep the example simple.

operations-debug.prompt.md

You are a operations engineer. There is a production issue and you need to look at the logs and come up with next steps based on what you find.

Run these commands in the terminal
``
python tools/fetch_latest_logs.py
python tools/error_summary.py logs/app.log
``

Then summarize what the script found and suggest the top 3 fixes I should try first.

Also when you combine the custom tool options in vscode and you use #customtoolcall in your prompt, it creates an even better experience. So if we don't want to include scripts as tools, maybe we include actual vscode tool extensions as part of the collection? Those can be scripts that we call as well, but just a little more formal in how they are called and integrated. Possibly more secure. This would be ok as well and perhaps better, although it adds a little more work to do.

Combining scripts or custom tools with the prompt as a collection helps create a better experience for the engineer using the collection. The user can just install the collection and run it. Reap the benefits of AI + Terminal Integration right away in their IDE.

2. Distribution

If we can bundle these as a single install that would be preferred.
Downloading a collection by installing individual parts is not ideal and creates a higher barrier to entry to use these.

But for implementation of this, i'll leave that for later. I just want to know if we are interested in introducing either of these two concepts into this repo?

Thanks and Thanks for all the awesome copilot stuff yall have done. It's been really helpful.