Thanks for submitting this PR. I appreciate the intent behind it and the effort to improve the structure of the repo.

After reviewing it, I have a few concerns I’d like to raise before making a final decision:

• Discoverability: Introducing another layer of README files (from root to collection) adds friction to navigating the repo. It makes prompts less immediately accessible, which could hinder usability for contributors and users.

• Conceptual Alignment: The idea of “collections” doesn’t currently exist within GitHub Copilot itself. Since this repo aims to reflect and support features that are native to the tools, adding new conceptual layers might create confusion or misalignment.

• Problem Framing: I do agree that there’s a real challenge here—how to represent a “job role” composed of prompts, instructions, and chat modes. That’s a valuable direction, but I think we need to explore solutions that preserve discoverability and stay closer to Copilot’s existing paradigms.

I’d love to hear your thoughts on these points before moving forward. If you have ideas on how to address the discoverability issue or align the concept more closely with Copilot’s current model, I’m open to discussing further.

Thanks for submitting this PR. I appreciate the intent behind it and the effort to improve the structure of the repo.

After reviewing it, I have a few concerns I’d like to raise before making a final decision:

• Discoverability: Introducing another layer of README files (from root to collection) adds friction to navigating the repo. It makes prompts less immediately accessible, which could hinder usability for contributors and users.
• Conceptual Alignment: The idea of “collections” doesn’t currently exist within GitHub Copilot itself. Since this repo aims to reflect and support features that are native to the tools, adding new conceptual layers might create confusion or misalignment.
• Problem Framing: I do agree that there’s a real challenge here—how to represent a “job role” composed of prompts, instructions, and chat modes. That’s a valuable direction, but I think we need to explore solutions that preserve discoverability and stay closer to Copilot’s existing paradigms.

I’d love to hear your thoughts on these points before moving forward. If you have ideas on how to address the discoverability issue or align the concept more closely with Copilot’s current model, I’m open to discussing further.

Thanks for the thoughtful feedback, @aaronpowell,

I completely understand your concerns about discoverability and conceptual alignment. You're right that adding structural layers could create friction.

Perhaps we can solve this with convention over structure, avoiding new conceptual layers entirely. Here's what I'm thinking:

• Filename prefixing: Add category prefixes to prompts (e.g., plan-, azure-, csharp-, blueprint-)
• Documentation approach: Create a simple docs folder explaining workflows and prompt sequences for each category
• Preserve flat structure: Keep everything discoverable at the root level while enabling logical grouping

For my plan category specifically, I'd love to document the persona and intended prompt sequence in a simple markdown file, without changing the repo's navigation model.

This addresses my core need: when setting up a dotnet API, I can quickly identify and copy all csharp- prefixed files. It also helps manage the cognitive load as the repo scales—especially for junior engineers who might find the growing collection overwhelming.

Regarding implementation approach: If contributors agree with this naming convention approach, I'm happy to update the repo to reflect this change. However, since it's a large structural change, it might make sense to put up a second PR with my plan prompts using the new naming convention for now?

Would this approach work better? It maintains discoverability while providing the organizational benefits through naming convention rather than structure.

Perhaps we can solve this with convention over structure, avoiding new conceptual layers entirely. Here's what I'm thinking:

• Filename prefixing: Add category prefixes to prompts (e.g., plan-, azure-, csharp-, blueprint-)

In an early draft of this project, I did go with using "tagging" in the file names to help group similar ones together, but unfortunately it falls down quickly. Let's say you're creating something that's in JavaScript for front-end. Do you have that as javascript-, typescript-, react- or tailwind-? All are most likely applicable.

This addresses my core need: when setting up a dotnet API, I can quickly identify and copy all csharp- prefixed files. It also helps manage the cognitive load as the repo scales—especially for junior engineers who might find the growing collection overwhelming.

There are a few ways that we currently can support a quick setup, there's a chat mode in the repo, and two prompts, which you can use to query the repo and find the prompts, instructions, and chat modes that are useful. Also, one of my team mates has built a MCP server for the repo.

But like I mentioned above, I really do think that some concept of a "role" and being able to create a "collection" of prompts/etc. that support that role does make sense, but it has to work in a way that is still logical and discoverable.

That is a fair point; the naming convention could break down quickly, especially considering the scope being very broad.

I'm going to keep thinking about this. The folders were the simplest way for me, but it's possible I need to wait for the tooling to mature and introduce the concept of collections

During last Friday’s VSCode Live “Let It Cook” podcast, @pierceboggan had referenced ongoing work on a Plan workflow.(the "Blair Witch moment" if you will)

This concept, once introduced, could serve as the foundation for organising a “collection” within an environment.

In practice, the prompts I added to this PR outlined a multistage workflow, where each phase is carefully reviewed and updated to ensure alignment before proceeding.

If GitHub Copilot’s Plan workflow becomes customizable and supports multiple stages, it could be leveraged to group related prompts by persona or category, enabling a more cohesive and guided workflow experience.

The plan I have with what is available now is to wrap it all up in a chat mode that understands the workflow and guides you through it. But having dedicated phases in a workflow would be great for this.

Saying that this same concept would apply to web development. You typically have a workflow you follow, build out to components needed, create a mock endpoint, build out the UI, etc

Most of these could be grouped in a custom multi-stage prompt workflow