cursor-commands: thirty-two Markdown files, and no checks on them

A command is a Markdown file and a slash lists two directories at once

The mechanism is small enough to state in full. A Cursor command is a reusable AI prompt stored as a Markdown file in a commands directory, and typing a slash in the chat input makes the IDE list every command it finds.

There are two such directories and they are searched together. Project commands live in a dot-prefixed commands folder inside your repository. Global commands live in the same folder under your home directory.

The IDE scans both, combines the results into one list, and inserts the selected command into the chat ready to run. So a project command and a personal command with the same name are both offered, and nothing on the page says which one wins.

That is the whole feature. There is no manifest, no registry and no versioning: a file with a name in a directory is a command, and the name is what you type.

The recorded homepage is not this repository but a changelog page for version 1.6 of the editor, which dates the feature to a specific editor release rather than presenting it as a third-party extension.

Thirty-two commands across six headings, and the headings are a taxonomy

The catalogue is organised into six groups and the group sizes are uneven in a way that says something about the author's priorities.

Code quality and maintenance has seven entries, covering lint fixing, a lint suite, refactoring, performance analysis, error handling, task clarification and a command for cleaning up generated code. Review and collaboration has five. Testing and reliability has five.

Documentation and onboarding is the largest at eight, which is unusual for a collection aimed at engineers: it includes writing documentation, generating API documentation, onboarding a new developer, planning a new feature, and four separate commands for producing diagrams.

Security, accessibility and infrastructure has five, and that heading is where the grouping gets loose. A database migration command and a command for resolving merge conflicts sit under a security heading, neither of which is a security task.

The git workflow is the smallest at two. And the directory listing in the page is alphabetical while the catalogue is thematic, so a file's position depends on which part of the page you are reading.

Four commands generate diagrams and two generate security reviews

Reading the catalogue against itself surfaces the overlaps, and they are not accidental-looking.

Four commands produce diagrams. One generates visual diagrams and flowcharts from code or concepts. One generates Mermaid diagrams covering flowcharts, sequence, class, entity-relationship and state diagrams. One generates Mermaid diagrams for user journeys and architecture flow. One generates visual feature roadmaps.

Two of those four name Mermaid explicitly and two do not, which suggests they were written at different times or with different assumptions about what the model would produce. A team picking one at random from a slash menu has to know which of the four they want.

The security pair has the same shape. One is a structured checklist for code changes and one is a broader vulnerability and risk assessment workflow. The descriptions differ in scope but not in kind, and the narrower one is defined by being narrower.

The review surface overlaps too. There is a comprehensive review checklist, a quick pass that highlights risky diffs and cleanup items, a command to address reviewer feedback on a pull request, and a separate command to prepare the pull request itself.

The author has also written a command whose entire job is cleaning up code a coding agent generated, described as removing unnecessary complexity and verbosity. A collection of agent prompts containing a command for fixing agent output is a coherent thing to ship.

Installing means copying a dot directory, and cloning is the optional route

Two install routes are given and the second is the one most teams will use.

# Option 1: clone the repository
git clone https://github.com/hamzafer/cursor-commands.git
cd cursor-commands
# Option 2: copy commands into an existing project
cp -r cursor-commands/.cursor /path/to/your/project/

The first clones the repository and leaves you in its own directory, which is only useful if you want to read the files. The second copies the dot-prefixed configuration directory straight into an existing project, and it is a plain recursive copy with no merge step and no conflict handling.

That matters because a project that already has its own commands will silently get duplicates or overwritten files depending on what is there. Nothing on the page warns about it.

The third route is to create the directory by hand and author the files, which is what you do if you only want two of the thirty-two.

Writing a new one starts with an empty file in the commands directory. The page then supplies a template with a heading, a brief description, an objective section, a requirements section listing constraints, coding standards and expected formats, and an output section.

That template is the actual specification of what these files are: a structured brief for an agent, with an explicit objective and an explicit deliverable.

The whole repository is a dot directory, a gitignore, a licence and a readme

The top level of this repository is four entries and three of them are documents.

There is a gitignore, a licence and the README. The fourth is the dot-prefixed configuration directory that holds every command.

There is no source code, which is why the primary language is recorded as unknown rather than as a placeholder value. There is also no package manifest, no test suite and no continuous integration directory.

So there is no automated check that a command file still parses, still has the sections the template asks for, or still describes what its filename says. The catalogue on the page and the files in the directory can disagree, and nothing catches it.

The sibling repository is named on the front page and is the more interesting one for a reader who wants to extend this. It is a collection of hooks, described as running after every file edit, which is the other half of the same idea: commands shape what you ask for, hooks shape what happens without asking.

The recorded state is MIT licensed, main as the default branch, no releases, and a last recorded push of 2026-04-07.

Shareable means in git, which makes review the quality gate

The feature list has five entries and the third is the one that determines whether a team uses this at all.

Commands are described as shareable because they are stored in git, so they ship with the repository. The others are quick access, reusability, focus and customisability, which are all properties of a file.

Putting them in a repository means command files go through the same review as code. That is the mechanism behind the other claim in the list, that commands reinforce team standards and keep feedback consistent. A team convention that lives in someone's home directory is a convention that one person left.

It also means the global directory is the opposite case. A personal command is by definition outside review, which is the right place for something specific to one person and the wrong place for a team standard.

The two directories are scanned into one list with nothing distinguishing them, so the practical consequence is that a team convention and a personal shortcut are presented identically in the slash menu.

Two commands sit on either side of the git boundary

Two entries in the git workflow group are about moving work rather than judging it, and they are the two shortest descriptions in the whole catalogue.

One creates well-structured commit messages with optional issue key linking. One pushes changes to the remote with pre-push checks.

That pre-push check is the interesting half. A commit message command and a push command that runs checks before pushing together describe a team that wants the same checks whether or not a person remembers to run them.

Neither description mentions what happens when the checks fail, and neither mentions a force-push path or a hook. For a collection aimed at teams, the gap between having a pre-push check command and having a real pre-push hook is the same gap the sibling repository is described as closing.

Editorial conclusion

Use this if your team already commits its prompts and wants a starting vocabulary rather than writing every command from scratch, since putting them in the repository is what turns a personal habit into a reviewable convention. Skip it if you want something maintained, because the repository is four files and nothing checks that the thirty-two commands still parse or still describe what their names claim. Before you copy the directory into an existing project, look at what is already in your commands folder, because the install is a plain recursive copy with no merge step and no warning about collisions.

Frequently asked questions

Official sources

1. hamzafer/cursor-commands on GitHub
2. Issues
3. License: MIT
4. Project website
5. README