Skip to main content

caret-rules

Caret Rulesを使用すると、Clineにシステムレベルのガイダンスを提供できます。プロジェクトまたはすべての会話に対してグローバルに、コンテキストと設定を永続的に含める方法と考えてください。

ルールの作成​

Rulesタブの+ボタンをクリックしてルールを作成できます。これによりIDEで新しいファイルが開き、ルールを記述できます。

ルールの作成

ファイルを保存すると：

  • ルールはプロジェクトの.clinerules/ディレクトリに保存されます（ワークスペースルールの場合）
  • またはGlobal Rulesディレクトリに保存されます（グローバルルールの場合）：

グローバルルールディレクトリの場所​

グローバルルールディレクトリの場所は、オペレーティングシステムによって異なります：

オペレーティングシステムデフォルトの場所注意事項
WindowsDocuments\Caret\RulesシステムのDocumentsフォルダを使用
macOS~/Documents/Caret/RulesユーザーのDocumentsフォルダを使用
Linux/WSL~/Documents/Caret/Rules一部のシステムでは~/Caret/Rulesにフォールバックする場合があります

Linux/WSLユーザーへの注意: ~/Documents/Caret/Rulesにグローバルルールが見つからない場合は、システム構成とDocumentsディレクトリが存在するかどうかによって場所が異なる可能性があるため、~/Caret/Rulesを確認してください。

チャットで/newruleスラッシュコマンドを使用してClineにルールを作成してもらうこともできます。

# プロジェクトガイドライン

## ドキュメント要件

-   機能を変更する際は、/docsの関連ドキュメントを更新する
-   README.mdを新機能と同期させる
-   CHANGELOG.mdに変更ログエントリを維持する

## アーキテクチャ決定記録

以下の場合に/docs/adrでADRを作成：

-   主要な依存関係の変更
-   アーキテクチャパターンの変更
-   新しい統合パターン
-   データベーススキーマの変更
    /docs/adr/template.mdのテンプレートに従う

## コードスタイルとパターン

-   OpenAPI GeneratorでAPIクライアントを生成
-   TypeScript axiosテンプレートを使用
-   生成されたコードは/src/generatedに配置
-   継承より合成を優先
-   データアクセスにはリポジトリパターンを使用
-   /src/utils/errors.tsのエラーハンドリングパターンに従う

## テスト標準

-   ビジネスロジックには単体テストが必要
-   APIエンドポイントには統合テスト
-   重要なユーザーフローにはE2Eテスト

主要な利点​

  1. バージョン管理: .clinerulesファイルがプロジェクトのソースコードの一部になります
  2. チームの一貫性: すべてのチームメンバー間で一貫した動作を保証します
  3. プロジェクト固有: 各プロジェクトのニーズに合わせたルールと標準
  4. 組織的知識: プロジェクトの標準と慣行をコードで維持します

.clinerulesファイルをプロジェクトのルートディレクトリに配置します：

your-project/
├── .clinerules
├── src/
├── docs/
└── ...

一方、Clineのシステムプロンプトはユーザーが編集できません（ここで見つけることができます）。プロンプトエンジニアリングのベストプラクティスについてより広く知りたい場合は、このリソースを確認してください。

効果的なClineルールを書くためのヒント​

  • 明確で簡潔に: シンプルな言葉を使い、曖昧さを避ける
  • 望む結果に焦点を当てる: 具体的な手順ではなく、求める結果を説明する
  • テストと反復: ワークフローに最適なものを見つけるために実験する

.clinerules/ フォルダシステム​

your-project/
├── .clinerules/              # アクティブなルールを含むフォルダ
│   ├── 01-coding.md          # コアコーディング標準
│   ├── 02-documentation.md   # ドキュメント要件
│   └── current-sprint.md     # 現在の作業に固有のルール
├── src/
└── ...

Clineは.clinerules/ディレクトリ内のすべてのMarkdownファイルを自動的に処理し、統一されたルールセットに結合します。数字のプレフィックス（オプション）は、ファイルを論理的な順序で整理するのに役立ちます。

ルールバンクの使用​

複数のコンテキストやチームがあるプロジェクトでは、ルールバンクディレクトリを維持します：

your-project/
├── .clinerules/              # アクティブなルール - 自動的に適用
│   ├── 01-coding.md
│   └── client-a.md
│
├── clinerules-bank/          # 利用可能だが非アクティブなルールのリポジトリ
│   ├── clients/              # クライアント固有のルールセット
│   │   ├── client-a.md
│   │   └── client-b.md
│   ├── frameworks/           # フレームワーク固有のルール
│   │   ├── react.md
│   │   └── vue.md
│   └── project-types/        # プロジェクトタイプの標準
│       ├── api-service.md
│       └── frontend-app.md
└── ...

フォルダアプローチの利点​

  1. コンテキスト依存のアクティベーション: バンクから関連するルールのみをアクティブフォルダにコピー
  2. 保守の簡素化: 他に影響を与えることなく個別のルールファイルを更新
  3. チームの柔軟性: チームメンバーが現在のタスクに固有のルールをアクティベート
  4. ノイズの削減: アクティブなルールセットを集中的かつ関連性の高いものに保つ

使用例​

クライアントプロジェクト間の切り替え：

# クライアントBプロジェクトに切り替え
rm .clinerules/client-a.md
cp clinerules-bank/clients/client-b.md .clinerules/

異なる技術スタックへの適応：

# フロントエンドReactプロジェクト
cp clinerules-bank/frameworks/react.md .clinerules/

実装のヒント​

  • 個別のルールファイルは特定の関心事に焦点を当てる
  • ルールの目的を明確に示す説明的なファイル名を使用
  • clinerules-bank/を追跡しながらアクティブな.clinerules/フォルダをgit-ignoreすることを検討
  • 一般的なルールの組み合わせを迅速にアクティベートするためのチームスクリプトを作成

フォルダシステムは、Clineルールを静的なドキュメントから、チームの変化するコンテキストと要件に適応するダイナミックな知識システムに変換します。

トグル可能ポップオーバーによるルール管理​

単一の.clinerulesファイルとフォルダシステムの両方の管理をより簡単にするため、Caret v3.13ではチャットインターフェースから直接アクセスできる専用のポップオーバーUIを導入しています。

チャット入力フィールドの下に便利に配置されたこのポップオーバーでは以下が可能です：

  • アクティブなルールの即座の確認: 現在アクティブなグローバルルール（ユーザー設定から）とワークスペースルール（.clinerulesファイルまたはフォルダの内容）を表示
  • ルールの迅速な切り替え: ワークスペース.clinerules/フォルダ内の特定のルールファイルをワンクリックで有効化または無効化。これは、必要な時のみコンテキスト固有のルール（react-rules.mdやmemory-bank.mdなど）をアクティベートするのに最適です。
  • ルールの簡単な追加/管理: ワークスペース.clinerulesファイルやフォルダが存在しない場合の迅速な作成、または既存のフォルダへの新しいルールファイルの追加

このUIは、会話中にファイルや設定を手動で編集することなく、コンテキストの切り替えと異なる指示セットの管理を大幅に簡素化します。

Caret Logo