💻Video + Code Examples·10 mins
Curate Project Context with .github and /docs/
Build the shared context layer that powers every AI interaction in your project by combining .github behavioral guidance with /docs knowledge context.
Transcript10 entries
Instructor:Last lesson, we watched the same model score 14 out of 14 with context and 4.5 without it. The gap wasn't the prompt. It was the operating environment. In this lesson, we create project context. We will build a shared context layer. .github and the docs folder, so every Copilot surface starts from the same ground truth. By the end, you will know exactly which files belong in each folder and how to keep them lean enough that the model actually reads them. This is where something called discoverability of context matters as well. This lesson boils down to one idea. .github tells the assistant how to behave. docs helps it know what to know. If either half is missing, the assistant can still sound competent while missing your repo's actual rules. As of early 2026, the behavior side has seven surfaces: always-on instructions, path-scoped instruction files, prompt files, custom agents, agent skills, hooks, and MCP server config, plus AGENTS.md. And if you are using Claude, then CLAUDE.md for cross-tool support. This particular example
Instructor:is intentionally narrow. We are not asking the model to invent a new feature. We are asking it to tighten existing notification preference routes while keeping owner-only writes, delegated-session blocking, audit logging, and centralized FORBIDDEN error intent. So before we get into the workflow here, let's see how it works in Visual Studio Code. So one of the very interesting areas of this let me go back to Visual Studio Code and let's stay there. So now we are in Visual Studio Code. It's a similar example like what we saw in 01, but here it is with behavior plus knowledge. This will be very interesting. We have created a simple but very powerful copilot-instructions.md. Now, however, you can see this copilot-instructions.md is just thirty-seven lines. But there are a lot of references being given as paths, as links. What we would like to see is when we provide a Copilot input, and then start the run, we don't waste a lot of time. It would be just, we can run using util.py --demo. And you can download this example from the GitHub
Instructor:code and just try it by yourself. So what it will do: it has deleted src, has recreated src. The logs are working. We would be expecting only this particular file out of this source that updates. It's quite a large project, not enterprise level, but it's a decent-sized project, around one hundred to two hundred and fifty files, and the database as well, and a frontend too. And based on that, the prompt we are passing here, we anticipate that just this particular file should change. And along with the file, we are expecting this pattern to be observed. Also, we would be looking for when the assessment will be created. So this is the assessment from the previous run, and this tells when this particular program was run. I think so. How it actually behaved, and at what point the first run actually got it from our index, and then indexed the area that we highlighted there. It worked like a pin, and then after the next step, the session started going to the other files. Handling one search as a blue pattern, and in this order, with very limited context, it was able to achieve it.
Instructor:So now I think our repro process is completed using the GitHub Copilot CLI. And if we see, the expected pattern was this, the expected file was this, and the changed file was this. And if we see the demo patch, it exactly arrived at what we were anticipating. I have tried this example without the same setup. It floated around three hundred to four hundred lines. It wasn't able to keep it tight. But if you carefully see here with the Copilot log, and if you analyze it, it has actually used less than 20,000 tokens, which is a perfect example of how effective our context management can be, and how effectively we can apply precision engineering. So it has completed this slide, and let's see the assessment. I think the assessment, as we were saying, is always updated afterwards. So is there any update? No, it was pretty much done. And then I got my internal validation that it passed scoreboards. I also want to highlight this particular assessment criteria as well. Whenever we are building and creating any kind of project, it's not just a job to create some documents and use
Instructor:AI anywhere. Context engineering and context creation is actually a scientific process. We need to have assessment, we need to have validation tools, and we need to actually test it against an actual coding agent. By seeing that whatever we are doing is picking up the right scenario and is it passing the right scenario. Any project that I do, I generally have around five to seven different verification criteria where I test against 10 to 15 different test case scenarios where I'm ensuring that my context discovery is at least 80 to 95 percent on a desired scale. And that provides me a confident ground before I actually release the context to a broader team. Context engineering is really an art, and that art actually leads to successful AI-assisted programming, not just for one person or two people, but for the whole team. It's really essential and absolutely cannot be disposed of as a requirement. In any case, so let's go back to our slides and let's understand where we left off. Right, so we are back here. So this is what happened in a
Instructor:broad sense. The task extracted the shared helper from the three routes because the repo already has the rules and architecture document available. But if you remember when I showed you the GitHub instruction, the way it was creating the graph by providing unique path patterns, those unique path patterns, instead of a linear context, created a graph where the AI assistant could really traverse very effectively without loading all the memory and without loading all the context, and that will eventually lead to less or no hallucination. The biggest challenge, even with great context, is context discovery. If it goes beyond one hundred percent, which means one hundred percent is your benchmark, that is the minimum context that you would like to be discovered for a particular request. It's better to target ninety than to target one hundred and fifty. Because generally, in my opinion, when we target the higher end of context discovery, that means fifty percent extra context has been passed, which is not necessary. Generally, it leads to hallucination and bad decisions by
Instructor:AI. While if we target the context below ninety or just around ninety, the AI can come in a creative way and actually target the missing context that it is looking for. So it is always important in context engineering where to target context discovery, and this is the exact example to show what kind of various tests you should do to validate the context you develop. So let's go back to the next point. On this, the response agent fired eight parallel tools. That is the context layer doing its job. It already knows, literally, the source of truth from the files. It reads before making any changes. We make sure that everything required in order to understand the common value of it, of principle, has been done. It reads basically ten discoveries before the first try. And then it finds three helper extractions, how to rewire three routes without adding a new layer. And this is exactly what Copilot would discuss: target ninety percent and then let AI come back for the remaining ten percent. If we go below seventy-five or sixty percent, then AI will actually make the guesswork. And if we go
Instructor:above one hundred and twenty, one hundred and forty percent as a target, then definitely it ensures a greater sense of hallucination and more AI slop will be developed. But the sweet spot is ninety. Ninety to one hundred and ten is the best sweet spot we can target. But even at that rate, I would consider the target and what is the end of it. Only one file got modified, and the session ended storing the learned pattern in memory. That output isn't just one-off batch output. It's reusable context for the next run. And that's the most important. Good context is curated, not dumped. Don't duplicate. Limit all the inputs. Don't paste whole documents. Don't build one giant rule file. Don't leave stale facts behind. Write only what changes the run. One quick tip that I probably give everyone is: try the /init slash command in VS Code Copilot Chat. It can generate a starter pack, but after that, take over and make sure that you curate the context you look for. Do not just rely on AI-generated output.
Instructor:Generally, I have found it is highly bloated content. Use it as a bootstrap and then keep refining, keep refining, keep practicing on context, and validate and make sure that in at least eighty to ninety cases, the context discovery is somewhere between 80 to 95%. And that's the most important exercise before passing the context into actual project bootstrapping. Before that point, I would never recommend a project should start and then keep maintaining the context. So very simple: context is where you will make a great project. That wraps Lesson 2. Now I want to hear from you: what's the biggest challenge that you've had curating context for AI tools? Is it stale docs, too many rules, or not knowing where to start? Share your thoughts, doubts, or questions in the comment section below. We'll be selecting the best comments to join in live sessions. In live sessions, we exactly talk through this kind of learning and we share the learning. It's one of the most valuable ways to actually explore and master this art of context.
Instructor:Finally, make sure you hit subscribe and turn on those notifications. So these lessons reach your timeline the second they drop. Thanks for watching, and I'll see you in Lesson 3.
Learning Objectives4
- Explain why .github and /docs should be treated as one shared context layer
- Distinguish behavioral guidance from knowledge context
- Identify the repository artifacts that provide high-leverage project context to AI systems
- Design a starter context layout that helps both human contributors and AI assistants
Q&A
Q & A
Q
Why do docs matter if the code already exists?
Code shows what exists. Docs explain why it exists, what was rejected, and what operational constraints matter. That missing why is often what the AI needs to avoid wrong suggestions.
Q
What is the highest-value document type for AI context?
Architecture Decision Records are especially valuable because they teach the assistant both the chosen pattern and the rejected alternatives.
Q
What should live in .github versus docs?
Put behavior and automation in .github. Put architecture, decisions, conventions, and operational knowledge in docs. They solve different but complementary problems.