How to Use Slash Commands to Code Effectively

they are instructions that you can save to your coding agent for easy access. This is often most useful for notifications that you use repeatedly, such as:

• Create a pull request from dev to the prod branch
• Analyze these log groups, and let me know of any problems
• Run pre-commit tests, push code, and do PR

These are all commands that I use every day. Instead of typing the information all the time or saving the information somewhere, I'd rather save it as slash commands in Claude Code or Warp.

This gives me quick access to my most frequently used commands, saving me a lot of time every day.

In this article, I will discuss the slash command, what it is, and why it is so effective. In addition, I will include some commands that I have saved and use regularly.

Why you should use slash commands

Slash commands are easy to access and very useful if you find yourself using repetitive commands. I believe that most of the commands used by programmers will be repeated commands. It could, for example, be:

• Creating pull requests
• Checks if the code is ready for production
• Documentation of the code base

These are all instructions that you will likely use regularly. If so, you should make these commands into slash commands. Instead of writing:

Check if the code is production ready, run pre-commit checks with black, 
mypy and pytest, commit and push the code, and create PR and provide me
the url to the PR.

You can simply save this as a command and type:

/make-pr

With the recent development of coding agents, I find myself writing more code and thus making more pull requests. So I write this warning anywhere from 2 to 10 times a day. The time to type the information, therefore, adds up quickly, and I save a lot of time using the slash command instead.

An added benefit of using slash commands is that your commands will be consistent. You will always use the same command, and never forget to write parts of the command, for example, forget to do previous tests. This also saves a lot of time.

How to execute slash commands

You create slash commands in different ways, depending on which tool you use. However, I will provide a link to the three most common code agent tools, and links to their documentation regarding slash commands:

In general, however, you can simply tell any coding tool, give it a prompt and a name, and tell it to generate a slash command for you.

You can use command by typing, cutting and command name. For example, using a command make-pr you can type the command below in your coding agent

/make-pr

Some of my slash commands

In this section, I will explain some of the slash commands that I use every day. For each command, I'll explain why it's useful and how to use it.

Create a PR release

It is a common coding practice to have 3 types of branches:

• Featured branches (personal branches used by people)
• Branch of joint development
• Branch of shared production

If you use this build, you can create PRs for releases from the development branch to the production branch. These PRs usually follow a standard structure, highlighting the different changes being covered. Example:

• Each change is added, and by whom
• Any useful links to documents, Slack messages, or other related context
• Checklist to be completed before compiling the code (quality assurance, etc.)

To create this, you usually tell your coding agent to create a PR, with the specifications from the bulleted list above. However, both of these take time and may conflict (as you may have small changes to your information each time you write it).

Instead, create a slash command like:

Create a release PR from the dev branch to the main branch. The PR should 
include: 
- each change being added, and by whom
- links to relevant context used for an of the changes (slack messages etc)
- a checklist of items that has to be done before merging, if relevant. For 
example: "perform QA testing in dev branch"

Now you can quickly and consistently create PR's for your storage space.

Create a new PR branch feature

Probably the most common command I use is to build a new PR branch feature. After I implement a new feature, or fix a bug, I have to do the following:

• Pull the latest dev branch, to make sure I'm updated
• Push to the feature branch, from the newly released dev branch
• Perform pre-commit testing on new code
• Commit and push the code to the new feature branch
• Create a PR from the feature branch to the dev branch

I use this many times a day, and it's much faster to use it as the slash command, as you can see below:

Given the changes, I now need to create a PR. Do the following:
- Pull the latest dev branch
- Branch off to a new feature branch from the dev branch
- Run pre-commit checks to make sure my code is production ready
- Commit and push the feature branch
- Create a PR from the feature branch to the main branch

I usually provide the name of the feature branch, as I use the Line branch naming, to automatically update the status of my issues, given the state of my code (if it's in a feature branch, in dev, or in prod).

Fill in the information with the thread

Another command I use to combine information with a string. This is very useful, because I often find that agents behave differently than I would like, for example in the way we use a feature. Or the model may lack some information that would be useful to have in any future communication.

So, I tell the model to include information from threads where I've implemented a new feature, or fixed a bug. I use a command like:

Generalize the knowledge from this thread, saving all useful, generalizable
knowledge that is useful for future coding in this repository. Store the 
knowedge in AGENTS.md

I usually run this command after the last command that creates a new pull request in my feature branch.

Production-ready code

I often find that asking my coding agent if the code is ready for production, works well for finding bugs and other issues. For some reason, informing the model about production readiness, makes the model think about its use, and discover problems that it previously ignored. So I have a different prompt that I use to check if my prompt is ready for production:

Check if the new code created in this branch is production ready. You should
look for any potential issues when running this code in production, and 
ensure all tests and pre-commit checks run as expected. If you detect any 
issues, provide me a report about the issues, their severity, and how we can
resolve them.

An example of a cursor

I also want to highlight the example of the slash command that Cursor provides in their documentation.

For example they provide a code review checklist, a model that I can go through to do a code review. This is very useful for doing reviews after creating a PR, but it's also useful to run as a pre-commit check.

You can see the slash command for the code review below:

# Code Review Checklist
## Overview
Comprehensive checklist for conducting thorough code reviews to ensure quality, security, and maintainability.
## Review Categories
### Functionality
- [ ] Code does what it's supposed to do
- [ ] Edge cases are handled
- [ ] Error handling is appropriate
- [ ] No obvious bugs or logic errors
### Code Quality
- [ ] Code is readable and well-structured
- [ ] Functions are small and focused
- [ ] Variable names are descriptive
- [ ] No code duplication
- [ ] Follows project conventions
### Security
- [ ] No obvious security vulnerabilities
- [ ] Input validation is present
- [ ] Sensitive data is handled properly
- [ ] No hardcoded secrets

The conclusion

In this article, I discuss the slash command, and how it can make you a more efficient editor. Slash commands simply prompt you to save them for easy access, often used for information you use repeatedly. Using slash commands saves me a lot of time every day. I urge you to think about the repetitive processes and commands you use in your daily programs, and think about how you can turn them into slash commands. I believe this way of thinking is very important if you want to be at your best. editor.

👉 My Free Resources

🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)

📚 Get my free ebook Vision Language Models

💻 My webinar on Vision Language Models

👉 Find me on social media:

📩 Subscribe to my newsletter

🧑‍💻 Contact

🔗 LinkedIn

🐦 X / Twitter

✍️ In the middle