Support .github subfolder with server-side editing

[isc-fpulv]

We use server-side editing with ISFS and use the _vscode web application as the virtualization of the .vscode subfolder. This works great and it makes it easy to share snippets.

We've recently rolled out Copilot. We'd like to have department-based and team-based instructions/skills to be shared among the developers. The default folder Copilot looks for is the .github subfolder. We currently include the .github subfolder by manual configuring the folder into the workspace.

Suggestion
Support a .github to _github virtualization mechanism. This will facilitate deployment of common instruction/skill files.

[isc-bsaviano]

Thank you for opening @isc-fpulv. I am not a fan of the way we currently map the .vscode to _vscode. I'm glad you find it easy but I've always found it clumsy and unintuitive. I definitely see the value in this sort of mapping though and would like to explore alternate ways to provide it before extending it to .github as well.

cc @isc-rsingh

[isc-fpulv]

Thanks for the quick reply.

I'm happy that you see the value. I simply suggested this approach because it conforms to the current design. I don't mind if the mechanism to virtually represent the subfolders evolves.

[gjsjohnmurray]

@isc-fpulv did you consider using the chat.agentSkillsLocations setting to point VS Code at, say, .vscode/ourSkills?

Unfortunately it looks like this setting cannot be done in the server-hosted .vscode/settings.json file, so every team member will need it in their user-level settings or in the code-workspace file holding the isfs:// url(s).

I'm not opposed to extending the current mechanism (invented by me) that projects a server-side file-tree from under the /_vscode webapp as a client-side .vscode subfolder of an isfs-type workspace root folder. But it seems .agents would be a more neutral choice than .github.

@isc-bsaviano sometime I'd like to understand what you find "clumsy and unintuitive" about the mechanism. Granted, it takes a bit of work to set up, but my IPM package can be used to simplify this step.

[isc-bsaviano]

@gjsjohnmurray I'm not a fan of having to set up a web application, or that it requires that a user have %DB_IRISSYS:R to function. There's also the issue that the settings aren't really folder-specific; they're namespace-specific. We haven't gotten any issues related to that discrepancy so maybe server-side users don't care about the mismatch, but it's still there. I'm not advocating that we remove this feature without replacement; it's certainly better than nothing. However, I do think we should be honest about the limitations before expanding it. I can see a future where users expect skills to be folder-specific but they actually get all the skills in that namespace and it leads poor code generation or token burn.

[isc-fpulv]

Good question, @gjsjohnmurray. Yes, I have tried location settings and tried to guide github to settings via _vscode. Both requiring manual intervention with limited success. My goal is to be able to implicitly serve the files github wants from where it expects them to be.

.agents seems like it should work. I'm happy to test it out.

Since we're discussing the mechanism as a whole, your comment re. .agents raises another interesting point: Would it be useful to consider a generic means to serve a dot subfolder? In the form of the current mechanism, configure a 'dotsubfolder' application and rearrange the compiled uri to /dotsubfolder/${namespace}/<requested folder without the dot>/. For example, /dotsubfolder/USER/vscode/'. Possibly with a whitelist of subfolders if the suggestion is too open. This way, you won't get a following suggestion from someone asking for .claude`. It would also future-proof for the next fantastic extension that insists on having a specific dot subfolder.