カスタムコマンドを使うと、チャット入力欄で「/」を付けるだけで呼び出せる再利用可能なワークフローを作成できる。コマンドはチーム全体のプロセスを標準化し、よくある作業をより効率的にしてくれる。
コマンドは現在ベータ版。今後の改良に伴い、機能や構文が変更される場合がある。
- プロジェクトコマンド: プロジェクトの
.cursor/commands ディレクトリに保存
- グローバルコマンド: ホームディレクトリの
~/.cursor/commands ディレクトリに保存
チャットの入力欄で / を打つと、Cursor が両方のディレクトリから使えるコマンドを自動検出して表示し、ワークフロー全体で即座に使えるようになる。
- プロジェクトのルートに
.cursor/commands ディレクトリを作成
- 説明的な名前の
.md ファイルを追加（例: review-code.md, write-tests.md）
- コマンドの目的と挙動を説明するプレーンな Markdown を書く
- チャットで
/ を入力すると、コマンドが自動的に表示される
コマンドディレクトリの構成は次のようになる例:
.cursor/
└── commands/
├── address-github-pr-comments.md
├── code-review-checklist.md
├── create-pr.md
├── light-review-existing-diffs.md
├── onboard-new-developer.md
├── run-all-tests-and-fix.md
├── security-audit.md
└── setup-new-feature.md
# コードレビュー・チェックリスト
## 概要
品質・セキュリティ・保守性を確保するための徹底的なコードレビュー用チェックリスト。
## レビューカテゴリ
### 機能
- [ ] コードが意図どおりに動作している
- [ ] 例外的なケースまで考慮されている
- [ ] エラーハンドリングが適切
- [ ] 明らかなバグやロジックエラーがない
### コード品質
- [ ] 読みやすく、構造が明確
- [ ] 関数が小さく、責務が明確
- [ ] 変数名がわかりやすい
- [ ] 重複コードがない
- [ ] プロジェクトの規約に従っている
### セキュリティ
- [ ] 明らかなセキュリティ上の脆弱性がない
- [ ] 入力バリデーションが実装されている
- [ ] 機微なデータが適切に扱われている
- [ ] シークレットがハードコードされていない
# セキュリティ監査
## 概要
コードベースの脆弱性を特定して修正するための包括的なセキュリティレビュー
## 手順
1. **依存関係の監査**
- 既知の脆弱性を確認
- 旧バージョンのパッケージを更新
- サードパーティ依存関係をレビュー
2. **コードセキュリティレビュー**
- 代表的な脆弱性を確認
- 認証／認可をレビュー
- データ取り扱いの方針・実装を監査
3. **インフラセキュリティ**
- 環境変数の管理をレビュー
- アクセス制御を確認
- ネットワークセキュリティを監査
## セキュリティチェックリスト
- [ ] 依存関係が最新かつ安全
- [ ] ハードコードされたシークレットがない
- [ ] 入力検証が実装済み
- [ ] 認証が安全
- [ ] 認可が適切に構成済み
# 新機能のセットアップ
## 概要
初期の企画から実装体制の構築まで、新機能を体系的にセットアップする。
## 手順
1. **要件定義**
- 機能のスコープと目標を明確にする
- ユーザーストーリーと受け入れ条件を洗い出す
- 技術的アプローチを策定する
2. **フィーチャーブランチを作成**
- main/develop からブランチを切る
- ローカル開発環境をセットアップする
- 新規依存関係を設定する
3. **アーキテクチャ設計**
- データモデルと API を設計する
- UI コンポーネントとフローを設計する
- テスト戦略を検討する
## 機能セットアップ・チェックリスト
- [ ] 要件が文書化されている
- [ ] ユーザーストーリーが作成されている
- [ ] 技術的アプローチが策定されている
- [ ] フィーチャーブランチが作成されている
- [ ] 開発環境が整備されている
# PR を作成
## 概要
適切な説明・ラベル・レビュアーを含む、よく整理されたプルリクエストを作成する。
## 手順
1. **ブランチを準備**
- すべての変更がコミットされていることを確認
- ブランチをリモートにプッシュ
- ブランチが main と最新同期されていることを確認
2. **PR の説明を書く**
- 変更点を明確に要約
- 背景や目的を含める
- 破壊的変更があれば列挙
- UI の変更があればスクリーンショットを追加
3. **PR を設定**
- 内容が伝わるタイトルで PR を作成
- 適切なラベルを追加
- レビュアーをアサイン
- 関連する issue をリンク
## PR テンプレート
- [ ] 機能 A
- [ ] バグ修正 B
- [ ] ユニットテスト合格
- [ ] 手動テスト完了
# すべてのテストを実行して失敗を修正する
## 概要
フルテストスイートを実行し、失敗を体系的に修正して、コード品質と機能を確保する。
## 手順
1. **テストスイートを実行**
- プロジェクト内のすべてのテストを実行
- 出力を収集して失敗を特定
- ユニットテストと統合テストの両方を確認
2. **失敗を分析**
- 種別で分類: フレーク、破損、新規の失敗
- 影響度に基づいて修正の優先度を決定
- 失敗が直近の変更に起因していないか確認
3. **体系的に問題を修正**
- 最もクリティカルな失敗から着手
- 1件ずつ修正
- 各修正後にテストを再実行
# 新任開発者のオンボーディング
## 概要
新任開発者がすぐに開発を開始できるようにする包括的なオンボーディング手順。
## 手順
1. **環境セットアップ**
- 必要なツールをインストール
- 開発環境をセットアップ
- IDE と拡張機能を設定
- Git と SSH 鍵をセットアップ
2. **プロジェクトの理解**
- プロジェクト構成を確認
- アーキテクチャを把握
- 主要ドキュメントを読む
- ローカルデータベースをセットアップ
## オンボーディングチェックリスト
- [ ] 開発環境の準備完了
- [ ] すべてのテストが合格
- [ ] アプリケーションをローカルで実行できる
- [ ] データベースのセットアップと動作確認済み
- [ ] 最初の PR を提出
