.cursor/commands로 자주 쓰는 프롬프트를 명령으로?

채팅에 매번 같은 리뷰·커밋·점검 프롬프트를 붙여 넣는다면, 그걸 슬래시 커맨드로 고정할 수 있습니다. Cursor에서 커맨드는 재사용 프롬프트이고, /이름으로 Agent 채팅에서 호출합니다. 가격·플랜·Skills 전체 비교는 다루지 않습니다.

이 글은 파일이 어디 있는지, 인자를 어떻게 쓰는지, rules와 무엇이 다른지만 정리합니다. 근거는 Customize Cursor, Plugins — Commands format, Rules, Command deeplinks입니다.

파일은 어디?

한 줄 답: 프로젝트는 .cursor/commands/, 개인 전역은 **~/.cursor/commands/**에 Markdown(또는 텍스트) 파일을 둡니다. 파일명이 / 뒤 이름이 됩니다.

공식·플러그인 문서 기준으로 두는 위치:

위치범위메모
.cursor/commands/*.md워크스페이스(레포)Git에 넣어 팀과 공유
~/.cursor/commands/유저(로컬 전역)개인 단축; 레포에 안 탐
플러그인 commands/플러그인 번들마켓/팀 플러그인으로 배포

실무에서 파일을 만드는 순서:

  1. 레포 루트에 .cursor/commands/를 만듭니다.
  2. code-review.md처럼 kebab-case 파일명을 씁니다 → 채팅에서 /code-review.
  3. 본문에 해야 할 절차·출력 형식·금지 사항을 Markdown으로 적습니다.
  4. (선택) YAML frontmatter에 name, description을 둡니다. 플러그인 Commands format이 이 필드를 안내합니다.
  5. Agent 채팅 입력창에 /를 치면 프로젝트·전역 목록이 합쳐져 보입니다.

최소 예시:

---
name: code-review
description: 열린 diff를 체크리스트로 리뷰
---

# Code review

1. 변경 범위와 리스크를 한 단락으로 요약한다.
2. 버그·회귀·시크릿·테스트 공백만 지적한다.
3. 수정 PR 코멘트 형태로 짧게 쓴다.

확장자는 플러그인 문서 기준 .md / .mdc / .markdown / .txt입니다. 일상 레포에서는 .md 하나 = 커맨드 하나로 충분합니다. 커맨드 deeplink로 이름·본문을 공유할 수도 있지만, 받는 쪽이 확인한 뒤에야 등록됩니다.

인자는 어떻게?

한 줄 답: /커맨드 뒤에 적은 텍스트가 이번 실행의 맥락으로 붙습니다. Claude Code식 $ARGUMENTS 템플릿을 가정하지 말고, **본문에 “뒤에 붙인 텍스트를 이렇게 써라”**고 명시합니다.

실무 패턴:

패턴입력 예커맨드 본문이 지시할 일
꼬리 텍스트/fix-issue 456이슈 번호·URL을 가져와 재현·수정
자연어 꼬리/fix-issue 이메일 검증 추가뒤 문장을 요구사항으로 사용
컨텍스트 중심/commit-msgstaged diff·열린 파일만 보고 동작
선택 영역/explain-selection (선택 후)에디터 선택·@파일을 전제로 설명

꼬리 인자를 쓰는 본문 예시:

# Fix issue

뒤에 이슈 번호, URL, 또는 한 줄 요구사항이 있으면 그걸 우선한다.
없으면 현재 대화·열린 파일에서 재현 경로를 먼저 확인한다.

1. 재현·실패 조건을 적는다.
2. 최소 수정으로 고친다.
3. 검증 명령을 실행하고 결과를 보고한다.

설계 팁:

  1. 위치 인자·플래그 파서를 기대하지 않습니다. 꼬리는 raw 텍스트입니다.
  2. 같은 커맨드가 컨텍스트만으로도 동작하게 폴백을 적습니다(열린 파일, staged diff).
  3. 인자가 필수면 본문 첫 줄에 “없으면 사용자에게 한 줄만 물어라”를 넣습니다.
  4. 팀 공유 커맨드는 출력 스키마(표·체크리스트·커밋 메시지 형식)를 고정해 반복 품질을 맞춥니다.

rules와 차이는?

한 줄 답: rules는 세션에 스며드는 지속 지시이고, commands는 /로 그때그때 꽂는 재사용 프롬프트입니다. 파일 위치·발화 시점이 다릅니다.

축Commands (.cursor/commands)Rules (.cursor/rules)
정체재사용 프롬프트·워크플로 단축시스템 수준 지속 지침
트리거채팅에서 /이름 (명시 호출)Always / Intelligent / globs / @rule
파일.md(등), 파일명≈커맨드명.mdc + frontmatter(alwaysApply, globs, …)
인자꼬리 텍스트·현재 컨텍스트정적; 호출마다 파라미터가 없음
길이 감각절차·체크리스트가 길어도 됨짧게·집중(문서: 대략 500줄 미만 권장)
역할 예코드 리뷰, PR 초안, 보안 점검 한 방스타일·아키텍처·도메인 제약

같이 쓰는 실무:

  1. 항상 지켜야 할 것(라이선스 헤더, 금지 import, 테스트 규칙) → rule.
  2. 가끔 같은 절차를 돌릴 것(릴리스 체크, diff 리뷰) → command.
  3. rule에 워크플로 전체를 넣지 않습니다. 매 채팅 컨텍스트만 커집니다.
  4. command 본문에 “프로젝트 rules·AGENTS.md를 따른다” 한 줄을 두면, 지속 규칙과 일회 절차가 겹치지 않습니다.

이 글이 다루지 않는 것: Skills vs Rules 전체 매트릭스, /migrate-to-skills 세부, 요금·요청 한도 숫자.

FAQ

/를 쳐도 내 커맨드가 안 보여요

경로가 레포 루트 .cursor/commands/(또는 ~/.cursor/commands/)인지, 확장자가 지원 목록인지 확인합니다. 파일명에 공백·대문자가 많으면 kebab-case로 바꿉니다. 채팅을 새로 열거나 창을 다시 띄운 뒤 /를 다시 칩니다.

frontmatter name이 파일명과 다르면?

플러그인·배포 맥락에서는 name이 식별자로 쓰입니다. 워크스페이스 일상 사용에서는 파일명 = 호출명으로 맞추는 편이 덜 헷갈립니다. 둘을 어긋나게 두지 않는 것을 권장합니다.

rules에 같은 체크리스트를 넣어도 되나요?

가능하지만 Always 규칙이면 매 대화에 실립니다. 가끔만 돌릴 절차는 command가 맞습니다. “항상 적용되는 짧은 제약”과 “명시 호출하는 긴 절차”를 나눕니다.

출처 (Sources)