Ultimate GitHub Copilot CLI tutorial for beginners

In this episode of GitHub Copilot CLI for beginners, we're going to get started. We'll take a look at how to install the tool, how to log in, and your first couple of requests that you're going to send to Copilot CLI. GitHub Copilot CLI is an AI agent right there on your desktop. Like you'd expect from any AI coding assistant, you can use C-Pilot CLI to explore your codebase, ask questions, and generate code. But what makes agents special is their ability to perform tasks autonomously, like building your code and running tests, and even being able to self-heal, making updates to the code when errors are detected. Copilot CLI fits nicely into your existing workflow as a developer, allowing you to interactively assign tasks and work on other items on your to-do list or to iteratively build, looking at the generated results and impact it has on your application and request changes as you go. You can even use Copilot CLI to delegate tasks to Copilot Coding Agent, a cloud-based agent. Getting started with Copilot CLI of course starts with installation. The core cross-platform way to do this is via npm using npm install. Tickg at github/copilot does the trick. If you're using a package manager like windget or homebrew, you can install copilot cli through those tools as well. You can consult the documentation for those tools for the exact specifics. For me personally, I prefer installing via Node, but that might just be the web developer in me. Once you install the product, you can launch it by typing out Copilot. There are numerous switches you can use, which we'll be talking about in later videos. If it's your first time, you'll need to log in with your GitHub credentials. This does two things. First, it ties the client to your Copilot account. Second, it connects the GitHub MCP server, which will grant access to resources on GitHub, and that's something else we'll talk about later. When using Copilot, you need to grant access to the folder for Copilot to be able to explore and potentially modify files. You can choose to do this for just this session or save that for later sessions. This allows you to launch Copilot again in the future on a particular project without having to approve it over and over. Once that's done, you can just start talking, asking questions, requesting code or other tasks. Let's start with a couple of basics here. Let's ask Copilot for an overview of the project. Copilot will explore, open important files, and report back with its findings. We can also ask for code like asking for a new endpoint to be created. When I make the request, Copilot will look again at the project, find existing documentation and examples, and do its best to follow the practices it sees. Again, Copilot will ask for permission, in this case, to create the file. I'll approve this, and now I've got a brand new endpoint created. Of course, this is just the beginning. One of the best ways to explore Copilot and what it can do is to just ask Copilot. It'll look through its documentation and provide guidance on how to interact with it, experiment, and explore. And of course, you can explore the rest of the videos in this series. We'll walk you through some of the most common scenarios and most powerful options and help you get the most out of GitHub Copilot CLI. Hey everyone, welcome back to the GitHub Copilot CLI beginner series. Today we're going to talk about the different modes of the CLI, interactive and non-interactive. So, let's get into it. Copilot CLI has a chat-like interactive mode that's great for back and forth coding and an inline or non-interactive mode that's great for quick oneshot prompts. Let's take a look at both of them. To enter interactive mode, just type copilot and hit enter. Copilot will usually ask if you trust this folder, and this is because copilot may read and modify files. In interactive mode, I can ask, how do I run this project locally? Copilot will give me instructions on how I can do it by hand, but I could also follow back up with, can you run it for me? Copilot will then analyze the project and start up the server. Then from here we can take a look at our project, find changes we want to make, and continue working within C-Pilot in the same session. For non-interactive mode, we'll exit out of Copilot and go back to our regular command line. From here, we can type copilot-p and provide copilot with a prompt like quickly summarize what this repository does and the key folders. Copilot will then look through the project files and give me an answer, all while keeping me within my command line context. This is great for one-off prompts or questions you may have while wanting to remain in just your shell. Another tip is you can resume a previous Copilot session from here with Copilot- Resume instead of using the slash command. This is great if you already know what session you want to work in, so you can get started developing with Copilot in just one command. So, to recap, you can jump into Copilot interactive mode for longer sessions with back and forth coding. And you can use non-interactive or inline mode for quick prompting. Copilot CLI beginner series. In this video, we're going to do a whole overview of the CLI's slash [music] commands. So, let's get started. Slash commands are the control surface within Copilot CLI. They help you steer, inspect changes, manage context, switch sessions, and keep permissions tidy. Let's take a rapidfire look at some of the popular ones. To look at all of the slash commands, just type slash and you can scroll through the options. If you want to change which model you're using, type slashmodel. From here, you can see a list of the available models and select which one you want to use depending on the task that you have. Some models are great for quick lightweight jobs like refactoring and others are better for deeper reasoning like feature planning. This list may change as new models become available and it also depends on which plan you have and what your organization has enabled. The numbers on the right show cost multipliers so you can see which models come with your plan and which will have an additional cost. Now that you've chosen a model, you may want to look at your token usage. To do that, type /context. This view will show you how many tokens you have left and how much your system free space and buffer has. If you want to get more room within your context, type /compact to summarize the conversation so you can keep going without starting a new session. What's great about Copilot CLI is that it'll do this automatically for you once you start to reach your limit. You can always do it by hand if you're moving on to a new part of your project, or you can use /clear to fully start over. If you want to resume a previous session, you can type /resume. This will bring up a list of previous sessions you've had, including both local and remote sessions. Entering a previous session will show you your session history, and you can continue working within that same context. Once you've made some changes to your project with Copilot, you can run /diff to see what the changes are. If you want to start working on another project without exiting Copilot, you can type / CWD to change the working directory to another repo. You can also use this within a repo if you want to keep Copilot's work scoped to a particular piece of your project. Lastly, if you've allowed certain tools like always allow file edits in this session, but you want to revoke that. For example, let's say if you've just moved to another repo that you want to be more careful in, you can run slashresetallowed tools to reset tool approvals. These slash commands help give you even greater control over Copilot CLI. So, be sure to check them out along with the rest in the list. going to plan a new feature, build it, and review the code, all using only Copilot CLI. So, let's go. In a previous video, we took a look at a bunch of slash commands you can use throughout your workflow. Now, let's take a look at three powerful ones we can use in sequence to plan a feature, have Copilot build it for us, and then review it using slashdelegate and slashre. Plan mode or slash plan is great for ensuring Copilot builds exactly what you want by creating the requirements ahead of time. Copilot will ask clarifying questions and it'll produce a step-by-step plan before writing code. Let's take a look at our app. It looks like when I select a game and click support this game, it doesn't do anything. I want this to work by showing I've supported it both within the individual game view and on the main page. Let's use Copilot's plan mode to plan out how we'll build this. Typing shift tab will put you into plan mode. You can also type / plan. Let's say let's implement the support this game button. We should see the status change to supported and also have an icon appear on that game on the main page. After submitting the prompt, Copilot will analyze the project structure and begin to form a plan. What's great about plan mode is Copilot will also ask clarifying questions for things you may not have thought of nor specified. Here, Copilot has asked about how we store the supported state, what icon we want to use, and if the user should be able to toggle the supported state. For the project storage, we'll stick with local storage. So, we don't need to implement a backend. For the icon, I want to use the same heart icon we had. And for toggling, I think we should have this supported. Now, Copilot will come up with a step-by-step plan, and we can go ahead and ask it to implement it. We could choose to implement it here locally or have Copilot build it in the cloud. Next, we'll delegate this plan from Copilot CLI to the cloud. So, the GitHub coding agent can build it for me. Delegation or delegate pushes the work to a remote C-pilot coding agent that opens a draft PR, which is perfect for tasks you don't want to do live. Let's delegate the plan we just made to the GitHub copilot coding agent from Copilot CLI. To delegate, we'll type /dlegate and then we can include a prompt. For this, we'll say implement this plan. Copilot will start by summarizing the context from the conversation. Then it'll create a draft PR and add its implementation. Copilot CLI will also provide a streaming log of what the agent is doing remotely. While this is working, I'm able to start a new session with CtrlN and begin working on something else because Copilot is processing in the background. Let's take a look at the PR it made. While it's still working, we can click on the view session button to see what steps it's taking and we can steer if needed. Now, let's fast forward a little bit. We can see it left a detailed PR description and now that the agent has finished, we can take a look at the files. From here, we can head back into Copilot and run slashres to play with this branch and test it. If you hit tab while looking at the /resume menu, you can cycle to the remote branches. Here's the one we just created since it was spun up 22 minutes prior. Now, we can continue the work remotely or pull it down locally. And for today, I want to work on this locally. This is how you can delegate tasks to the GitHub Copilot coding agent directly from your terminal. And now, we'll take this PR and review it using C-Pilot. Copilot CLI can review your code right in the terminal. And this works with both uncommitted changes or changes that are in a PR. The goal of this PR was to get this support this game button working, which we can now see is changing state when I click on it. So that's a good sign. We also wanted an icon to appear on the homepage, which it looks like it has. To start this code review, we can type /re and we can provide it additional things to look at by adding an additional prompt. For now, we'll stick with a plain review. This will then delegate the review task to a sub agent that specializes in code reviewing. Right now, we're reviewing the PR within a remote session, but this also works for local sessions as well. This is helpful for finding any bugs or vulnerabilities. And one tip is to have the review use a different model than what wrote the code. If Copilot finds any issues while doing the code review, it'll apply fixes to them and ask for your input. At the end of the review, you can see a summary of what Copilot changed. This way, you can continue to iterate with Copilot to fix any of the items it found within its review and have more confidence in the final PR that you'll merge for your feature. This is how you can do a complete coding loop with Copilot CLI to plan your feature, have Copilot author it for you remotely, and review what it built all from your terminal. for beginners, we're going to explore MCP or model context protocol, which is an open API standard that will allow agents to perform even more tasks beyond just writing code. There's more to writing code than just writing code. Beyond things like building and running tests, there's issues to manage, PRs to create, databases to interact with, just to name a few. Since agents have an ability to act autonomously, it'd be wonderful if we could grant them access to these types of resources. And this is where MCP or model context protocol comes into play. MCP is an open AI standard to allow AI agents to interact with them. Through MCP, organizations can expose documentation, assets, and functionality to enhance an AI agent's capabilities. One great example of this is an MCP server that's already built into GitHub Copilot CLI, the GitHub MCP server. Through this server, you can access both documentation and assets on GitHub like issues and pull requests. I want to explore a couple of my favorites, Playright and Spelt to highlight how to manage MCP servers and some of their functionality. To add an MCP server in Copilot CLI, you use the /mcp command. The interface will prompt you then to add in a brand new MCP server where we'll ask you to provide a name and the details on how to start that MCP server. The two core methods for accessing a server is either having it run locally, typically through node using npx or remote hosted with a URL. You can check the documentation of the MCP server you wish to use to determine what details to provide. To add playright, we'll start by providing the name. The playright MCP server is local, so we'll leave that option as the default. Then provide the npx command to start it which I copied from the documentation to add spelt. It's the same process but this time we'll specify http since it's a remote server and provide the URL for that remote server. Again I pulled that from the documentation. Let's explore each one of these in action. Starting with playright. Playright is an endtoend testing framework for web applications. The Playright MCP server allows an AI agent to use Playright to interact with a web app. Using the MCP server, you can validate functionality. I'll send a prompt to tell Copilot to look for functionality for filtering in the app. In my case here, I'm being explicit in telling Copilot to use the MCP server. This isn't required, but I have a basic philosophy when using any AI assistant. If there's something I want to make sure it does or that it might need to know, I'll just always tell it. And we can see copilot then using the MCP server in action. It looks through the site, interacts with it, and confirms that the filter functionality exists and behaves as a user would expect it to. Now, turning our attention to the spelt MCP server. And if you're not already familiar with spelt, it's my personal favorite front-end web framework. And the spelt MCP server exposes documentation and a really nice feature to review an app for best practices, which is exactly what I want to do. Again, just like before, I send the prompt and I tell it to use spelt. Copilot uses the MCP server to look through the app. And in this case, it found a small issue with indexing on a generated list. I ask Copilot to make the update, and away it goes. Within just a couple of minutes, I've got my issues resolved. Well, at least my code issues. Through MCP, you can enhance the capabilities of Copilot CLI. You can access external documentation, ensuring Copilot is always up to date on what it needs to know and external resources to perform actions on your behalf. This makes for a more powerful AI coding assistant. instructions files, agents, and skills, which all allow you to ensure that Copilot is following the exact same patterns and practices that your organization has laid out and that you're already following. Ensuring C-Ilot works with existing patterns and practices our organizations have set forth is key to success. To support this, Copylet has several capabilities between instructions files, custom agents, and agent skills to ensure you get the code and activities. How do you'd have completed them if you did them manually? Let's explore each of these separately, then bring them together at the end to see how they help us form a cohesive strategy. Let's start with instructions. Sort of as the name would suggest, instructions are exactly that, instructions to co-pilot. They provide Copilot the background of both what we're building and how we're building it. Defined in markdown files, instruction files come in two core varieties. A single centralized copilot-in instructions file which is project level and instructions file which allow you to target specific types of files like tests or code used to define APIs. Let's make a quick request of copilot to see the impact of instructions files. I'll ask for an API to be generated which in the case of my application is done using Python and Flask. We can see the response is relatively generic. It follows my existing patterns. But let's say our organization requires doc strings. Let's add a copilot instructions.m MD file. The copilot instructions file is global to that entire project and always in context. If we explain we always want dock strings then send the same command we see the impact of this. A dock string is now included with the function in the generated code. Copilot instructions is table stakes. Every project should have one. It's so important in fact that there's a slash command to generate them /it. This will give you a great starting point from which you can add specifics about your project. Now, dot instructions files allow you to get more specific targeting individual types of files. In our Flask API, for example, we have specific requirements on how we want those files to be built. By adding a instructions files, we can break down our instructions into smaller chunks. The apply to section accepts a path which will be used by copilot to determine when to use that provided context. In our case, we've specified Python files in our server routes folder. As you might expect, there are common instructions you might want to add, like how to create React components or playright tests. There's a collection of instructions files you can quickly add to your project at gh.io/ awesome-pilot. Turning our attention to activities and tools, we might want to provide copilot our agent skills. Skills can be used to tell Copilot both how we want to create that code, but how we want to perform lower level tasks. They are defined with markdown files and even scripts in the github/skills folder. We've got a skill here for creating contributions to a repository. It instructs Copilot to look for contribution guidelines and issue and pull request templates. If those exist, it will use those or use the templates we've given it as an example to ensure co-pilot is doing its best work. Skills can be called by using them as slash commands, make contribution in our case or dynamically through natural language. When we ask copilot to make a pull request or PR, it automatically kicks off that skill following the guidance provided. It generates a new branch, an issue, logically groups commits, and eventually creates a PR using the template defined in the repository. And just like before, there are skills available that you can use in your projects at gh.io/ aesome-copilot. Now, for larger tasks, we have custom agents. Custom agents defined in markdown files either in.github/ GitHub/ aents or by your organization allow you to create specialized workers for particular scenarios. Let's take accessibility as an example. Accessibility is of course important and we always want to get it right. It can also require updates to numerous parts of our application and some specialized skills. Custom agents have their own context and are built for exactly this. Using the / aagent command, we see the list of agents that are available. Let's activate that accessibility agent and ask Copilot to perform a review identifying the most impactful updates that could be made to our code. Just as before, Copilot diligently performs the task this time as the accessibility custom agent. Once it generates the suggestions, we can then ask it to apply them and off it goes. Instructions, skills, and agents are all defined as markdown files. And you might be wondering when to use each. It's important to highlight that these are built to be used in harmony with one another rather than an eitheror approach. Instructions provide context on how best to generate code, the things Copilot should be considering as it modifies and updates the codebase. Skills are tools in C-pilot's toolbox for performing tasks like how it should approach running tests and recovering from failures or creating a PR to a project. And agents are built to handle more complex tasks like performing search engine optimization or an accessibility review which might require updates to the entire project. Working together, these features ensure tasks are completed correctly. Both what needs to be done and how it needs to be done.