Chat: Support custom attachments for participants

[bwateratmsft]

Right now, in Insiders, the currently-opened editor is included as an attachment in chat requests. The user can easily disable it by clicking.

Certain participants (thinking about @azure particularly) would benefit from being able to default-attach their own items in this list. For example, for @azure, attaching azure.yaml by default (if present) would help with a multitude of user questions. We can attach it automatically today, but we cannot make it show up in the attachments list and allow the user to detach it easily for queries where it is unhelpful.

Implementation-wise, perhaps if, after typing @azure, a method can be called to resolve additional attachments?

/cc @isidorn

[isidorn]

This sounds reasonable to me. What do you think @roblourens

[roblourens]

That's something that I don't like about the current implicit context, it doesn't really capture all the implicit context. Not sure whether I want to try to spell everything out or just rely on participants to report references but I'll keep thinking about it.

Do you currently return a reference for the files you use?

[bwateratmsft]

Right now we're only using attached files, we're not auto-attaching anything. Auto-attaching felt like it introduced wrong answers but with no way to detach the file causing the wrong answers. For example, when we auto-attached azure.yaml, and asked what ports the app listens on, it would try (and fail) to find the answer in azure.yaml. Instead, we wanted it to query our workspace context plugin (which essentially just calls the copilot_codebase lmTool underneath)

[bwateratmsft]

Any updates on this?

[roblourens]

You might be able to make some progress on

it would try (and fail) to find the answer in azure.yaml

with some creative prompt crafting rather than relying on the user managing it. I know that we went that direction for the open file, but just telling the LLM something like "this piece of context might be relevant to the user's query, if not, try doing xyz" can help a lot sometimes. Or you might consider using tool calling to let it decide whether it needs that context or other context.

I'd still consider this, I think we are developing some precedent with the "file suggestions" in the edits view. But some API with a new feature like this wouldn't happen quickly.

[kvenkatrajan]

"this piece of context might be relevant to the user's query, if not, try doing xyz"

Thanks - we will give this a try in the interim

[JasonYeMSFT]

We can try this for the next kind of implicit reference we want to add but probably not for azure.yaml right now. Our workspace plugin currently fetches not only the codebase query results, but also azure.yaml results from azd show command which has covered its needs.