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.

[wherka-ama]

@joshkurz, @jeremiah-snee-openx, @aaronpowell : I'm very glad I've found this discussion!

I can see a strong convergence in efforts to industrialize the approach for packaging prompt-apps, and my team at Amadeus IT Group has developed something that may help make distribution more user-friendly.

We've built Prompt Registry, which is essentially a Marketplace for prompts with the ability to automatically scaffold repository content with an example collection and corporate-friendly features.

It is as easy as:

1. Trigger the VS Code command to scaffold a new collection
2. Switch to the created folder and customize your prompts
3. Push the content to GitHub (public or private repositories work)
4. Add the repository as a source in the Prompt Registry extension

We're exploring future enhancements such as user profiles with automatic collection recommendations—similar to the VS Code extension marketplace experience.

Here are the links to the extension in the VS Code Marketplace and to the GitHub repository:

Our approach builds upon and extends the excellent foundation provided by the awesome-copilot project. The collection specification you've developed is fantastic, and the content in the awesome-copilot repository is already extremely valuable.

However, we've identified several challenges that Prompt Registry aims to address:

• Private collections: Not all prompts can be shared beyond corporate boundaries
• Installation friction: Installing prompts individually via links is tedious
• Version management: The lack of versioning means no notifications when collections are updated

While the MCP server approach works well for technical users, we've received feedback that some GitHub Copilot users prefer a simpler solution without container dependencies. We believe the awesome-copilot collection format combined with a marketplace-style extension could serve a broader audience.

We'd welcome the opportunity to collaborate with the awesome-copilot community on this initiative and ensure our approaches remain compatible and complementary.

Note: This is a very early version. Things are far from perfect, but it is functional and brings value already.

CC: @dpomian, @KevinNzue

[joshkurz]

Looks awesome. Are you planning to integrate scripts and steps for repeatable tasks that users may want to run? What does a package consist of that I install for a use case I'm trying to solve?

Are you planning to create helper scripts to make it easier for engineers to create new collections based on chat context they have?

[wherka-ama]

@joshkurz: this actually the idea - to create a self-contained app based on skills/competencies. In some cases it would be also possible to extend them.

Apart from the Awesome collections which we start with as a natural and immediate booster of productivity we are also working on more complex scenarios. It includes those requiring workflows and extra resources.

We already have a solid foundation in the form of OLAF(https://github.com/AmadeusITGroup/olaf).

All that needs to be done is to finalise the way competencies are dynamically added to OLAF.
We are already on it. It might take a couple of weeks to release a version that is shippable and extensible via Prompt Registry.

[joshkurz]

I think this discussion is timely because we are starting to see other AI platforms introduce the idea of reusable “skills” that bundle prompts, steps, and tool use into something that can be shared and invoked. This shows there is clear demand for a standardized way to package workflows so that they can be reused and improved across teams.

It would be great for the Copilot ecosystem to have a similar approach where common tasks can be captured in a consistent format, stored in a repo, and invoked from the editor. I think /collections could be that.

We could add workflows to collections. And reference prompts and other preemptives that have already been defined.

collections/
  my-collection/
    prompts/
      pr-review.md
      upgrade-dotnet.md
    agents/
      repo-maintainer.md
      data-cleaner.md
    workflows/
      upgrade-all-services/
        steps.md
        scripts/
          find-services.sh

• Workflows reference prompts and agents through refs, so they stay decoupled and reusable
• steps can mix human guidance (steps.md), scripts, and agent tasks that consume referenced prompts
• builds on top of what has already been done

[bakosa]

Interesting idea, I built a new project like spec-kit as you are mentioning above @aaronpowell with a bunch of prompts that are ment to be executed in a specific order to solve a specific problem. Each prompt is tied to a phase of the process that humans take much like how and why spec-kit is broken up the way it is.

I feel like having some workflow or "playbook" (like Devin) makes sense in this project as well.

For example, @aaronpowell you added the new partner JFrog security agent. I feel like there could be a handful of prompts to help patch vulnerabilities, but perhaps it is a broader workflow or playbook of multiple prompts to achieve that, and they leverage that custom agent.

At the end of the day, engineers follow many reusable processes or playbooks to achieve some outcome. Many of those are broken up into phases/prompts much like how spec-kit is broken up. I get the idea of collections here, but how might we make it more consumable if there are many prompts in a collection? What if they are intended to be used in some order to produce some desired outcome?

Just thinking out loud a bit here, I have been thinking about the same tradeoffs with all of this stuff on some internal repos and I have been looking at both awesome-copilot and spec-kit for inspiration!