How to Leverage Slash Commands to Code Effectively

are prompts you can store for your coding agent for easy access. This is typically very useful for prompts you use repeatedly, such as:

• Create a release pull request from the dev to the prod branch
• Analyze these log groups, and inform me of any issues
• Run pre-commit checks, push the code, and make a PR

These are all commands I run on a daily basis. Instead of typing out the prompts each time or storing the prompts somewhere, I can simply save them as slash commands in Claude Code or Warp.

This gives me super-fast access to my most commonly used prompts, saving me a lot of time on a daily basis.

In this article, I’ll discuss slash commands, what they are, and why they are so effective. Furthermore, I’ll cover some specific commands that I have saved and utilize regularly.

Why you should use slash commands

Slash commands are simply easy-to-access prompts that are super useful if you find yourself running a lot of repetitive prompts. I believe that a lot of the prompts most programmers use will be repeated prompts. It can, for example ,be:

• Creating pull requests
• Checking if the code is production-ready
• Writing documentation for a code base

These are all prompts you likely run on a regular basis. If so, you should make these prompts 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 store this as a command and write:

/make-pr

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

An additional benefit of using slash commands is that your commands will be consistent. You’ll always be running the same command, and never forget to write out parts of the command, for example, forgetting to run pre-commit checks. This is also a huge time-saver.

How to make slash commands

You create slash commands in different ways, depending on which tool you are using. However, I’ll provide link to three of the most common coding agent tools, and links to their respective documentation about slash commands:

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

You can then use the command by typing, slash and the command name. For example, to run the command make-pr you would write the command below into your coding agent

/make-pr

Some of my slash commands

In this section, I’ll describe some of the slash commands that I use on a daily basis. For each command, I’ll explain why it’s useful and how to use it.

Create release PR

A common coding practice is to have 3 types of branches:

• Feature branches (personal branches people use)
• A shared development branch
• A shared production branch

If you are using this structure, you likely create release PR’s from the development branch to the production branch. These PR’s typically follow a standard structure, highlighting the different changes that are being merged in. For example:

• Each change being added, and by whom
• Any useful links to documentation, Slack messages, or other relevant context
• A checklist that must be filled out before merging the code (quality assurance, etc.)

To create this, you typically prompt your coding agent to make a PR, with the specifications from the bullet point list above. However, this both takes time and can be inconsistent (as you might have small changes in your prompt every 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 release PR’s for your repository.

Create new feature branch PR

Probably the most common command I use it to create a new feature branch PR. After I’ve implemented a new feature, or fixed a bug, I have to do the following:

• Pull latest dev branch, to make sure I’m updated
• Branch off to a feature branch, from the newly pulled dev branch
• Run pre-commit checks on the new code
• Commit and push the code in the new feature branch
• Create a PR from the feature branch to the dev branch

I run this multiple times a day, and it’s thus way faster to run it as a slash command, like you 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 often also provide the feature branch name, as I use Linear branch naming, to automatically update the status of my issues, given the status of my code (if it’s in a feature branch, in dev, or in prod).

Generalize the knowledge from a thread

Another command command I use it to generalize knowledge from a thread. This is very useful, because I often find that agents behave a bit differently than desired, for example in how it implements a feature. Or the model might lack some knowledge that would be useful to have in any future interaction.

Thus, I tell the model to generalize the knowledge from the thread where I implemented a new feature, or fixed a bug. I use a prompt 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 typically run this command after the last command which creates a new pull request from my feature branch.

Production-ready code

I often find that asking my coding agent if the code is production-ready, is efficient at finding bugs and other issues. For some reason, prompting the model about production readiness, makes the model reflect on its implementation, and discover issues it overlooked earlier. I thus have a separate prompt I use to check whether my prompt is production-ready:

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.

A Cursor example

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

They for example provide a code review checklist, which the model can go through to perform code reviews. This is very useful to run reviews after you create PR’s, but is also useful to run as a pre-commit check.

You can see the code review slash command 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

Conclusion

In this article, I’ve discussed slash commands, and how they can make you a more effective programmer. Slash commands are simply prompts you store for easy access, typically used for prompts you run on a repeated basis. Using slash commands saves me a lot of time daily. I urge you to think about repeated processes and prompts you use in your day-to-day programming, and think of how you can convert it into slash commands. I belive this mindset is incredibly important if you want to become a more efficient. programmer.

👉 My Free Resources

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

📚 Get my free Vision Language Models ebook

💻 My webinar on Vision Language Models

👉 Find me on socials:

📩 Subscribe to my newsletter

🧑‍💻 Get in touch

🔗 LinkedIn

🐦 X / Twitter

✍️ Medium