localm™TUTS
FollowFollowSubscribe
💻Video + Code Examples·25 mins

Surface Strategy: Copilot, Claude, and Codex

Build a portable context layer that works across GitHub Copilot, Claude Code, and Codex by separating shared project knowledge from tool-specific wrappers.

Surface Strategy: Copilot, Claude, and Codex · 25 mins
Instructor:Lesson Seven: Surface Strategy. Your team spent weeks on Copilot instructions and agents, and then someone opens Claude Code. And none of that context exists. This lesson fixes that. We will cover which config file each tool reads, how to share knowledge across the tools, and three ready-to-use folder designs. Chapters are in the description if you want to jump ahead. Every major AI coding tool reads a config file from your repo. Same idea, different file names, different hierarchy, different structure. Here is the full picture: nine formats and seven tools. Look at the "Also Read By" column. That's the portability story you are focusing on. AGENTS.md is the closest thing to a universal standard. Around sixty thousand open-source agent repos, and proprietary agents, actually use it.
Instructor:Codex reads it first. Claude Code reads it as a fallback. Cursor picks it up too. Copilot has its own stack. Copilot-instructions.md for the global rules, then scoped instructions with globs, and agents, skills, and prompts, which we already saw in the previous lessons. They complement AGENTS.md. They don't replace it. Here is the core idea: separate what is portable from what is tool-specific. For example, the portable base is your AGENTS.md plus docs. Every tool we use reads that. Put your build commands, tech stack, and conventions there. Tool layers: Copilot gets .github/, Claude gets CLAUDE.md, Cursor gets .cursor/rules/ for its rules. Each of them has only what that tool needs. And you know what's the best trick? Just imagine the object-oriented programming. A CLAUDE.md can follow AGENTS.md and add Claude-only extras there.
Instructor:Don't duplicate the knowledge. That's the key. One source of truth, not ten replicas per tool. We will walk through a fantastic example just in a moment. But before we get there, why do we need this? That question should come. Why do we need two? Can't we just stick with one? Yes, we can stick with one. Well and good. This stays there. But that's not a practical thing. Different providers develop different kinds of backend capability with the model. For example, Claude Code is good at the long-running sessions, deep session reasoning, while Copilot is a much more balanced approach. It is cost-effective, economical, and also very effective, and has many other models to offer under one umbrella. Codex is brilliant when it comes to backend programming. Cursor is great when it comes to UI.
Instructor:And the future will always belong to specialized tooling and specialized systems. So we cannot, first of all, rule out that our project would need these more specialized AI capabilities, such as how a regular team has a UI developer, backend developer, database expert, and so on. So we must keep that in mind. The second thing is protecting our own economy and sovereignty. For example, today, when Claude released Opus 4.7, Opus 4.7 is around twice as costly as the previous version. The reason is the tokenization now is different, and it consumes a lot of tokens. Most of my team has gone by quota after two requests there. The potential quota was filled, and now they cannot use anything else. And this is the real issue: what if your organization somehow is banned from Claude? How are you going to migrate all of your projects? So these are the very essential things, that you are de-risking your project from one provider.
Instructor:And as an enterprise, this should be on top of the list. You should not rely on just one provider. Your goal should be to be capable of working with many, at least two or three providers. Ideally three, but if not three, then at least allocate two, so you can switch between them. Then there is another thing: not every agent or agent system, their backend, their servers, are going to give you one hundred percent availability. We see roughly around eighty-nine to ninety-five percent availability across the different platforms. And that means, what will happen if your system is down and you absolutely need them? You would need an alternate path. So this also gets into the redundancy and capability that your overall team and enterprise would need. And that's why this is absolutely essential for any team to focus on these parameters.
Instructor:So now let's go, first of all, into Visual Studio Code and see what we have done. So here in our Visual Studio Code, and we got this lesson eight. Sorry, lesson seven, that is Surface Strategy. Let me turn off lesson eight first. Surface Strategy, and you can see I got Claude and I got GitHub. We will keep that simple, simple, so we understand what it looks like. This is a sort of mini solution that we internally use in my companies and my team. We write a wrapper Python file, and the wrapper Python file basically looks for one common project, which is templates, and then the contexts that it would need. So, for example, my context is not duplicated across the Claude or GitHub folders. We write one standardized context in .code.agent. That's our solution folder,
Instructor:and then we have written all the templates that we would need to output, transformed into agent-specific files. Very simple, straightforward. I have a graph.json that tells us where exactly this context needs to be dropped. It's a very straightforward architecture, and transform.py does this as a wrapper class. Very simple architecture, and let's try to run this. And I'll just go on by transform.py --write. When I write it, it just generates the files again. If you see, this context guards and others, they will ensure that every time Claude or anyone is running, it will just refresh. So no matter what, or no matter where, we update our actual context, it will always propagate either across GitHub or Claude agents and make sure it always remains up to date. So first, we have solved the first problem. The tool-specific files are generated like that.
Instructor:Then we have the docs. Docs are pretty much common. We follow a baseline process of creating docs, which are easily accessible, by keeping in mind that context is not always discovered one hundred percent. Generally, Claude looks for up to fifty to sixty percent of the code that you provide in a certain amount of tokens in one go. So, if your documentation is, for example, quite large and bulky, it will not work. So it's always suggestible that you make it discoverable. So, always multiple layers of the graph can keep exploring different sets of the context when it needs. So on demand they become available to your process, and this works perfectly accordingly. So, we have managed the tool-specific using an automated process.
Instructor:We have managed the project-specific using the docs, and docs are also pretty much graph-populated in this tool-specific. So, when they come from an agent, the agent will link to the tool, and then tools will link to this particular doc, and that's how the graph is explorable. However, there is one important aspect: the skills are also pretty much common now in agents like AGENTS .md. In our use case, we recommend using a good skills open-source repo or CLI function, which can offer you the multi-tooling capability where it can enable the skills into multiple tooling folders. For example, here we are using the Microsoft repository called APM, and I have enabled something called Agent Skills Marketplace. So, Agent Skills Marketplace, I'm just searching Terraform agent, sorry, Terraform skills, and yeah, we got a Terraform skill.
Instructor:So, what I do is, I'm going to install this Terraform skill, and let's see if it comes right now. There is no Terraform skill in Claude or here. Now, let's see, and I'm installing the Terraform skill. And you will see it will automatically propagate the skill into those multiple parts. You can see here it is already integrated into it. So it's very easy for you when you use this common agent CLI which can actually help you to maintain multiple agent standard structures, which will also enable the skills and some other capabilities that agents would need. In a sort of a transparent manner, you won't need to work or worry much about dealing with artifacts within themselves. So this is the overall architecture of how we are managing in our system. And this is pretty much standard across any advanced team.
Instructor:Most of the enterprise advanced teams actually use two coding agents. So there is one thing we spoke about here: the hooks. In the last lesson we spoke about the hooks and how the hooks actually work for guarding. Here we are ensuring that guardrails make sure that context updates and context availability are always at parity across the tool. That is very simple. If we do not have an automated process that keeps the synchronization between these two folders, or these two coding agents, then they might have outdated references in one of them, which means when we update GitHub it might work in a different way, and when we update Claude it might go the other way. And that is a big, that is one of the risks, especially when we are dealing with a polycode architecture.
Instructor:Then, when you are dealing with a polycode architecture, the hooks are essential. There has to be the same guarding process, and a process that ensures that the context remains in sync between the multiple coding agents. And that's what I wanted to demonstrate here. There isn't something much on this code that we will run. Previously, we have demonstrated everything in terms of context, how the context discovery works, and everything, and the guardrails. So in the Surface Strategy, I will show basically how we can work with this multi-tooling architecture and multi-tooling structure. This is precisely the end of the demo here. So let's go back on the presentation and understand where we are and how it works.
Instructor:So the application I showed you is common architecture. It doesn't mean that this is something unique to DevOps. You can use JavaScript or any other simple scripting, scripting logic, to actually build what we have built. We have given a small subset of the tooling that we did. We use the orchestration agent on top of this CLI and our Claude or GitHub CLI in order to control this whole architecture in a more sophisticated way. But if you are not using the orchestration method, then you can still manage with the hooks and other things which will take care of that synergy and synchrony between multiple tools. Here, as a simple flow, everything starts in .code.agent. You can have any name you want, but we gave it .code.agent.
Instructor:I have /context, API entity, backend rules, frontend rules, testing, everything within plain markdown. That markdown is also parsable by us. So every title in markdown becomes the variable for the template, and we can easily transform the markdown into templates. So you can decide what design, what sort of portability you want, and that's pretty much the flexibility that you have. We got a graph.json which decides what paragraphs and what context will move to what particular location for particular tools. So it's generally a mapping diagram, or I would say a map file, which ensures that the template generates the correct code at the correct file location. It's just a simple knowledge transfer to the right path, nothing more than that.
Instructor:Templates hold the shell for each output file, the way the output file is supposed to be generated. The placeholders for content, generated notes, and everything are automatically there. And it always works with the correct markdown notices. As a command, between the command sections it replaces the right knowledge and context and keeps the things clean. The transform.py file is basically a script that loads the graph, reads the context files and templates, and writes the final output. Think of this as the compiler step of your context. The script generates Copilot instructions, .md, scoped instructions, agents, skills, prompts, etc. Now here is one advanced step. We also deploy a very powerful localization. So when we actually manage our orchestrator, we do all of the locality-building parameterization to make sure that it captures the content
Instructor:based on each and every request. Because we do not want to expose an agent request to over- and overflow the context. That's how we actually push our quality of AI coding a little further. You can use this technique to generate dynamic and runtime context. That's a very powerful pattern, especially if you're working with enterprise software that owns millions and millions of lines of code. When you create a subscope or a low-sneak boundary and ask an AI agent to work with it, they actually make far more magical outputs than working with large-scale context and a lot of files because the load, number one, costs us due to more token usage, and number two, more tokens doesn't mean that it will deliver a better output.
Instructor:More tokens generally mean the inferior outcome and hallucination, and, somewhat I would also say, it could lead to drift as well. So it never touches the roadmap in our case. Some source material also produces AGENTS.md, CLAUDE.md, and Claude rules. One set of facts and multiple native tool outputs. We have the stable two switches. If you're using our example, which is available in GitHub, and the link is available in the description as well, you use switch --write to regenerate, or switch --check to flag whether generated files have drifted or not. We have a very strong deterministic as well as the LLM-based drifting logic, which actually can go into LLM and validate whether context semantically drifted or not, or whether they are differently exploitable, because we also need to make
Instructor:sure that both sets of context are equally exploitable. There is no point that context exists, but in one tool it is discoverable and in the other tool it is difficult to discover, which will also create a disparity across that. That's how you keep things in sync. We have a nice design to copy. We use all of these three. In our team, some people use Copilot plus Claude Code. I personally use Copilot, Claude Code, and Codex already, the full spectrum. Copilot for IDE completion as well as Copilot for the majority of my daily work. Copilot is one of the most efficient capabilities that exists right now in enterprise terms. Then Claude for terminal work and more advanced and long-term agent-running tasks. We use Codex for a lot of background tasks and also the backend, and the complex programming and reasoning tasks.
Instructor:This all has their own capabilities and own strengths, and we use them across our board for what they are best suited for. AGENTS.md is the shared base. Each will get its own layer on top of it. The Design B somewhere is used by our designer team. Cursor and Copilot, they love this. Dual IDE. AGENTS.md is shared and Copilot uses the instructions folder, while Cursor uses the rules folder. Design C is something some of our quant agents and others use, which is AGENTS.md with Copilot and Claude. We added later. We can also add Cursor into that mix. We mostly use Copilot and Codex with our quant, because they really need to have a larger context analysis capability, especially the multi-tool capability of Codex and GPT-5.4,
Instructor:and that's where we actually designed these three setups for different kinds of team players who have different needs. And this is perfectly okay, because if we democratize to too low a layer, then the problem is it will become a sort of very difficult context-management process, and if we actually take it very high and make it enterprise-level rocky, then we cannot use that, or this, and everyone needs to use Copilot, et cetera. Then it becomes pretty much handcuffed, because every team and every function, we need some different capabilities to work at best, so it's the right thing to set up, to have two or three setups that can be canonicalized across the enterprise and then enforced accordingly. And then Cursor rules whenever you need to switch, and that's it basically.
Instructor:Five rules for the team multi-tool setup. Keep the config short. Under three hundred lines. I said before this point as well: models generally follow one hundred fifty instructions, and this is something coming from my own research for the last two years. It could differ here and there ten to twenty percent, but generally, if you put some constraints in mind in a context, most likely it's not going to be read, and most of the information will be discarded. So the context is very essential to have one hundred to one hundred fifty lines. In a broader term, in tokenified, I say around one thousand tokens is the best place, the best spot. And delegate the code style to linters. Don't put code or coding style into this code, into context. Because linters are deterministic. You can always add just one line towards the end from the hook that,
Instructor:like for example, ESLint or Prettier, and then check if anything breaks or not. That iteration is far more positive value and easy to manage, over adding this significant amount of lines and constraints into the context. Then I would also recommend having agent-specific tooling and agent-specific guidelines. The reason is because the common tools generally capture around twenty to thirty percent of the context window itself. Ideally, no agent should have more than five or six tools explicitly defined. And it might come as a shock, that how only five or six tools, because that's where we create multiple agents for specific tasks. It's okay to create ten or twelve agents and manage them compared to allowing thirty to forty tools per agent and blow the context. Just try it and use comments, say thanks to me, how much difference it could make.
Instructor:Treat config as a living doc. Wrong instructions cause more harm than none. Review them regularly. Context is your new code. Bear in mind that context is the abstract nature of your coding. So, for example, at this scale of a ten-centimeter, the change in one centimeter of a context will manifest a one-meter distance in your code itself. So this precision engineering is based on context. From a context, a person can just measure a small one-centimeter block from point A to point B, and that will decide how much distance on a projected line within the code it should travel, and that's where the abstract thinking comes. The abstract thinking is all about developing appropriate context. Now the final, the last point, we will cover the operating model, and this is where exactly we will discuss
Instructor:what should be the operating model across the team when you are having the shared decks. When you are having the enterprise-ready, enterprise, the common architecture, common design patterns, common design guidelines across the enterprise, and how to design the operating model for individual small projects and the enterprise projects. These are the very essential aspects to make the coding or system development successful. Then the second question which is common across everyone is calling that IDEs are dead. I beg to differ. IDEs are not dead. IDE or CLI, don't pick one, use both. IDE, like Copilot, offers suggestion. Real-time completion, visual diffs, inline feedback, great for writing functions, fixing bugs, tweaking components. There is a lot that you can get from IDE. Do not write them off. Designers really need that tab ability.
Instructor:The CLI agents like Claude Code or GitHub CLI, they're perfect for delegation and summation tasks, or bootstrapping the project. They describe a goal and walk away and come back to a commit. That's great for refactoring, migration, cross-file audits. To me, on a CV, if I share some of the internal data that I gathered in my team, how it behaves, we have around sixty-five to thirty-five percent between the IDE and CLI, and we are a very much AI-centric team. We got most people who were natively AI scientists, but still we use IDE not because we can't use CLI, but because the IDE has far more offering than CLI itself in many use cases. So that argument of IDE versus CLI is pretty much on a case-by-case basis.
Instructor:What we want to achieve. The table shows when which particular use case: frontend work may be IDE. If you don't need UI, maybe DevOps may be CLI, maybe something like that. But one warning: CLI agents produce code far faster than you can review it. IDE's one of the core benefits is progress as you review, and that's the real friction. Because as a team, I have also noticed in my subordinates and my colleagues that CLI can generate a lot of code, but it's very difficult to review and maintain that code. So set session limits, review in small batches, and ensure you develop the best practices between the CLI and IDE, and also understand what are the limits in terms of team capability, especially when it comes to post-code generation or post-code generation validation.
Instructor:IDE reviews. That wraps up lesson seven, the Surface Strategy. Does your team use multiple AI tools? What's in your AGENTS .md? Drop your setup in the comments and subscribe and turn on notifications so I can see you in lesson eight, and bye-bye.
Learning Objectives4
  • Compare the repository entry points used by GitHub Copilot, Claude Code, Codex, Cursor, and related AI coding tools
  • Design a hybrid folder strategy with a portable base and thin tool-specific layers
  • Explain how graph.json and transform.py can project one shared context source into multiple tool-native outputs
  • Choose when IDE agents or CLI agents should lead based on task shape, review cost, and team workflow

