hamzafer/cursor-commands: a Markdown prompt library for Cursor's slash menu
Cursor Custom Slash Commands
At a glance
- What is it?
- This repository is a set of Markdown prompt files that Cursor surfaces when you type a slash in chat, plus a suggested directory layout for keeping them in version control. It is a prompt collection, not a tool you install, and its value depends entirely on whether the prompts match your team's workflow.
- Who is it for?
- Adopt it if your team already uses Cursor and you want a shared, git-tracked starting point for prompts like code-review.md or run-all-tests-and-fix.md, then edit those files to match your own test runner and review checklist. Skip it if your team is on a different editor, if you need a prompt to enforce anything mechanically, or if you want a maintained product rather than a set of Markdown files.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 162 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: prompts that live in people's heads and clipboards
Most teams using an AI coding assistant end up with a handful of prompts they retype or paste from a notes app: review this diff, write tests for this file, draft a PR description. The prompts drift between developers, and a new hire has no way to see what the team considers a good review request. This repository addresses that by treating prompts as files. The README describes commands as "reusable AI prompts saved as Markdown files in `.cursor/commands/`", and the stated goal is workflows that are "reusable, version-controlled" and live "directly inside the Cursor IDE". The intended audience is a team already working in Cursor that wants a shared starting set rather than each person maintaining private snippets. It is not a plugin, a CLI, or a service. Nothing here executes on its own.
How the slash menu finds your command files
The mechanism is directory scanning, not registration. According to the README, commands live in two places: project commands in `.cursor/commands` inside the repository, and global commands in `~/.cursor/commands` on the developer's machine. When you type `/` in Cursor's chat or agent input, the IDE scans both directories, combines the results into one list, and inserts the selected command's text into the chat. There is no build step, no manifest, and no index file. A command exists because a `.md` file exists in one of those two paths. That has a practical consequence worth stating plainly: the command list is per-machine plus per-repository, so two developers on the same repo see the same project commands but different personal ones. The repository itself is the source of the project-side files, and the README's example tree lists thirty-odd of them, from `code-review.md` and `write-unit-tests.md` to `deslop.md` and `fix-git-issues.md`. The file contents are the product. Everything else is convention.
Installing it: clone, copy, or write your own file
The README gives two installation paths. The first clones the repository: `git clone https://github.com/hamzafer/cursor-commands.git` followed by `cd cursor-commands`. The second copies the command directory into an existing project: `cp -r cursor-commands/.cursor /path/to/your/project/`. It also notes you can create `.cursor/commands/` manually and copy only the files you want. To add your own, the README suggests `touch .cursor/commands/my-custom-command.md` and shows a template with `# My Custom Command`, then `## Objective`, `## Requirements`, and `## Output` sections. That template is the only structural guidance the README offers, and it is thin: three headings and a line telling you to "provide clear instructions for the AI to follow". There is no documented convention for argument handling, no way to parameterize a command, and no stated limit on how many commands Cursor will list before the menu becomes unwieldy. If you copy the whole directory, you are taking on roughly thirty prompt files to read and adapt.
The commands are prompts, so they enforce nothing
This is the limitation that matters most. A file named `lint-suite.md` does not run your linter. It asks the model to run your linter, and whether that happens depends on the model, the context you gave it, and what your project's scripts are actually called. The same applies to `run-all-tests-and-fix.md` and `security-audit.md`. The README's own framing supports this reading: step three of the usage instructions is "Let the AI execute the prompt with the relevant project context". Execution is the model's job, not the file's. Two further constraints follow. First, the repository is Cursor-specific by construction, since the discovery path is Cursor's chat input; if your team is not on Cursor, these files are inert text. Second, the project ships no releases according to the material provided, and the README itself is the main documentation, so there is no changelog to consult when a command's behaviour changes. Treat each file as a draft you own after copying it, because the upstream copy will not track your project's conventions.
What you would use instead, and how it differs
The closest alternative is the editor's built-in prompt storage or a personal snippet manager: you keep your review and test prompts in your own notes and paste them when needed. The difference is scope and sharing. A snippet manager gives one developer a private, instantly editable library with no directory convention to follow and no repository to pull from. This project trades that for a shared, reviewable artifact: prompts go through the same pull request process as code, and a change to `code-review.md` is visible to the whole team in the diff. The cost is ceremony. Someone has to decide which of the thirty files the team actually wants, and someone has to maintain them as the project's scripts change. If your team is small, or if each developer's prompts are genuinely personal, the snippet approach is less work for the same result. The README also points to a companion repository, `hamzafer/cursor-hooks`, described as running "after every file edit", which addresses a different point in the loop: hooks fire automatically, commands fire when you type a slash.
Maintenance, licensing, and what the MIT file means here
The repository is MIT-licensed and not archived, with a last push date of 2026-04-07 in the supplied metadata. MIT is permissive: you can copy the command files into a private or commercial repository, modify them, and ship them, provided the licence terms are met. Because the files are prompts rather than linked code, there is no dependency to update and no version to pin. That cuts both ways. There is no upgrade path to break, and there is also no upgrade path at all: once you copy `.cursor/commands/` into your project, you have forked it, and pulling later changes means diffing directories by hand. The realistic maintenance cost is the time to read and rewrite the prompts you keep, plus whatever you spend re-editing them when your build or test commands change. This is not legal advice; check how your organisation handles attribution for copied files.
Who this is for, and the two files to read first
The fit is narrow and clear. You are on Cursor, you work in a repository where more than one person writes code, and you want a shared baseline for recurring prompts rather than a blank `.cursor/commands` directory. The repository is most useful as a reference for structure and coverage: it shows the range of tasks a team might want commands for, and the README's grouped list (code quality, review, testing, documentation, security, git) is a reasonable checklist when deciding what your own set should contain. The wrong fit is a solo developer with no sharing need, a team on another editor, or anyone hoping a command will guarantee a lint pass or a complete test run. Before adopting, open `code-review.md` and `run-all-tests-and-fix.md` and check whether the instructions they give the model name scripts your project actually has; if they reference a test command you do not use, that is the first file you rewrite, and it tells you how much of the rest needs the same treatment.
Editorial conclusion
Adopt it if your team already uses Cursor and you want a shared, git-tracked starting point for prompts like code-review.md or run-all-tests-and-fix.md, then edit those files to match your own test runner and review checklist. Skip it if your team is on a different editor, if you need a prompt to enforce anything mechanically, or if you want a maintained product rather than a set of Markdown files. Before copying the directory in, read two or three of the command files end to end and confirm the instructions they give the model match commands your project actually has.
Community notes