OASF Extention for "chat modes" like in VSCode

[jubarbot-cisco]

Hello team,

VSCode supports Chat Modes (https://code.visualstudio.com/docs/copilot/chat/chat-modes).

It's a combination of:

• description
• list of tools
• model
• description of the mode in markdown

---
description: Generate an implementation plan for new features or refactoring existing code.
tools: ['codebase', 'fetch', 'findTestFiles', 'githubRepo', 'search', 'usages']
model: Claude Sonnet 4
---
# Planning mode instructions
You are in planning mode. Your task is to generate an implementation plan for a new feature or for refactoring existing code.
Don't make any code edits, just generate a plan.

The plan consists of a Markdown document that describes the implementation plan, including the following sections:

* Overview: A brief description of the feature or refactoring task.
* Requirements: A list of requirements for the feature or refactoring task.
* Implementation Steps: A detailed list of steps to implement the feature or refactoring task.
* Testing: A list of tests that need to be implemented to verify the feature or refactoring task.

As there is already an OASF MCP extension that is also used to import MCP servers configuration into VSCode, is there an current work regarding creating a "Chat Mode" OASF extension ?

Maybe there is already an OASF extension which convey such a concept ? Or maybe a combination of already existing OASF extensions can achieve that ?

Can you give a little bit of guidance about how I could implement that ?

Thank you very much.

[jubarbot-cisco]

Maybe creating an OASF record including those extentions is enough ? :

• https://schema.oasf.outshift.com/0.5.0/features/model
• https://schema.oasf.outshift.com/0.5.0/features/prompt

I'm missing the "list of tools" part though.

[jubarbot-cisco]

So, we are balancing between reusing already existing extensions, and creating a brand new extension.

• I have difficulties in understanding what OASF is for IF everytime we have a new need for a feature, we create a new extension. OASF will end-up in being a big repository of unrelated, very specific, extensions.

On the other hand:

• Creating a brand new extension, for this specific use case (VSCode chat mode) is explicit, we really know what it's about and it can be misused.

So, I'll do the later, as you proposed: creating a new extention, this new extension will have a new 'VSCode Chat Mode' type, that will be composed of 2 already existing attributes (LLM Prompt + LLM Model) a string (Description) and a list of tools.

With that I'm reusing some of the already existing OASF components (the 2 attributes), while I'm also creating a new extension.

Those questionings are mainly because I'm trying to be inline with the OASF purpose.

[jubarbot-cisco]

• Here is a first draft, what do you think ? feat(schema): add a new vscode chat mode extension #268

• Unrelated remark: I looked at the OASF schema contribution documentation and realized that https://docs.agntcy.org/oasf/workflow/#oasf-extensions needs to be updated:

  • The link to the OASF Extensions Registry (to register a new number) points to the empty extensions.md file
  • The end of the https://docs.agntcy.org/oasf/workflow/#create-your-extensions-subdirectory paragraph make us believe something is missing (it end with a colon).

[ramizpolic]

I have difficulties in understanding what OASF is for IF everytime we have a new need for a feature, we create a new extension. OASF will end-up in being a big repository of unrelated, very specific, extensions.

OASF is a schema framework as described in the README. It is not true that an extension is ALWAYS needed to support a specific functionality. An extension MAY be needed, but it is not always the case. The extensions are meant to encapsulate logic in a generic way so that building things with it does not restrict the usage of a specific extension.

Creating a brand new extension, for this specific use case (VSCode chat mode) is explicit, we really know what it's about and it can be misused.

Although this is true, naive implementation creates a lock-in for a specific functionality which can easily bloat the schema. There are many primitives in OASF where a given logic can be supported by leveraging existing extensions. As per my suggestions, rather than developing VSCode-specific extension, it is possible to extend/leverage existing extensions so that a given functionality can be supported. This way, an agent mode usage is no longer tide to VSCode only, but can be extended to other applications.

Here is a first draft, what do you think ? #268

I think this is okay, but again, I would not tie this explicitly to VS Code. Instead, this can be a new generic extension for Agent usage which can reside inFeatures/Runtime/Usage. I would suggest trying to generalize this so that it can be leveraged by other tools out there (CLI, VIM, JetBrains, whatever).

[ramizpolic]

On the last note regarding docs @jubarbot-cisco, could you please open an issue under docs repo so that this can be tracked and sorted out

[muscariello]

I agree with @ramizpolic and I would add the this proposal is not leveraging the framework at all.
The point of having MCP servers and A2A extensions is that a data model like this one for VSCODE GH copilot agent (this should be the name BTW, as it's not all VSCODE) does not leverage existing records. This data model does not leverage composition.
But it must. Otherwise OASF would become a collections of schema and not a schema framework.

[jubarbot-cisco]

@ramizpolic, @muscariello: Thank you for taking time to answer my questions. I totally got your points, and I totally agree, hence my first remark:

I have difficulties in understanding what OASF is for IF everytime we have a new need for a feature, we create a new extension. OASF will end-up in being a big repository of unrelated, very specific, extensions.

My first try was with a record containing 2 extentions: schema.oasf.agntcy.org/features/prompt and schema.oasf.agntcy.org/features/model, where I was missing the list of tools.

So, it becomes like duck-typing, "if it's a feature/prompt and it's a features/model then it's a vscode gh copilot chat mode". No new extension.

If that's how OASF is meant to be used, then I'm good with that.

Now that this is decided I have a new concern.

What if ANOTHER record, totally unrelated to VSCode GH copilot Chat mode, contains those two extensions ? I may incorrectly use it in the vscode extention. So, how can I be sure it is originally meant for vscode ?

Should I use the annotations field ? Something like {"vscode": true, "emacs": true}. The risk of doing that, is again, to start to put anything in annotations.

Now for the tools_list, (It's a list of strings). It's either part of a new extention, or part of an already existing one.

So @ramizpolic is proposing in #241 (reply in thread) to either:

• (1) create a new extension composed of already existing types
  or,
• (2) to update an already existing extention so that it can contain the list of tools.

(1) is what I drafted, with a too specific name, that I can generalize, with a new name and with more generic descriptions
(2) feels more or less like "creates a lock-in for a specific functionality which can easily bloat the schema" -- Ramiz

@muscariello: I don't understand when you say that what I drafted "does not leverage existing records". It uses 2 existing records:

• model: https://schema.oasf.outshift.com/0.6.0/data_types/model (for some reason this link timesout)
• prompt: https://schema.oasf.outshift.com/0.6.0/objects/prompt

So, if I understand correctly, @ramizpolic would prefer a new extension (a more generic one than the one I drafted), and @muscariello is more going toward NOT creating a new extension but having a record with a set of already existing extensions.

Thanks again for your time.

[muscariello]

Never said NOT to create a new extension. You MUST create a new extensions. But a modular one.