Say I have a custom language that is based out of XML. Code is written in this XML based language, and this is fit as an input to a server, which runs code in Java or C++. Now this language has got some documents that describe the rules syntax and all the cons available in it. So given a specific scenario in a prompt it should be able to go ahead and write the code in this language. So the situation is, we have a bunch of documents. We also have the C++ or Java code base and we might even want to use some additional resources here and there and write this code. How to achieve this in an agent, and this should be running in get up copilot using the models available there.

Claude Opus 4.7

Answer: Build a GitHub Copilot custom agent (via a `.github/copilot-instructions.md` plus a Copilot Extension or Coding Agent setup) that grounds the model on your XML-language docs through a retrieval layer (MCP server or indexed workspace), references the Java/C++ codebase as context, and uses Copilot's available models (GPT-4o/Claude/o1) to generate and validate the XML code.

Here is a concrete architecture that fits inside GitHub Copilot using only the models it exposes: 1) Put everything in one repo (or a workspace Copilot can see): - `/docs/` — the XML language specification, syntax rules, list of constructs, examples. - `/server/` — the Java/C++ source that actually executes the XML. - `/examples/` — known-good XML programs and their expected behavior. - `/schemas/` — an XSD or RelaxNG for the XML language (generate one if you don't have it; this is the single biggest accuracy lever). 2) Ground Copilot with `.github/copilot-instructions.md`. This file is automatically injected into every Copilot Chat/Agent request in that repo. In it, describe: what the language is, where the spec lives, where the executor code lives, coding conventions, and a rule like "Always validate generated XML against `/schemas/lang.xsd` and cite the spec section you used." This alone dramatically improves output without any extra infrastructure. 3) Add retrieval so the model isn't guessing. Two options inside Copilot today: - Easiest: rely on Copilot's workspace indexing (`@workspace` in Chat, or the Coding Agent which indexes the repo) and reference docs explicitly with `#file:docs/spec.md`. - More robust: stand up an MCP server (Copilot supports MCP in Agent mode) that exposes tools like `search_spec(query)`, `get_construct(name)`, `validate_xml(xml)`, and `run_in_sandbox(xml)`. The agent calls these tools instead of hallucinating syntax. Point it at your docs via a simple vector index (e.g., embeddings stored locally) plus a direct XSD validator. 4) Make it a Copilot Extension / Coding Agent, not just chat. Define an agent (in `.github/agents/` or via a GitHub App Copilot Extension) whose system prompt encodes the workflow: (a) read the user scenario, (b) retrieve relevant spec sections, (c) look up how the Java/C++ executor handles the relevant tags to confirm semantics, (d) draft XML, (e) validate against XSD, (f) optionally execute against a test harness, (g) return code plus citations. The Coding Agent can open a PR with the generated XML and a test result. 5) Model choice: in Copilot you can pick from GPT-4.1/4o, Claude 3.5/3.7 Sonnet, o1/o3-mini, Gemini. For DSL generation, Claude 3.5/3.7 Sonnet and GPT-4.1 tend to do best on structured XML with long spec context; use o1/o3 for tricky reasoning scenarios. Let the user switch models from the Copilot model picker — no code change needed. 6) Close the loop with validation. The non-negotiable trick for DSL generation is: schema-validate every output and feed errors back to the model for one or two repair iterations. Do this as an MCP tool so the agent self-corrects before showing the user. Net result: the heavy lifting is (a) `copilot-instructions.md` for grounding, (b) an MCP server exposing spec-search + XSD validation + optional sandbox execution, (c) a Copilot Agent definition that orchestrates retrieve → draft → validate → repair, all running under whichever Copilot-hosted model the user selects. You don't need to host your own LLM; you just need to feed Copilot's models the right context and tools.

Final Summary

The AI Roundtable proposed a robust architecture centered on GitHub Copilot’s extensibility features to handle custom DSL generation. Claude Opus 4.7 recommended using a combination of workspace indexing for documentation, .github/copilot-instructions.md for grounding, and an MCP server to provide real-time validation against XML schemas and the underlying C++/Java semantics.

1 of 1 model agreed