# COPILOT EXPLAINED in the Terminal

## Метаданные

- **Канал:** That DevOps Guy
- **YouTube:** https://www.youtube.com/watch?v=PftfVT-Mm7o
- **Дата:** 12.05.2026
- **Длительность:** 2:59
- **Просмотры:** 12,302
- **Источник:** https://ekstraktznaniy.ru/video/51718

## Транскрипт

### Segment 1 (00:00 - 02:00) []

As a DevOps, SRE, or platform engineer, I always encourage engineers to become tool agnostic and not biased towards a specific technology. In my AI CLI series, we've taken a look at Gemini, and today we take a look at Copilot. Now, GitHub Copilot actually has a free tier, so there's about 50 chat requests per month, which is good enough to learn about the CLI tool and familiarize yourself with AI concepts. The Copilot CLI can be installed with simple commands. It's a standalone binary, which means you can even run it in a Docker container. This means I can do Docker build, Docker run, and then I can fire up the CLI in my terminal. We take a look at the various commands, like logging in and logging out. We take a look at the init command, and the init command is what allows us to generate an instruction file. This is what sets up the context window and guides the model to be more accurate when looking at our code base. This generates a Copilot instructions file that basically summarizes and describes our entire repository. The Copilot CLI supports creating custom agents. We can see these agents by using the slash agent command, which lists our custom agents. The GitHub CLI looks in the dot GitHub folder under agents for markdown file, which is basically your agent instruction file. That's how we create an agent. You give it a name and a description, and the CLI will automatically discover your agent. To further enhance the context, instead of putting everything in the agent file, we've created what's called skills. You can list these with the skills command, and you can see we have three skills. To create a skill, all you need to do is in your dot agents directory, create a skills folder, and under there create a folder for each skill. And each skill is defined by a skill. md. So, this is what a skill looks like to provision a local Kubernetes cluster. I give a clear description. This tells the agent when to activate the skill, and the skill is only activated and the content is only read once the skill is activated. This means we save on tokens as the skills are not loaded into context automatically. When I ask the agent to provision a Kubernetes cluster, the agent will then detect the skill it needs to load, and then it will load the instructions of the skill into context. The cool thing about skills is that we can actually have scripts, resources, and assets packaged with the actual skill. So, here I have a scripts directory in my skill, how to create a cluster, how to install all the dependencies in order to create a cluster. This means the LLM will not guess. It's simply going to work out which scripts to run, and it will run it automatically. This means I can just say create a Kubernetes cluster, and my agent will go ahead and it will detect the skill, activate it, load it, and then go ahead and run my scripts to provision a cluster. I can then enter shell mode and say kubectl get nodes, and my cluster has been provisioned. I can also use {slash}mcp, and I can add a Kubernetes mcp. This means I can use natural language to query my cluster, and so I can say something like show me the namespaces in my cluster. If I go ahead and run that, it will execute the mcp tool called kubectl get and return the namespaces. If you want to dive into more details about the Copilot CLI, check the link down below for the full video.