Video: Top 10 GitHub Copilot Commands You Should Know | Duration: 1352s | Summary: Top 10 GitHub Copilot Commands You Should Know
Transcript for "Top 10 GitHub Copilot Commands You Should Know":
Hello, everyone. Happy Friday. Hope you're having a great day. My name is Roza. I'm a solution engineer here at GitHub, and, yeah, I really appreciate your time today to come through to our GitHub co pilot Friday webinar. So this is essentially a series of webinars where we deliver this every second Friday, where we've got a variety of GitHub experts exploring different types of topics, use cases, or even just personal demonstrations where you can get a lot of useful insights for your needs. And this session is being recorded and will be available for everyone to revisit, at their convenience. And we're also excited to offer great coverage for our APAC community by making these recorded sessions available in multiple languages such as Korean, Bahasa, Mandarin, etcetera. So definitely keep an eye out for that after the session for the link. So in today's session, we will be diving into top 10 GitHub Copilot commands you should know. So I've prerecorded my talk so I can be available to answer any of your questions in the q and a window. So if you look towards on your top right of the screen in front of you, you should see that there's a chat window as well as a q and a window. So please be sure to drop the questions in the q and a window so that we can try to get some of them answered as we go along. So, yeah, let's, roll the video. Enjoy the content. Hi, everyone, and thank you so much for your time today. We've got a pretty jam packed Copilot Friday session ahead of us, and we're going to cover the basics of using GitHub Copilot commands and show how they can take an idea from a rough prompt to a result you can confidently use. Here's what you'll walk away with by the end of the session. First, you'll understand what Copilot commands are, why they save you from repeating the same instructions, and how to choose the right command for the job. Then we'll deep dive into the top 10 most useful commands from improving design and strengthening security to using an AI coach that help you work smarter. Okay. Let's dive in. So let's get the basics out of the way. What even is a command? Essentially, it is a saved prompt that has been prewritten. Someone smart wrote a good version of the instruction once, and now you just have to type slash and a verb, then you get the same prompt every time. Now this really beats typing it all out yourself. One, it is consistent. The same command repeats the same steps. Secondly, it is faster. Right? One slash instead of typing out the entire paragraph for setup. So you're not really writing out the instructions. You're doing the work. Then lastly, the expertise is baked in. Each command is you may have a researcher, a designer, a critic, or even an AI coach. So you don't have to have specialties in everything. You just have to know which command to summon slash use. First command, research. Here is the situation that this command is trying to prevent. So let's say you ask GitHub Copilot about a specific topic and then you go straight into implementation mode. Then forty minutes down the line, you realize that you're going down the wrong path and you're producing the wrong feature. Right? So this is where research comes in. It runs a deep investigation both using GitHub search within your current repository and also existing web sources. Then it produces a source back research report, which then you can take into your planning and implementation mode. Okay. Next command we have coming up is plan. So think about how you finished using the research command. You've done a detailed report on the topic that you're planning to implement. Now, you can take the asset that's generated from research and feed it into the next step, which is plan. So plan turns that into a executable direction. Right? So it's a step between understanding the problem and then spending time building on the solution. Without a plan, Copilot may fill in the gaps for you, and it can be building the wrong version completely. So only you have the right vision to tweak the plan that it does generate before you go ahead and actually implement. Now the outcome of that is you will improve the quality of your final project. There's gonna be fewer surprises, faster approvals of the work that's been broken down, then there would definitely be less rework over time. This plan can also be shared widely with the team, which will make sure everyone shares the same picture, and they can respond and collaborate with you if they have a different version of the that final vision. So once you have the requirements locked in, they're locked in for good, and they're locked in whilst gathering different perspectives different perspectives from different persona. Next up, we have a skill that unlocks a UX designer for you slash impeccable so that you can walk away with the most impeccable design. Because we all know a great prototype or MVP proves that a particular idea works, but if you pair it with great design, people can really see the vision, understand its value, and see where it could actually go. So the slash impeccable command is a front end design and UX skill. It can build an interface from an idea, critique what already exists, audit it for problems, or refine it for a specific outcome. So it actually looks beyond if the page works from a UX perspective. It checks for accessibility, responsiveness, typography, and layout. It even has the ability to add animations for you. So the instruction can be quite broad. It can be impeccable audit, or it can be more precise such as impeccable critique this dashboard that I'm building, or impeccable animate this page to see where you're appropriate. So it's quite flexible from a more front end UI UX designer perspective. Okay? And essentially, yeah, you're not limited to just saying make it better. You can name the interface and the outcome that you want, then you can critique it, polish it to make it closer to that end vision. I'm just making it more polished so that when you are presenting an idea, it will drive a stronger impact. Next command, we have a pretty fun one with a cute name. It is called slash rubber duck. This is a command that gives you essentially more confidence before you share or ship your work. Right. So you've gone ahead, done your research, done your planning, and done your design. Right. Before you actually present to anyone else, you can get a independent agent. Think of it as pairing with a rubber duck to challenge results, to see if it can uncover any blind spots or catch mistakes when they're should still be easily fixable before you ship. Okay? So you can think of it as a on demand critical reviewer. So it looks past surface polish UI and more focus on the question that could change the outcome. Right? So does the underlying logic build up? Does everything work in practice to what you're trying to achieve? And are we relying on assumptions that perhaps it hasn't been tested? So this is a read only command. It critiques everything, gives you feedback without changing any of your files, so you can still stay in control of what recommendations you do end up accepting. Then next up, we have Chronicle. K? Think of this command as multiple command in one. Right? It actually can do multiple things. It is both a personal coach, a cost advisor from an AI token cost perspective, and also a way to turn repeated corrections into lasting improvements inside your workplace. Right? So you can think of it as a chronicle is really just a record of what happened over time. It's the history. Right? So this command reads the story of your past co pilot sessions and it spots patterns running through them. Then it uses those lessons to improve what happens next. So you do get recommendations based on well, they're literally personal personalized recommendations based on how you actually work. Right? So it means fewer repeated mistakes going forward, so you can train yourself to have clear prompts, faster sessions, and less time spent correcting GitHub Copilot on the same behavior. So the first command under chronicle is chronicle tips. Right? Chronicle tips, it finds the pattern holding you back and turns them into specific actions. It might show that you mix research and implementation in one long session where there should be separated into separate ones. Or it's you're repeating the same project context or you spent too many turns clarifying prompts that could have been structured from the start. So the outcome is a workflow tailored to you so that you can unlock more GitHub Copilot capabilities that you may not know and improve the way that you work. Then the second subcommand under Chronicle is more from a cost perspective. So this shows you where your Copilot usage is becoming unnecessarily expensive. It looks at your past thirty days history. It highlights bloated sessions, repeated context, oversized pace, or premium models being used for routine work. So then it recommends the changes with the biggest potential savings. So definitely recommend you using use the cost tips chronicle command to figure out how you can spend less, but still put out the same output. And then the third sub command that's super handy within the chronicle command series is chronicle improve. It turns recurring friction. So when you are interacting with Copilot, there can be frictions with your interactions. You can transform these frictions into lasting improvement. So it finds corrections that you keep on making to the Copilot agent, then it recommends updates to your project instructions and your agent instructions, and it lets you approve what should be applied. So then over time, you your work with your agent should feel smoother and smoother as it figures out the improvements that the agent should be making to tailor more to your preferred way of working. Next command we have is security review. So as we're using AI more and more to ship a lot of code, we're shipping a lot faster, we're creating more features, but at the same time, there's a trade off. Right? We're creating more surfaces and areas where security risks can be introduced. So more means, more opportunity for maybe a leaked secret and unsafe path or vulnerable dependencies to slip through unnoticed. And this is where the value of security review comes in. It moves the security checks a lot earlier. So while you're changing the different features and while you're still developing, you can have the fix a lot earlier in the software life cycle development. So you can have more confidence before you commit, push, or ask someone else to review the code. So this command is currently experimental. It analyses your repository stage and end stage changes for exploitable security vulnerabilities. Then it prioritises high confidence findings by severity and confidence. So it can report issues such as injection risks, authentication flaws, exposed secrets, unsafe input handling, or even insecure configuration. Then it actually shows you where in the code the risk is, and you do get recommendations on how to address it. This is complement tree to our wider security suite for code security or code scanning or secret scanning, but this is a practical way for you to get a firsthand view of vulnerabilities that are being introduced as you're generating more code. Then next up, we have how you can free up context with the compact command. So as you're communicating with Copilot by sessions, well, long sessions can be productive because you can go back and forth, spending multiple hours or even multiple days. But all of that history eventually can become baggage. So your context window can be built up. In addition, you can be dropping in screenshots, additional documents, and they can all, pollute or fill in your context window, which results in responses being slow or context cost rises, you know, more AI token cost for context. And, also, the important decisions can compete with dozens of turns that doesn't actually matter anymore. So this is where compact comes in handy, where it lets you to keep in the same session. You can keep the momentum going without starting over. What it does is it summarizes the conversation up until this point, then replacing the old detailed history with a shorter context, which then will free up context window space while preserving all of the important decision progress and also next steps. So it's not necessarily forget everything that you've been told. It's just more about summarizing and compacting everything that it does remember so you can keep the knowledge and continuity in the same same session without having to carry the full transcript over time. Now for the final command. Now this command is more of a community skill that you can install once. I will be listing out where the exact public GitHub repository is that you can install. But essentially what it does is, when you're moving quickly inside a chat, sometimes Copilot may respond in answers that are quite bloated. So it's inside paragraphs and inside polite narration. And this is where the skill called caveman comes in handy. It can switch the GitHub Copilot agent to more of an information dense reply for the rest of that session. So instead of opening with, sure, let me help you with that, it goes straight into, okay, auth middleware. Token null after refresh. So it removes a lot of the bloat, from the polite narration's point of view. So the goal is not necessarily fewer codes for the sake of it. It is less scanning and lower cognitive overhead and also faster decisions when you're debugging, reviewing, or working through a long list of tasks. So you can find the problem and the next action at a clan plans without losing the technical accuracy that you need. And there's also a cost benefit. Typically, for any AI models, the output tokens are often the most expensive part of the in AI interaction. So the easiest way to save cost is also to simply condense the response. Amazing. So that ends the last command for today's session. Okay. So that's it. We've covered 10 different commands, and these are the different values summarised again. We've got research, which turns question into a source backed evidence file. Plan, that takes the research asset and align on the outcome before you spend time on building it so that you you can improve the quality of implementation. Next is impeccable. It turns a working prototype into a perfectly polished, UI. Rubber duck exposes any blind spots from a review perspective, before you're presented for next steps. Chronicle is useful for turning past sessions into bet better habits. May it be finding out other co pilot skills, capabilities that you're missing, lowering cost by getting recommendations, and also improving the quality of your agent over time so it it has less mistakes. Then we covered security review where you can find risky code changes way earlier on in your software development life cycle as opposed to, down the chain. Then we also covered compact, one way to free up context window without losing the decisions that can move the work forward. Then lastly, caveman, reducing the reading and output cost by getting straight to the answer without any of the polite fluffiness. Now one ask before you go, we have covered quite a few comments today. Feel free to pick one of these and use it on something in your workflow this week. K? Not all eight. My honest recommendation is to go test out Rubber Duck and also run Chronicle, right, to get some personalized recommendations of what you can do differently to reduce token cost or explore different capabilities that you might have not used before. And, otherwise, thank you for your time today. We'll be back in two weeks time, so keep an eye out for the next topic and the sign up link. But otherwise, enjoy your week. Hi, everyone. Just an update on the following session. So appreciate you attending today's talk, but for our next Copilot session coming up on the September 4, My colleague, Laksh, will be covering stacked pool requests. So that's the actual next topic. It's very, very interesting. It actually shows you in the GitHub Copilot app how you can have multiple requests by breaking down your to do so you actually get more accuracy in terms of implementation. So instead of implementing, say, 20,000 lines of code, it breaks that big feature down into specific subfeatures, and all of that is stacked together. So super cool topic. Highly recommend you to come through to listen. And, again, have a great great Friday, and see you next time.