Setup Instructions

0/3

Clone the repository

Clone the course repository to your local machine to follow along with the code examples.

bash
git clone https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/07-surface-strategy
cd $(basename https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/07-surface-strategy)

Create a virtual environment

Create an isolated Python environment for the project dependencies.

bash
python -m venv .venv
source .venv/bin/activate  # or .venv\Scripts\activate on Windows

Install dependencies

Install all required packages from the requirements file.

bash
pip install -r requirements.txt
nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/07-surface-strategyGitHub

Complete source code for this lesson.

github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/07-surface-strategy
Q&A

Q & A

Q

If I want one portable starting point, what should I build first?

Start with a shared base like AGENTS.md plus docs that explain architecture, commands, and conventions. That gives every tool the same project truth before you add tool-native wrappers.

Q

Why not just copy the same rules into every tool file?

Because copied context drifts. One tool gets updated, another gets stale, and now your AI surfaces disagree about the same project. Keep the source material shared and generate or reference the wrappers from that base.

Q

When should CLI agents lead instead of IDE agents?

Use CLI agents for delegation-heavy work such as refactors, migrations, and cross-file audits. Use IDE agents when you need inline feedback, visual diffs, or UI iteration.

Q

What does transform.py buy me in this lesson?

It makes the mapping explicit. Shared markdown context lives once, graph.json decides which pieces go where, templates define the wrappers, and transform.py renders the outputs each tool reads.