はじめに

プロジェクトごとに一々、RulesやSkillsを作るのが面倒なので、
GitHubにテンプレートとして置いておけばいいのでは？と思ったので、テンプレート化します

内容

構成は以下の感じでGitHubにリポジトリ作成します
スキルはコードレビュースキルだけです。必要に応じて追加してください。

cursor-template
  └─.cursor
      ├─rules
      │      project-rules.mdc
      │
      └─skills
          └─code-review
                  SKILL.md

以下はRuleのテンプレートです
{{ ... }}の中身をプロジェクトごとに編集します

project-rules.mdc

---
description: このプロジェクトで AI が従う共通ルール。他プロジェクトにコピーして使えるテンプレート。( {{ ... }} を実際の内容に置き換える )
globs:
alwaysApply: true
---

# Project Rules

## 適用範囲と優先度

- このファイルのルールは **グローバルルールより優先** する。
- このプロジェクト内のコード・ドキュメント・AI の回答に適用する。

---

## 言語・トーン

- 回答は **日本語** とする。
- コード内のコメント・変数名・コミットメッセージは、このプロジェクトの既存スタイルに合わせる。
- 説明は事実ベースで簡潔に。主観的な断定は避ける。

---

## 技術スタック（プロジェクトで編集）

<!-- 使用言語・フレームワークを記載。AI がコード例や提案の前提に使う -->

- **言語**: {{ 例: TypeScript, Python 3.11 }}
- **フレームワーク**: {{ 例: Next.js 14, FastAPI, なし }}
- **テスト**: {{ 例: Jest, pytest, Vitest }}
- **その他**: {{ 例: Prisma, SQLAlchemy }}

---

## コーディング規約

### 命名

- 変数・関数: **{{ camelCase / snake_case }}**
- クラス・型・コンポーネント: **{{ PascalCase }}**
- 定数: **{{ UPPER_SNAKE_CASE / camelCase }}**
- ファイル名: **{{ kebab-case.ts / snake_case.py }}**

### 関数・クラス

- 関数は **1 つの責務** に限定する。
- 長くなりそうな場合は分割を提案する。
- コメントは「何を」より「なぜ」を書く。

### フォーマット

- インデント: **{{ 2 スペース / 4 スペース / タブ }}**
- 行末: **LF**
- クォート: **{{ シングル / ダブル }}**（プロジェクトの既存に合わせる）

---

## API 設計（バックエンドがある場合）

- スタイル: **RESTful** を基本とする。
- レスポンスは共通形式とする:

  ```json
  {
    "success": true,
    "data": {},
    "error": null
  }
  ```

以下はSKILLのテンプレートです
こちらも、{{ ... }}の中身をプロジェクトごとに編集します

SKILL.md

---
name: code-review
description: コードの品質・セキュリティ・保守性をチェックリストに沿ってレビューする。ユーザーがコードレビューやPRレビューを依頼したとき、または /review や /code-review を使ったときに適用する。( {{ ... }} を実際の内容に置き換える )
---

# コードレビュー

## 適用タイミング

- ユーザーが {{ 依頼の言い方の例 }} と言ったとき
- ユーザーが {{ コマンド例: /review | /code-review }} を使ったとき

---

## レビュー方針

- **トーン**: {{ [選択: 厳しめ | バランス | 優しめ ] }}
- **重視する観点**（優先順）: {{ 例: セキュリティ → パフォーマンス → 可読性 }}
- **その他**: {{ プロジェクト固有の前提があれば。例: 既存の .cursor/rules に従う }}

---

## チェックリスト

<!-- 使う項目だけ残し、不要な見出しは削除。項目の追加・修正も自由 -->

### 正しさ・ロジック

- [ ] ロジックは正しく、境界値・異常系が考慮されているか
- [ ] エラーハンドリングは十分か
- [ ] 明らかなバグや競合条件がないか

### セキュリティ

- [ ] インジェクション（SQL・コマンド・XSS）のリスクがないか。入力は検証されているか
- [ ] 機密情報がログやレスポンスに含まれていないか
- [ ] 保護すべき操作に認証・認可チェックがあるか

### パフォーマンス

- [ ] N+1 クエリやループ内の重い I/O がないか
- [ ] データ構造・アルゴリズムは適切か
- [ ] 不要なオブジェクト生成やコピーがないか

### 保守性

- [ ] 関数は小さく単一責務か
- [ ] 名前は分かりやすく、コメントは「なぜ」を書いているか
- [ ] プロジェクトのスタイル・規約に沿っているか

### テスト

- [ ] 変更にテストが伴っているか
- [ ] 重要な経路やエッジケースがカバーされているか

---

## 指摘のフォーマット

指摘には次のラベルを付ける（文言は必要に応じて変更）。

- **【{{ 最優先のラベル名。例: 要対応 }}】** {{ 意味。例: マージ前に直すべき。重大な問題。 }}
- **【{{ 中程度のラベル名。例: 推奨 }}】** {{ 意味。例: できれば直したい。品質・保守性に影響。 }}
- **【{{ 軽いラベル名。例: 任意 }}】** {{ 意味。例: 余裕があれば。軽微な改善。 }}

各指摘には「どこが問題か」「なぜ問題か」「どう直すとよいか」を簡潔に書く。該当ファイル名・関数名があるとよい。

---

## レビュー手順

1. {{ ステップ1。例: コンテキスト（PR説明・既存パターン）を確認する }}
2. {{ ステップ2。例: 高リスク箇所（入力・DB・認証など）を特定する }}
3. {{ ステップ3。例: チェックリストに沿って確認する }}
4. {{ ステップ4。例: 指摘を優先度順にまとめ、改善案を添える }}

---

## 出力例（任意）

<!-- 実際の出力イメージを1つ書いておくと AI の振る舞いが揃いやすい -->

**総評**  
{{ 総評の書き方の例 }}

**指摘**

- **【{{ ラベル }}】** {{ 指摘1の例 }}
- **【{{ ラベル }}】** {{ 指摘2の例 }}

---

## 補足

- {{ プロジェクト固有の注意・参照ドキュメント・用語の説明など。なければこのセクションごと削除可 }}

コミット・プッシュしたら、リポジトリ設定からテンプレート化します

今後リポジトリ作成時はテンプレートを選択します

最後に

今回作成したテンプレートは一例です
内容に過不足があるかもしれませんが、今後運用して最適化するつもりです