毎回同じプロンプトを Agent に貼り付けていませんか。私も先月まではそうでした。「テストを書いて、命名は snake_case で、Vitest を使って…」を1日20回タイプしている自分に気づいて、さすがに笑いました。
Cursor 1.6 で正式追加されたカスタムスラッシュコマンドを2週間運用してみたら、その手打ちが /test の3打鍵で終わるようになったんです。今回はその実装手順と、私が実際に使っている7つのレシピを共有します。
結論:.cursor/commands/ に .md を置くだけで、チーム共有のプロンプトが完成する
先に結論から。Cursor カスタムスラッシュコマンドは、リポジトリ直下に .cursor/commands/ ディレクトリを作り、そこに Markdown ファイルを1つ置けば動きます。Agent 入力欄で / をタイプすればドロップダウンに出てきて、選ぶだけでプロンプトが挿入される仕組みです。
仕組み自体はシンプルで、.cursor/commands/ に .md ファイルを置き、Agent 入力で / を打ってドロップダウンから選ぶだけ。リポジトリに置くのでバージョン管理でチーム全員が同じプロンプトライブラリを共有できます。
つまり .cursor/rules/*.mdc が「常に効かせるルール」だとしたら、コマンドは「呼び出したときだけ効くプロンプト」。この使い分けが分かると設計がスッと通ります。
なぜ Cursor カスタムスラッシュコマンドが必要か
私が導入前に感じていた痛みは3つでした。
1つ目はプロンプトが個人資産で終わること。Notion に貼っていた「PR 説明文生成プロンプト」を、チームの誰も知らない。共有しても運用に載らない。
2つ目はタイプ量の多さ。Agent に指示するとき、前提・制約・出力フォーマットを毎回書き直す。1回3分でも、日に10回で30分溶けます。
3つ目はブレ。同じタスクでも私と同僚でプロンプトが違うから、レビュー時に出力の質がバラバラ。これが地味に効きます。
スラッシュコマンドが解決するのはまさにこの摩擦点で、リポジトリに置いた瞬間から全員が同じプロンプトを叩けるようになります。
セットアップ:3分で最初のコマンドを動かす
手を動かしましょう。既存のリポジトリで OK です。
ステップ1:ディレクトリを作る
mkdir -p .cursor/commandsそれだけです。拍子抜けするほど簡単でした。
ステップ2:最初のコマンドを書く
.cursor/commands/review.md を作って、以下を貼ります。
# Self Review
ステージ済みの変更をシニアエンジニアとしてレビューしてください。
## 観点
- ロジックの誤り、Null/Undefined の見落とし
- テストが不足している分岐
- 命名・可読性(3行以上のネストは指摘)
- パフォーマンス(N+1、不要な再レンダリング)
## 出力
- 深刻度(High/Med/Low)付きで箇条書き
- 修正案はコードブロックで提示
- 問題なければ「LGTM」の1行だけ返すステップ3:Cursor で呼び出す
Agent タブで /review とタイプ。ドロップダウンから選ぶと、上のプロンプトがそのまま挿入されます。あとは Enter を押すだけ。
ファイル名がそのままコマンド名になり、ファイル本文がプロンプトのテンプレートとして使われます。プロジェクトを跨いで使いたいものは ~/.cursor/commands/ に置けばグローバルコマンドになります。
この「グローバル/プロジェクト」の切り分けが後で効いてきます。
実際に使っている7つのレシピ
2週間試して残ったのがこの7つです。捨てたコマンドの方が多いくらいですが、残ったものは毎日叩いています。
1. /commit — Conventional Commits でメッセージ生成
# Commit Message
ステージ済み変更を Conventional Commits 形式でコミットしてください。
形式: `type(scope): description`
- type: feat / fix / refactor / test / docs / chore
- scope: 変更ディレクトリの最上位(例: api, ui, infra)
- description: 命令形・50字以内・末尾ピリオドなし
破壊的変更なら `!` を type の後に付ける。
本文は空行を挟んで箇条書きで理由を2〜4行。git diff --staged を Agent に読ませてから /commit を叩くと、9割そのまま採用できるメッセージが返ってきます。
2. /test — テスト雛形を書かせる
プロジェクトごとにテストフレームワークが違うので、これはプロジェクト側に置きます。
# Generate Tests
選択中のファイルに対して Vitest でテストを書いてください。
## 規約
- ファイル名は `*.test.ts`(同じディレクトリ)
- describe/it の日本語 OK
- 正常系1・境界1・異常系1 を最低セットとする
- モックは vi.mock、時刻固定は vi.setSystemTime を使う
- カバレッジ 80% を目標にする(100% は狙わない)3. /plan — 実装前に設計だけ返させる
# Plan Only
このタスクを実装する前に、以下を Markdown で返してください。コードは書かないこと。
1. 影響ファイル一覧(推測でよい)
2. 変更概要(各ファイル1〜2行)
3. 想定される副作用・破壊的変更
4. テスト戦略
5. 見積もり工数(S/M/L)
私が OK を出すまで実装に入らないでください。地味ですが、これがいちばん効きました。「勝手に書き始める Agent」を止める鎖として機能します。
4. /refactor — 単一責任で分解
# Refactor to SRP
選択範囲を Single Responsibility Principle に沿って分解してください。
- 30行超の関数は分割候補
- ネスト3段超は早期 return で平坦化
- 命名は動詞+目的語(例: fetchUserById)
- 分解した関数には JSDoc を1行だけ付ける
- 挙動を変えない。テストが全部通ることを確認して5. /docs — 関数コメント一括生成
# Doc Comments
選択ファイルの export された関数・型に JSDoc/TSDoc を付けてください。
- 説明は1〜2行
- @param は型ではなく意味を書く(型は TS が持っている)
- @returns は返り値の意味と、失敗ケースを1行
- @example は使いどころが自明でないときだけ6. /pr — PR 説明文を書かせる
# PR Description
現在のブランチと main の差分から PR 説明文を書いてください。
## テンプレ
### なぜ
(背景・課題を2〜3行)
### なに
(変更の要点を箇条書きで)
### 動作確認
- [ ] ローカルでテスト通過
- [ ] 手動確認したシナリオ(箇条書き)
### レビュー観点
(レビュアーに特に見てほしい点)7. /explain — 既存コードを新人向けに解説
# Explain for Newcomer
選択コードを、この分野を知らない新人エンジニアに説明してください。
- 前提知識を先に1〜2行で補足
- コードのブロックごとに「何をしているか」を書く
- なぜこの書き方なのか(代替案との比較)を末尾に添える
- 専門用語は初出で括弧書きで説明オンボーディング資料の下書きが3分で出ます。私はこれで社内 Wiki 記事を1本書きました。
.cursor/rules との使い分け(ここでハマった)
最初、私はコマンドとルールを混同していました。同じ .cursor/ 配下にあるし、両方プロンプトを扱うので当然です。でも役割が完全に別物でした。
ルールはプロンプトレベルで持続的・再利用可能なコンテキストを提供するもので、.cursor/rules に保存され、バージョン管理下でコードベースに紐づきます。
私の中の整理はこうです。
- ルール(
.cursor/rules/*.mdc):常に効かせたい約束事。「TypeScript の strict モードを守る」「日本語で回答する」など。呼び出さなくても発火する - コマンド(
.cursor/commands/*.md):呼び出したときだけ効くプロンプト。「今からテストを書いて」「今から PR 説明を書いて」など、タスク駆動
両方を書くのが正解です。ルールで土台を作り、コマンドで具体タスクを叩く。
運用の落とし穴3つ
2週間で私が踏んだ地雷を共有します。
1. コマンドを長く書きすぎる
スラッシュコマンドは短く保ってコンテキストを効率的に管理するのが鉄則で、目安は150行未満です。
私は最初 /test に「モックのパターン集」まで書き込んで200行超になり、Agent の応答が明らかに雑になりました。長い前提はルール側に逃がし、コマンドは**「今回のタスクの指示」だけ**に絞るのが正解です。
2. グローバルとプロジェクトを混ぜる
~/.cursor/commands/test.md と .cursor/commands/test.md の両方に /test を作ると、どちらが優先されるのか毎回考えるハメになります。私は「言語依存するもの(/test, /lint)はプロジェクト、言語非依存(/commit, /pr)はグローバル」に統一しました。
3. コマンドをチェーンさせようとする
/plan の後に /implement を自動で呼ぶ、みたいな連鎖を最初やろうとしましたが、うまくいきませんでした。コマンド同士のチェーン自体は可能ですが、人間が結果を確認する隙間を残したほうが結局速いです。Agent モードで暴走されるより、区切って回すほうが安心。
チーム導入のコツ:PR で1つずつ追加する
いきなり10個のコマンドを揃えて配布するのはやめたほうがいいです。私は最初にそれをやって、誰も使わないまま3週間経ちました。
代わりに、普通の機能実装 PR に .cursor/commands/xxx.md を1つだけ含める運用に変えました。「この PR で /review を追加しました。次回から使ってみてください」と Slack に流す。これで採用率が上がりました。
コマンドは資産なので、ライブラリと同じで育てるものだと考えるといいです。
まとめ:今日からやる3つのアクション
記事の内容を今日中に手を動かして試すなら、次の3ステップです。
mkdir -p .cursor/commandsしてreview.mdを1つ置く。中身は上の雛形をコピペで OK- 直近1週間で自分が Agent に3回以上貼り付けたプロンプトを思い出し、それを2つ目のコマンドにする
.gitignoreから.cursor/を外し、コミットしてチームに共有する
「毎回タイプしているプロンプト」は全部コマンド化候補です。私は結局7つに絞りましたが、あなたのプロジェクトなら別の7つがあるはず。まずは1つ、動かしてみてください。
参考リンク
- Cursor Docs — Slash commands (CLI reference) — Cursor 公式のスラッシュコマンド一次情報
- Prompts Ninja — Cursor 1.6 Slash Commands — 1.6 でのカスタムコマンド追加と仕様まとめ
- Toolsbase — Cursor Cheat Sheet 2026 —
.cursor/commands/の配置ルールとグローバル運用 - ReactSquad — Cursor Slash Commands — コマンド長の目安とチェーン運用の注意点