are prompts you’ll be able to retailer to your coding agent for straightforward entry. That is sometimes very helpful for prompts you utilize repeatedly, equivalent to:
- Create a launch pull request from the dev to the prod department
- Analyze these log teams, and inform me of any points
- Run pre-commit checks, push the code, and make a PR
These are all instructions I run each day. As an alternative of typing out the prompts every time or storing the prompts someplace, I can merely save them as slash instructions in Claude Code or Warp.
This provides me super-fast entry to my mostly used prompts, saving me lots of time each day.
On this article, I’ll focus on slash instructions, what they’re, and why they’re so efficient. Moreover, I’ll cowl some particular instructions that I’ve saved and make the most of frequently.

Why it is best to use slash instructions
Slash instructions are merely easy-to-access prompts which are tremendous helpful if you end up operating lots of repetitive prompts. I imagine that lots of the prompts most programmers use will probably be repeated prompts. It will possibly, for instance ,be:
- Creating pull requests
- Checking if the code is production-ready
- Writing documentation for a code base
These are all prompts you probably run frequently. In that case, it is best to make these prompts into slash instructions. As an alternative of writing:
Verify if the code is manufacturing prepared, 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’ll be able to merely retailer this as a command and write:
/make-pr
With the current developments of coding brokers, I discover myself writing much more code and thus making much more pull requests. I subsequently write this immediate anyplace from 2 to 10 occasions a day. The time writing out the immediate, subsequently, provides up rapidly, and I save lots of time merely utilizing the slash command as an alternative.
An extra advantage of utilizing slash instructions is that your instructions will probably be constant. You’ll at all times be operating the identical command, and always remember to write down out elements of the command, for instance, forgetting to run pre-commit checks. That is additionally an enormous time-saver.
The way to make slash instructions
You create slash instructions in several methods, relying on which device you might be utilizing. Nonetheless, I’ll present hyperlink to a few of the most typical coding agent instruments, and hyperlinks to their respective documentation about slash instructions:
Basically nevertheless, you’ll be able to merely immediate any coding device, give it a immediate and a reputation, and inform it to create the slash command for you.
You’ll be able to then use the command by typing, slash and the command identify. For instance, to run the command make-pr you’ll write the command beneath into your coding agent
/make-pr
A few of my slash instructions
On this part, I’ll describe among the slash instructions that I take advantage of each day. For every command, I’ll clarify why it’s helpful and the right way to use it.
Create launch PR
A typical coding follow is to have 3 sorts of branches:
- Function branches (private branches individuals use)
- A shared improvement department
- A shared manufacturing department
If you’re utilizing this construction, you probably create launch PR’s from the event department to the manufacturing department. These PR’s sometimes comply with a normal construction, highlighting the totally different modifications which are being merged in. For instance:
- Every change being added, and by whom
- Any helpful hyperlinks to documentation, Slack messages, or different related context
- A guidelines that should be crammed out earlier than merging the code (high quality assurance, and many others.)
To create this, you sometimes immediate your coding agent to make a PR, with the specs from the bullet level listing above. Nonetheless, this each takes time and might be inconsistent (as you may need small modifications in your immediate each time you write it).
As an alternative, create a slash command like:
Create a launch PR from the dev department to the primary department. The PR ought to
embrace:
- every change being added, and by whom
- hyperlinks to related context used for an of the modifications (slack messages and many others)
- a guidelines of things that needs to be achieved earlier than merging, if related. For
instance: "carry out QA testing in dev department"
Now you’ll be able to rapidly and persistently create launch PR’s to your repository.
Create new characteristic department PR
In all probability the most typical command I take advantage of it to create a brand new characteristic department PR. After I’ve applied a brand new characteristic, or mounted a bug, I’ve to do the next:
- Pull newest dev department, to verify I’m up to date
- Department off to a characteristic department, from the newly pulled dev department
- Run pre-commit checks on the brand new code
- Commit and push the code within the new characteristic department
- Create a PR from the characteristic department to the dev department
I run this a number of occasions a day, and it’s thus means quicker to run it as a slash command, such as you see beneath:
Given the modifications, I now must create a PR. Do the next:
- Pull the most recent dev department
- Department off to a brand new characteristic department from the dev department
- Run pre-commit checks to verify my code is manufacturing prepared
- Commit and push the characteristic department
- Create a PR from the characteristic department to the primary department
I typically additionally present the characteristic department identify, as I take advantage of Linear department naming, to mechanically replace the standing of my points, given the standing of my code (if it’s in a characteristic department, in dev, or in prod).
Generalize the information from a thread
One other command command I take advantage of it to generalize information from a thread. That is very helpful, as a result of I typically discover that brokers behave a bit in a different way than desired, for instance in the way it implements a characteristic. Or the mannequin may lack some information that will be helpful to have in any future interplay.
Thus, I inform the mannequin to generalize the information from the thread the place I applied a brand new characteristic, or mounted a bug. I take advantage of a immediate like:
Generalize the information from this thread, saving all helpful, generalizable
information that's helpful for future coding on this repository. Retailer the
knowedge in AGENTS.md
I sometimes run this command after the final command which creates a brand new pull request from my characteristic department.
Manufacturing-ready code
I typically discover that asking my coding agent if the code is production-ready, is environment friendly at discovering bugs and different points. For some motive, prompting the mannequin about manufacturing readiness, makes the mannequin replicate on its implementation, and uncover points it missed earlier. I thus have a separate immediate I take advantage of to verify whether or not my immediate is production-ready:
Verify if the brand new code created on this department is manufacturing prepared. You must
search for any potential points when operating this code in manufacturing, and
guarantee all assessments and pre-commit checks run as anticipated. If you happen to detect any
points, present me a report concerning the points, their severity, and the way we will
resolve them.
A Cursor instance
I additionally wish to spotlight a slash command instance that Cursor gives in their documentation.
They for instance present a code overview guidelines, which the mannequin can undergo to carry out code evaluations. That is very helpful to run evaluations after you create PR’s, however can also be helpful to run as a pre-commit verify.
You’ll be able to see the code overview slash command beneath:
# Code Evaluation Guidelines
## Overview
Complete guidelines for conducting thorough code evaluations to make sure high quality, safety, and maintainability.
## Evaluation Classes
### Performance
- [ ] Code does what it is speculated to do
- [ ] Edge instances are dealt with
- [ ] Error dealing with is suitable
- [ ] No apparent bugs or logic errors
### Code High quality
- [ ] Code is readable and well-structured
- [ ] Capabilities are small and centered
- [ ] Variable names are descriptive
- [ ] No code duplication
- [ ] Follows undertaking conventions
### Safety
- [ ] No apparent safety vulnerabilities
- [ ] Enter validation is current
- [ ] Delicate information is dealt with correctly
- [ ] No hardcoded secrets and techniques
Conclusion
On this article, I’ve mentioned slash instructions, and the way they’ll make you a more practical programmer. Slash instructions are merely prompts you retailer for straightforward entry, sometimes used for prompts you run on a repeated foundation. Utilizing slash instructions saves me lots of time day by day. I urge you to consider repeated processes and prompts you utilize in your day-to-day programming, and consider how one can convert it into slash instructions. I belive this mindset is extremely necessary if you wish to turn out to be a extra environment friendly. programmer.
👉 My Free Sources
🚀 10x Your Engineering with LLMs (Free 3-Day Electronic mail Course)
📚 Get my free Imaginative and prescient Language Fashions e-book
💻 My webinar on Imaginative and prescient Language Fashions
👉 Discover me on socials:
🧑💻 Get in contact
✍️ Medium















