are prompts you may store on your coding agent for easy accessibility. This is usually very useful for prompts you utilize repeatedly, resembling:
- 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 each day. As a substitute of typing out the prompts every time or storing the prompts somewhere, I can simply save them as slash commands in Claude Code or Warp.
This offers me super-fast access to my mostly used prompts, saving me numerous time each day.
In this text, I’ll discuss slash commands, what they’re, and why they’re so effective. Moreover, I’ll cover some specific commands that I actually have saved and utilize repeatedly.
Why it is best to use slash commands
Slash commands are simply easy-to-access prompts which might be super useful if you happen to end up running numerous repetitive prompts. I consider that numerous the prompts most programmers use can be repeated prompts. It may, for instance ,be:
- Creating pull requests
- Checking if the code is production-ready
- Writing documentation for a code base
These are all prompts you likely run regularly. If that’s the case, it is best to make these prompts into slash commands. As a substitute 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 supply me
the url to the PR.You may simply store this as a command and write:
/make-prWith the recent advancements of coding agents, I find myself writing lots more code and thus making lots more pull requests. I due to this fact write this prompt anywhere from 2 to 10 times a day. The time writing out the prompt, due to this fact, adds up quickly, and I save numerous time simply using the slash command as a substitute.
A further good thing about using slash commands is that your commands can be consistent. You’ll all the time be running the identical command, and always remember to put in writing out parts of the command, for instance, forgetting to run pre-commit checks. This can also be an enormous time-saver.
The best way to make slash commands
You create slash commands in alternative ways, depending on which tool you might be using. Nevertheless, I’ll provide link to 3 of probably the most common coding agent tools, and links to their respective documentation about slash commands:
Normally nonetheless, you may simply prompt any coding tool, give it a prompt and a reputation, and tell it to create the slash command for you.
You may then use the command by typing, slash and the command name. For instance, to run the command you’d write the command below into your coding agent
/make-prA few of my slash commands
On this section, I’ll describe a number of the slash commands that I take advantage of each day. For every command, I’ll explain why it’s useful and use it.
Create release PR
A standard coding practice is to have 3 varieties of branches:
- Feature branches (personal branches people use)
- A shared development branch
- A shared production branch
If you happen to are using this structure, you likely create release PR’s from the event branch to the production branch. These PR’s typically follow an ordinary structure, highlighting the several changes which might be being merged in. For instance:
- Each change being added, and by whom
- Any useful links to documentation, Slack messages, or other relevant context
- A checklist that have to be filled out before merging the code (quality assurance, etc.)
To create this, you sometimes prompt your coding agent to make a PR, with the specifications from the bullet point list above. Nevertheless, this each takes time and will be inconsistent (as you would possibly have small changes in your prompt each time you write it).
As a substitute, create a slash command like:
Create a release PR from the dev branch to the most important 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 things that must be done before merging, if relevant. For
example: "perform QA testing in dev branch"Now you may quickly and consistently create release PR’s on your repository.
Create recent feature branch PR
Probably probably the most common command I take advantage of it to create a brand new feature branch PR. After I’ve implemented a brand new feature, or fixed a bug, I actually have to do the next:
- Pull latest dev branch, to be sure I’m updated
- Branch off to a feature branch, from the newly pulled dev branch
- Run pre-commit checks on the brand new code
- Commit and push the code in the brand 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, such as you see below:
Given the changes, I now must create a PR. Do the next:
- Pull the most recent dev branch
- Branch off to a brand new feature branch from the dev branch
- Run pre-commit checks to be sure my code is production ready
- Commit and push the feature branch
- Create a PR from the feature branch to the most important branchI often also provide the feature branch name, as I take advantage of Linear branch naming, to robotically 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
One other command command I take advantage of it to generalize knowledge from a thread. This may be very useful, because I often find that agents behave a bit otherwise than desired, for instance in the way it implements a feature. Or the model might lack some knowledge that may be useful to have in any future interaction.
Thus, I tell the model to generalize the knowledge from the thread where I implemented a brand new feature, or fixed a bug. I take advantage of a prompt like:
Generalize the knowledge from this thread, saving all useful, generalizable
knowledge that is helpful for future coding on this repository. Store the
knowedge in AGENTS.mdI typically run this command after the last command which creates a brand 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 neglected earlier. I thus have a separate prompt I take advantage of to ascertain whether my prompt is production-ready:
Check if the brand new code created on this branch is production ready. You must
search for any potential issues when running this code in production, and
ensure all tests and pre-commit checks run as expected. If you happen to detect any
issues, provide me a report concerning the issues, their severity, and the way we will
resolve them.A Cursor example
I also want to focus on a slash command example that Cursor provides in their documentation.
They for instance provide a code review checklist, which the model can undergo to perform code reviews. This may be very useful to run reviews after you create PR’s, but can also be useful to run as a pre-commit check.
You may see the code review slash command below:
# Code Review Checklist
## Overview
Comprehensive checklist for conducting thorough code reviews to make sure quality, security, and maintainability.
## Review Categories
### Functionality
- [ ] Code does what it's imagined to do
- [ ] Edge cases are handled
- [ ] Error handling is suitable
- [ ] 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 secretsConclusion
In this text, I’ve discussed slash commands, and the way they will make you a simpler programmer. Slash commands are simply prompts you store for easy accessibility, typically used for prompts you run on a repeated basis. Using slash commands saves me numerous time every day. I urge you to take into consideration repeated processes and prompts you utilize in your day-to-day programming, and consider how you may convert it into slash commands. I belive this mindset is incredibly vital if you must turn into 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:
🧑💻 Get in contact
✍️ Medium
