yuna

 背景と目的AIが日々進化し、AIを用いた開発が標準になりつつあります。

しかし、日々いろいろなモデルやAI開発ツールが出てくる中で、都度調査したりやツールに合わせて開発スタイル、技術スタックを変えていくのはコストがかかり、本来の目的である生産性を下げてしまう原因にもなります。
AIを使ってコードを書く上で、今後最も大事なるのは、

AIという確度の低い生成物を出力するツールを、コントロールすることにより可能な限り確度を高くすること、

かつ、ツールやモデルによる差分を吸収するような仕組みを構築することで、

AIの恩恵を受けつつ、日々の目まぐるしい変化に対してローコストで対応できるようになる事だと考えました。
そうすることで、今後AIが人類を超えるまでの移行期を、落ち着きながらしっかりAIの恩恵を受けて開発に活かしていけるのではないか？と思っています。

 やりたいことルールを細かく書かずとも、ある程度ざっくりしたメタファイルを書き、

それを各ツール用に整形・最適化するプログラムを準備することで、AIが確度高く、保守性の高いコードを生成するように制御すること。

アーキテクトとして、詳しければ詳しいほど、最初のメタファイルの段階で細かい指定ができるようになる。

普段、理解はしていても漏れなくルールとして書き出すのは結構面倒だったり、忘れがちなので、

それをサポートするような機能もツールに盛り込みたい。

yuna

 o1 proに解析させた物を一時保管
 ルールカテゴリの階層構造AIエディタで設定されるルールを、共通パターンに基づいて階層化しました。以下に、大カテゴリーから小カテゴリーへのツリー構造で示します（太字は大カテゴリー、_斜体_は中カテゴリー、小カテゴリーは具体的なルールグループの例です）。
プロジェクトのコンテキスト・専門知識（AIに与える文脈やドメイン知識）​
silasreinagel.com

技術スタックとドメイン：使用技術（言語、フレームワーク、ライブラリ）、プロジェクト特有の専門用語、業務ドメインの知識

目的・要件の共有：プロジェクトの目的や機能要件の概要、重要な設計上の制約

(例：「あなたはTypeScript/React/Tailwindの専門家です。プロジェクトXの背景知識としてYについて理解しています」など)
コーディング標準とベストプラクティス（コードの書き方に関する包括的な規範）​
docs.cline.bot
命名規則：変数・関数・クラスの命名規則、ファイルやディレクトリの命名規約
コードスタイル・構文：コーディング規約（インデントや括弧のスタイル）、言語特有のベストプラクティス（例: TypeScriptではinterfaceを優先する等）​
silasreinagel.com
設計・コーディングパターン：デザインパターンの推奨/禁止、関数型スタイル推奨、DRY原則の徹底​
silasreinagel.com
コメント・ドキュメンテーション：関数やクラスにJSDoc/PHPDocを書く、READMEやコード内コメントのガイドライン

(例：コードは簡潔でモジュール化し、クラスは避け関数型で記述する。公開関数には必ずDocコメントを付与する...)
プロジェクト構造とアーキテクチャ（プロジェクト全体の構成に関するルール）​
docs.cline.bot

ディレクトリ/ファイル構成：フォルダ階層の約束事、ファイル命名（index.js, module_name.tsなどのパターン）

モジュール分割と責務：レイヤー別の責務分担（例: MVCアーキテクチャに沿う）、コードの配置場所（UIコンポーネントはcomponentsフォルダへ等）

再利用性と構成管理：共通モジュールの分離、パッケージ構成やMono-repo構造のガイドライン

(例：「UIコンポーネントはすべてcomponents配下に配置」「サービス層とUI層を分離する」など)
品質保証とテスト（コード品質を保つためのルール）​
docs.cline.bot
テスト方針：ユニットテストの自動生成規則、テストカバレッジ目標、TDDの推奨
エラーハンドリング/検証：エラー時の挙動（例外処理のガイドライン）、ユーザ入力のバリデーション標準
パフォーマンス最適化：効率的なアルゴリズムの利用、不要な計算の削減、メモリ/CPU負荷に関するベストプラクティス​
silasreinagel.com
セキュリティ・その他品質：脆弱性対策コーディング、リンターやフォーマッタの遵守、コードレビュー基準

(例：「新規関数には必ず単体テストを作成」「O(n^2)以上の処理は避ける」「入力チェックを徹底し、脆弱性を防ぐ」など)
AIアシスタントの動作・プロセス（AIがどのように思考・行動するかに関するルール）​
github.com
プランニングとステップ実行：取り組む課題に対し、まず計画を立案、手順を箇条書きした後に実装に移る（例：Plan & Actモードの利用）​
github.com
自己改善と学習：誤り発生時の自己訂正、ユーザフィードバックから「教訓」を学習しルールに追加（Devinの自己進化機能など​
github.com
）
マルチエージェント/役割分担：AIエージェントをプランナーと実行役に分離、プランナーAIが計画立案、実行AIがコード生成​
github.com
ツール統合：外部ツールやリソースの活用判断、CLIコマンド・ウェブ検索・ブラウザ操作の自動利用​
github.com
メモリとコンテキスト管理：作業メモ（Scratchpad）への重要情報記録、長文コンテキストの要約保持

(例：AIは提案前に必ず計画を提示し、ユーザ修正指摘があれば「Lessons Learned」に追記して次回に活かす。必要ならウェブ検索ツールを用いて情報収集する...)
上記のように分類することで、個々のルールを言語やフレームワークに縛られない抽象的なカテゴリに整理できます。例えば_Cline_のカスタム命令では、**「コード規約の強制」「ファイル構成の標準化」「テスト手順の指示」「反復作業の自動化」「コード品質・性能の向上」**といった目的でルールを設定できます​
docs.cline.bot
。またCursorコミュニティでも、技術スタック指定、使用ライブラリ定義、コーディングパターン・フォーマット、UIスタイル指針、パフォーマンス最適化など様々な観点でルールが活用されています​
silasreinagel.com
。こうしたカテゴリ分けにより、AIエディタへの指示内容を体系的に把握できます。

 視覚的なルール関係図上記の分類はツリー構造として視覚化できます。大カテゴリーから小カテゴリーへの関係性を図示することで、ルール間のカバレッジ領域や関連性が一目で分かります。例えば以下のようなツリーダイアグラムで表現可能です：
ルール設定全体
├─ プロジェクトのコンテキスト・専門知識
│   ├─ 技術スタック・ドメイン知識
│   └─ 目的・要件の共有
├─ コーディング標準とベストプラクティス
│   ├─ 命名規則
│   ├─ コードスタイル・構文
│   ├─ 設計・コーディングパターン
│   └─ コメント・ドキュメンテーション
├─ プロジェクト構造とアーキテクチャ
│   ├─ ディレクトリ/ファイル構成
│   └─ モジュール分割と責務
├─ 品質保証とテスト
│   ├─ テスト方針
│   ├─ エラーハンドリング
│   ├─ パフォーマンス最適化
│   └─ セキュリティ・コード品質
└─ AIアシスタントの動作・プロセス
    ├─ プランニングとステップ実行
    ├─ 自己改善と学習
    ├─ マルチエージェント/役割分担
    ├─ ツール統合
    └─ メモリとコンテキスト管理
（※上記は一例です。プロジェクトによっては「UIデザイン指針」「データモデリング規約」のようにドメイン固有の中小カテゴリが追加される場合もあります。）
このような図解により、どの領域にどんなルールがあるか、また各ルールがどのカテゴリーに属するかが直観的に理解できます。関係図をもとに、抜け漏れのない包括的なルール設定を検討できます。

 メタ設定ファイルの設計（YAML/JSON）上記で整理したルールカテゴリ体系を、メタプログラミング可能なデータ構造で表現します。言語非依存かつ拡張性を持たせるために、YAMLやJSON形式でルールを階層的に記述できる設定ファイルを設計します。ポイントは次の通りです。

階層構造の表現: 大カテゴリー→中カテゴリー→小カテゴリーのネストを、そのままネストしたデータ構造で表します。例えばYAMLではインデントで、JSONではオブジェクト内にオブジェクトを持つ形で階層化します。

ルール内容のリスト化: 最下位の小カテゴリーには具体的なルール文やガイドラインのリストを格納します。各ルールは文字列として保持し、必要に応じてプレースホルダや変数を含めることもできます。

拡張性と再利用: カテゴリーやルールは追加・削除が容易な構造にします。例えば共通するサブカテゴリをテンプレート化し、複数の大カテゴリーで参照できるようにする、もしくは別ファイルに共通ルールセットを置きインクルードできるようにする設計も考えられます。

メタデータの付加: 必要に応じ、各ルールにコメントや適用範囲（どの言語/フレームワークに適用か）などのメタ情報を持たせます。ただし基本は言語に依存しない記述とし、特定技術にのみ現れるルールは条件的に適用できるようにします。
以下は、上記階層をYAMLで表現した簡易な例です。
rules:
  project_context:
    description: "プロジェクト固有のコンテキストやドメイン知識"
    tech_stack:
      - "言語やフレームワーク: Python3, Django, Postgres"
      - "ドメイン知識: 金融システムの基本用語を理解している"
  coding_standards:
    description: "コードスタイルや命名規則などのコーディング標準"
    naming:
      - "変数名はキャメルケース、小文字から開始"
      - "クラス名はPascalCase（頭字語も大文字）"
    formatting:
      - "インデントはスペース4つ"
      - "80文字を超える行は改行して可読性を維持"
    patterns:
      - "デザインパターン: シングルトンは禁止"
      - "DRY原則: 重複するコードは関数化して再利用"
  structure:
    description: "プロジェクトのディレクトリ構造やモジュール構成"
    file_structure:
      - "controllers/, models/, views/のレイヤー構成に従う"
      - "ユーティリティ関数はutils/ディレクトリに集約"
  quality:
    description: "テストやパフォーマンス、セキュリティなど品質に関する規則"
    testing:
      - "新規機能には必ずユニットテストを追加"
      - "CIでテストが全てパスしない限りコードをマージしない"
    performance:
      - "ネストが深いループは可能な限り避ける"
      - "データベースクエリはN+1にならないよう注意"
    security:
      - "入力値は全てバリデーションチェックする"
      - "機密情報は環境変数から読み込む（直ベタ書き禁止）"
  ai_behavior:
    description: "AIアシスタントの振る舞いに関する指示"
    planning:
      - "返信の最初に、タスク達成のためのステップ一覧を提案"
    self_improvement:
      - "ユーザからの訂正指示を受けたら、原因を分析し今後の改善点を記録"
    tool_usage:
      - "必要に応じてWeb検索ツールを使い、最新の情報を取得"
      - "ターミナルコマンドが必要な場合は適切に提案"
上記のようなYAML構造により、ルール設定をプログラムで扱いやすい形で保持できます。例えば各カテゴリーにdescriptionを付け人間が読める説明を加えています。また、小カテゴリーごとに具体的なルールをリストアップしています。この形式なら、プロジェクトに合わせて値を差し替えたり、不要な部分を削除するだけで簡単にカスタマイズ可能です。JSON形式でも同様に、ネストしたオブジェクトと配列で表現できます。

 Cursor・Cline向けルールファイル生成プロセス最後に、上記メタ設定ファイルからCursorやCline用のルールファイルを自動生成するプロセスの設計です。狙いは、一つのメタ設定から各種エディタ向けの具体的なルール定義ファイルを出力できるようにすることです。以下の手順で進めることを想定します。

メタ設定ファイルの入力: YAML/JSON形式のメタルールファイルを用意します。これにはプロジェクト固有の内容（技術スタック名や命名規則の細部など）を反映済みとします。

テンプレートによる組み立て: スクリプトがメタファイルを読み込み、各カテゴリー・ルールを遍歴します。CursorやClineの期待する書式（基本的にはプレーンテキストまたはMarkdown）に沿って、ルール文を組み立てます。例えば、各大カテゴリーをセクション見出し（Markdownの#や##）にし、その下に中カテゴリーを箇条書き、具体的ルールをインデント付きで列挙する、といったテンプレートを適用します。

エディタ固有フォーマットの適用: Cursorの.cursorrulesもClineのカスタム指示も内容はテキストベースですが、もし微妙な差異があれば分岐処理します（例：ファイル名やヘッダーの有無など）。基本的には両者に同じ内容を出力し、Cursor用にはプロジェクトルートに.cursorrulesファイルとして保存し、Cline用には.clinerulesまたは設定UIに貼り付けるテキストとして出力します。

言語・フレームワーク切り替えへの対応: メタ設定が言語非依存でカテゴリ分けされているため、新しい言語やフレームワークでも、追加のルールを同じカテゴリ構造内に記述するだけで対応できます。生成スクリプトはカテゴリ構造に依存して動くため、特定の言語固有ロジックに頼らずに済みます。例えばPythonプロジェクトではtech_stackやpatternsにPython/Django用のルールを入れ、Javaプロジェクトではそれを差し替えるだけで、残りの構造（テスト方針やAI動作ルールなど）はそのまま再利用できます。

出力と検証: 生成されたルールファイルをCursorやCline上で読み込み、期待通りAIが動作するか検証します。必要に応じてメタファイル側を修正し再度生成することで、ルール調整を効率的に行えます。将来的にはこのプロセス自体をCIに組み込み、コードベースに変更があれば自動でルールを再生成・適用することも検討できます。
以上のプロセスにより、一度定義したメタルールをもとに複数のエディタや環境向けの設定ファイルを一貫して生成できます。これはDRY原則（ルールの重複定義を避け一元管理する）にも適合し、プロジェクトの成長や技術スタックの変更に対しても柔軟にルールを保守できる利点があります。さらに、この手法を発展させれば、将来的にGitHub Copilot用の設定や他のAIコーディング支援ツールへの展開も容易になるでしょう。

 おわりに本分析では、AIエディタ向けルール設定を抽象化し体系立てて分類しました。大カテゴリーから小カテゴリーへ分類することで、ルールの全体像を把握しやすくなり、プロジェクトに適したカスタマイズが可能になります。またメタ設定ファイルを設計することで、ルール定義を再利用可能なデータとして管理でき、複数環境への適用がシームレスになります。これらの検討を踏まえ、次の段階では実際にメタ設定ファイルを構築し、それを入力としてCursorやClineの.cursorrules/.clinerulesファイルを自動生成するツールの設計・実装へと進めていきます。

yuna

 claude-3.7 sonnet-thinkingによる分析メモ
 AIエディタ制御ルールのメタ分析レポート
 概要このレポートでは、AIエディタ（Cursor、Clineなど）の制御ルールをメタ的な視点から分析し、カテゴリー別に整理しています。AIエディタに対する指示は多岐にわたりますが、これらを体系的に整理することで、より効果的なルール設定が可能になります。

 大カテゴリー → 中カテゴリー → 小カテゴリー 構造
 1. モデル挙動制御AI自体の振る舞いや応答特性を制御するルール群です。

 1.1 応答スタイル設定AIの応答の仕方や表現スタイルを定義します。

簡潔性制御: 回答の詳細度や簡潔さの度合いを指定

専門性レベル: 専門家向けか初心者向けかなど、説明の専門性レベルを調整

パーソナリティ設定: カジュアルか公式かなど、AIの人格的特性を定義

出力形式指定: マークダウン形式や特定の構造化フォーマットでの回答を要求

 1.2 ツール使用ポリシーAIが利用できるツールやコマンドについての制約を設定します。

自動実行許可設定: 特定のコマンドやツールの自動実行を許可するかどうか

承認要求基準: どのような操作に対してユーザーの承認を求めるか

ツール優先順位: 複数のツールが使用可能な場合の選択基準

セキュリティ制約: 機密性の高い操作や危険な操作に関する制限

 1.3 メモリ・コンテキスト管理AIがセッション間やプロジェクト内でコンテキストや記憶をどう扱うかを定義します。

コンテキスト維持戦略: 長期的な会話やプロジェクトでのコンテキスト維持方法

プロジェクト記憶構造: プロジェクト情報を構造化して記憶する方法

スクラッチパッド使用法: 一時的なメモやタスク管理のためのスクラッチパッド機能の使用方法

学習ログ管理: エラーや改善点に関する学習内容の記録・適用方法

 2. コード生成ガイドライン生成されるコードの質や特性に関するルール群です。

 2.1 コーディング規約コードの書き方やスタイルに関する具体的な規則を定義します。

命名規則: 変数、関数、クラスなどの命名方法

フォーマットルール: インデント、空白、改行などのフォーマットに関するルール

コメント方針: コメントの書き方、量、場所に関するガイドライン

言語固有規約: 特定のプログラミング言語に特化した規約

 2.2 アーキテクチャガイドラインコードの設計思想や構造に関する高レベルな指針を提供します。

設計パターン指定: 採用すべき設計パターンや避けるべきアンチパターン

モジュール化原則: コードのモジュール化に関する原則や方針

依存関係管理: ライブラリやモジュール間の依存関係の管理方法

スケーラビリティ考慮点: コードの拡張性やスケーラビリティを確保するための考慮点

 2.3 エラー処理方針エラーや例外の扱い方に関するガイドラインを設定します。

例外処理戦略: 例外の捕捉、処理、伝播に関する戦略

エラーメッセージ設計: ユーザーへのエラーメッセージの設計方針

リカバリーメカニズム: エラー発生時の回復メカニズムの実装方針

障害検知アプローチ: バグや障害を早期に検知するためのアプローチ

 3. プロジェクト構造定義プロジェクトの構造や構成に関するルール群です。

 3.1 ディレクトリ構造定義プロジェクトのフォルダ構造やファイル配置に関する規則を定義します。

フォルダ階層設計: プロジェクトのフォルダ階層の設計方針

機能別分類原則: 機能や役割によるファイルの分類・配置原則

特殊ディレクトリ規則: 特定の目的を持つディレクトリ（tests, docs等）の規則

パッケージ構成方針: パッケージやモジュールの構成方針

 3.2 ファイル命名規則ファイルの命名に関する具体的なルールを設定します。

ファイル名形式: ファイル名の形式（キャメルケース、スネークケースなど）

拡張子利用方針: 拡張子の使い方や意味づけ

命名禁止パターン: 避けるべきファイル名のパターン

特殊ファイル命名規則: 特定の役割を持つファイル（設定ファイル、テストファイル等）の命名規則

 3.3 技術スタック指定プロジェクトで使用する技術やツールに関する制約を定義します。

バージョン管理: ライブラリやフレームワークのバージョン管理方針

互換性要件: 異なる技術間の互換性確保のための要件

ツールチェーン定義: 開発・ビルド・テストに使用するツールチェーンの定義

技術選定理由: 特定の技術を選択した理由や背景の記録

 4. コミュニケーション設定AIとユーザー間のコミュニケーションに関するルール群です。

 4.1 インタラクションスタイルユーザーとAI間のやり取りの方法や特性を定義します。

質問フォーマット: AIが質問する際のフォーマットや方法

提案スタイル: 改善案や代替案を提示する際のスタイル

不確実性表現: 不確かな情報や推測を伝える際の表現方法

進捗報告方法: タスクの進捗や状況を報告する方法

 4.2 説明・ドキュメント形式AIが提供する説明やドキュメントの形式を規定します。

コード説明レベル: コードに対する説明の詳細度や抽象度

ドキュメント構造: 生成するドキュメントの構造や章立て

図表使用基準: 説明のための図表や視覚的要素の使用基準

用語統一方針: 専門用語や技術用語の使用に関する統一方針

 4.3 フィードバックループ設定ユーザーからのフィードバックに対する処理方法を設定します。

修正要求対応: ユーザーからの修正要求への対応方法

改善提案発見: ユーザーのニーズや課題を発見するための質問や観察

理解確認プロセス: AIがユーザーの要求を正しく理解しているか確認するプロセス

批評受容態度: ユーザーからの批評や指摘への対応姿勢

 5. ワークフロー制御開発プロセスやワークフローに関するルール群です。

 5.1 タスク分析プロセスタスクの分析や計画に関するプロセスを定義します。

要件解析方法: ユーザーの要件を分析・整理する方法

問題分解アプローチ: 複雑な問題を分解・単純化するアプローチ

前提条件確認: タスク実行前の前提条件や依存関係の確認方法

潜在的課題予測: 潜在的な問題や障害を予測する方法

 5.2 開発ステップ定義実際の開発作業の進め方や手順を規定します。

イテレーションサイクル: 開発のイテレーションサイクルの定義

段階的実装手順: 機能を段階的に実装するための手順

マイルストーン設定: 進捗管理のためのマイルストーン設定

タイムボックス戦略: 時間制約下での開発戦略

 5.3 品質管理プロセスコードやプロダクトの品質を確保するためのプロセスを定義します。

テスト駆動開発手順: テスト駆動開発を実践するための手順

コードレビュー基準: コードレビューの基準や焦点

バグ修正プロトコル: バグの分析・修正に関するプロトコル

リファクタリング判断: リファクタリングの必要性を判断する基準

 まとめAIエディタ制御ルールは、上記のようなカテゴリーに分類することで、より効果的かつ体系的に管理することができます。プロジェクトやチームの特性に合わせて、必要なカテゴリーのルールを適切に設定することで、AIエディタとの協業効率を大幅に向上させることが可能です。
これらのルールは固定的なものではなく、プロジェクトの進行や技術の進化に合わせて継続的に見直し、改善していくことが重要です。

yuna

claude-3.7 sonnet-thinkingによる分析メモ（メタルール→rule吐き出し)

AIエディタ制御ルールのメタフレームワーク設計

目的

このドキュメントでは、AIエディタ制御ルールをメタプログラミングの観点から設計し、単一のメタ設定ファイルから各種AIツール（Cursor、Cline等）に最適化されたルールファイルを生成するシステムについて説明します。

全体アーキテクチャ

メタルール定義ファイル（YAML形式）

メタルール定義ファイルは、ツールに依存しない抽象的なルールの集合を定義します。このファイルはYAML形式で、以下のような構造を持ちます。

meta_rules:
  version: "1.0"
  project_info:
    name: "プロジェクト名"
    description: "プロジェクトの説明"
    
  # モデル挙動制御関連の設定
  model_behavior:
    response_style:
      conciseness: "高" # 低/中/高
      expertise_level: "上級者" # 初級者/中級者/上級者
      personality: "カジュアル" # 公式/カジュアル/協力的
      output_format: "markdown" # plain/markdown/structured
      
    tool_usage:
      auto_execution: ["grep_search", "list_dir"] # 自動実行を許可するツール
      approval_required: ["run_terminal_cmd", "edit_file"] # 承認が必要なツール
      tool_preference: # ツールの優先順位
        search: ["codebase_search", "grep_search"]
        file_operations: ["read_file", "edit_file"]
      
    memory_management:
      context_retention: "セッション" # なし/セッション/プロジェクト
      scratchpad_enabled: true
      learning_log_enabled: true
      
  # コード生成ガイドライン
  code_generation:
    coding_conventions:
      naming:
        variables: "camelCase"
        functions: "camelCase"
        classes: "PascalCase"
        constants: "UPPER_SNAKE_CASE"
      formatting:
        indent_style: "space"
        indent_size: 2
        max_line_length: 80
      comments:
        required_sections: ["概要", "パラメータ", "戻り値", "例外"]
        
    architecture:
      design_patterns:
        preferred: ["Factory", "Repository", "Dependency Injection"]
        avoid: ["Singleton", "Global State"]
      modularization:
        principles: ["単一責任", "関心の分離", "インターフェース分離"]
        
    error_handling:
      strategy: "例外ベース" # 戻り値ベース/例外ベース/ハイブリッド
      logging_level: "詳細" # 最小限/標準/詳細
      recovery_mechanism: "自動リトライ" # なし/自動リトライ/手動復旧
      
  # プロジェクト構造
  project_structure:
    directory_structure:
      root_dirs:
        - name: "src"
          description: "ソースコード"
        - name: "tests"
          description: "テストコード"
        - name: "docs"
          description: "ドキュメント"
      
    file_naming:
      pattern: "kebab-case" # snake_case/kebab-case/camelCase
      extensions:
        typescript: [".ts", ".tsx"]
        documentation: [".md", ".mdx"]
        
    tech_stack:
      languages: ["TypeScript", "JavaScript"]
      frameworks: ["React", "Next.js"]
      libraries:
        ui: ["tailwindcss", "shadcn/ui"]
        state: ["zustand"]
        testing: ["jest", "react-testing-library"]
      versions:
        node: "20.x"
        typescript: "5.x"
        react: "19.x"
        
  # コミュニケーション
  communication:
    interaction_style:
      question_format: "開放型" # はい/いいえ型/選択型/開放型
      suggestion_approach: "提案のリスト" # 単一提案/提案のリスト/段階的アプローチ
      uncertainty_expression: "確率表示" # あいまい表現/確率表示/確信度レベル
      
    documentation:
      code_explanation_level: "中" # 低/中/高
      document_structure: ["見出し", "概要", "詳細", "例", "参考資料"]
      
    feedback:
      correction_handling: "即時対応" # 確認/即時対応/選択肢提示
      understanding_verification: true
      
  # ワークフロー
  workflow:
    task_analysis:
      requirement_breakdown: ["目的", "入力", "出力", "制約", "例外"]
      complexity_assessment: true
      
    development_steps:
      methodology: "TDD" # TDD/BDD/フィーチャー駆動
      iteration_cycle: ["計画", "設計", "実装", "テスト", "レビュー"]
      
    quality_control:
      test_coverage_target: 80
      code_review_focus: ["セキュリティ", "パフォーマンス", "可読性"]
      refactoring_triggers: ["複雑度", "重複", "パフォーマンス"]

ルール変換エンジン

ルール変換エンジンは、メタルール定義ファイルを読み込み、各AIツール向けのルールファイルを生成します。エンジンは以下の機能を持ちます。

メタルール定義ファイルの解析
ツール固有のテンプレートの読み込み
メタルールとテンプレートの組み合わせによるルールファイルの生成
生成されたルールファイルの検証

実装言語

ルール変換エンジンはTypeScriptで実装し、Node.jsで実行します。選定理由は以下の通りです。

型安全性により設定ファイルの検証が容易
豊富なライブラリエコシステム（YAML/JSON操作、テンプレートエンジン等）
クロスプラットフォームで動作

主要コンポーネント

1. メタルールパーサー

interface MetaRules {
  version: string;
  project_info: {
    name: string;
    description: string;
  };
  model_behavior: { /* ... */ };
  code_generation: { /* ... */ };
  project_structure: { /* ... */ };
  communication: { /* ... */ };
  workflow: { /* ... */ };
}

class MetaRuleParser {
  parse(yamlContent: string): MetaRules {
    // YAMLをパースしてメタルールオブジェクトを返す
  }
  
  validate(rules: MetaRules): ValidationResult {
    // メタルールの整合性を検証
  }
}

2. テンプレートエンジン

interface TemplateEngine {
  loadTemplate(toolName: string): Template;
  render(template: Template, metaRules: MetaRules, toolConfig: ToolConfig): string;
}

class HandlebarTemplateEngine implements TemplateEngine {
  // Handlebarsを使用したテンプレート処理の実装
}

3. ツール固有設定マネージャー

interface ToolConfig {
  name: string;
  version: string;
  file_extension: string;
  template_path: string;
  rule_structure: {
    // ツール固有のルール構造定義
  };
  transformers: {
    // メタルールをツール固有形式に変換する関数
  };
}

class ToolConfigManager {
  loadConfig(toolName: string): ToolConfig {
    // ツール固有の設定を読み込む
  }
}

4. ルール生成器

class RuleGenerator {
  constructor(
    private parser: MetaRuleParser,
    private templateEngine: TemplateEngine,
    private configManager: ToolConfigManager
  ) {}
  
  generateRule(metaRulePath: string, toolName: string, outputPath: string): void {
    // メタルールからツール固有のルールを生成
  }
}

ツールテンプレート

各AIツール向けのテンプレートは、ツールの特性やフォーマットに合わせた形式で作成します。テンプレートはHandlebarsなどのテンプレートエンジンの記法を用います。

Cursor用テンプレート例

# {{project_info.name}} - AI制御ルール

このファイルは{{project_info.name}}プロジェクト用のAI制御ルールを定義します。
{{project_info.description}}

## 応答スタイル

- 簡潔性: {{map model_behavior.response_style.conciseness}}
- 専門性: {{model_behavior.response_style.expertise_level}}
- スタイル: {{model_behavior.response_style.personality}}

## コーディング規約

### 命名規則
- 変数: {{code_generation.coding_conventions.naming.variables}}
- 関数: {{code_generation.coding_conventions.naming.functions}}
- クラス: {{code_generation.coding_conventions.naming.classes}}
- 定数: {{code_generation.coding_conventions.naming.constants}}

### フォーマット
- インデント: {{code_generation.coding_conventions.formatting.indent_size}}{{code_generation.coding_conventions.formatting.indent_style}}
- 最大行長: {{code_generation.coding_conventions.formatting.max_line_length}}文字

## プロジェクト構造

{{#each project_structure.directory_structure.root_dirs}}
- {{this.name}}/: {{this.description}}
{{/each}}

## 技術スタック

{{#each project_structure.tech_stack.languages}}
- {{this}}
{{/each}}

{{#each project_structure.tech_stack.frameworks}}
- {{this}}
{{/each}}

{{#with project_structure.tech_stack.versions}}
- Node.js: {{node}}
- TypeScript: {{typescript}}
- React: {{react}}
{{/with}}

## エラー処理

- 戦略: {{code_generation.error_handling.strategy}}
- ログレベル: {{code_generation.error_handling.logging_level}}
- 回復メカニズム: {{code_generation.error_handling.recovery_mechanism}}

Cline用テンプレート例

## 重要

あなたは専門的なソフトウェアエンジニアとして{{project_info.name}}プロジェクトをサポートします。
{{project_info.description}}

## メモリバンク

コンテキスト保持: {{model_behavior.memory_management.context_retention}}
{{#if model_behavior.memory_management.scratchpad_enabled}}
以下のスクラッチパッドを活用してタスクの進行状況を管理してください。
{{/if}}

## 技術スタック

{{#with project_structure.tech_stack}}
言語: {{join languages ", "}}
フレームワーク: {{join frameworks ", "}}
{{/with}}

{{#with project_structure.tech_stack.versions}}
- Node.js v{{node}}
- {{#if typescript}}TypeScript v{{typescript}}{{/if}}
- {{#if react}}React v{{react}}{{/if}}
{{/with}}

## コーディング規約

{{#with code_generation.coding_conventions}}
### 命名規則
- 変数: {{naming.variables}}
- 関数: {{naming.functions}}
- クラス: {{naming.classes}}

### フォーマット
- インデント: {{formatting.indent_size}}{{formatting.indent_style}}
- 最大行長: {{formatting.max_line_length}}文字
{{/with}}

## プロジェクト構造

{{#each project_structure.directory_structure.root_dirs}}
- {{this.name}}/: {{this.description}}
{{/each}}

## 開発フロー

{{#with workflow.development_steps}}
方法論: {{methodology}}
サイクル: {{join iteration_cycle " → "}}
{{/with}}

## 品質管理

{{#with workflow.quality_control}}
テストカバレッジ目標: {{test_coverage_target}}%
コードレビュー重点: {{join code_review_focus ", "}}
{{/with}}

コマンドラインインターフェース

ルール変換エンジンは、コマンドラインから操作できるインターフェースを提供します。

Usage: rulegen [options]

Options:
  -V, --version                    バージョン情報を表示
  -i, --input <path>               メタルール定義ファイルのパス (必須)
  -o, --output <directory>         出力ディレクトリ (デフォルト: "./rules")
  -t, --tool <tool>                生成するツール (cursor, cline, all) (デフォルト: "all")
  -c, --config <path>              ツール設定ファイルのパス (オプション)
  -v, --validate                   生成前にメタルールを検証する
  -s, --sample                     サンプルメタルールファイルを生成
  -h, --help                       ヘルプ情報を表示

実装プロセス

基本フレームワークの構築
- メタルールスキーマの定義
- パーサーの実装
- 基本的なコマンドラインインターフェースの実装
テンプレートシステムの実装
- テンプレートエンジンの選定と実装
- ヘルパー関数の定義（マッピング、変換、フォーマット等）
ツール固有設定の実装
- 各ツールの特性・要件の調査
- ツール固有の変換ロジックの実装
生成と検証機能の実装
- ルール生成ロジックの実装
- 生成されたルールの検証機能
テストとドキュメント
- 単体テスト、統合テストの実装
- ユーザードキュメントの作成
- サンプルメタルールと生成ルールの作成

利用例

基本的な使用方法

# サンプルメタルールを生成
npx rulegen --sample > metarules.yaml

# 編集後、ルールを生成
npx rulegen --input metarules.yaml --output ./rules

# 特定のツール向けのみ生成
npx rulegen --input metarules.yaml --tool cursor --output ./rules

プログラムからの利用

import { RuleGenerator } from 'rulegen';

const generator = new RuleGenerator();
generator.generateRule('metarules.yaml', 'cursor', './rules/cursor');

まとめ

メタルール定義からの各種ツール向けルールファイル生成システムは、AIエディタとの協業効率を大幅に向上させる可能性を持っています。このシステムにより、以下のメリットが期待できます。

一貫したルール管理: 複数ツールでも単一のメタ定義から一貫したルールを適用
メンテナンス性の向上: ルール更新が一箇所で完結
ツール間移行の容易さ: 新しいAIツールへの対応も容易
チーム間の標準化: 組織全体での標準的なルールの適用が容易

今後の発展としては、ルールの効果分析機能や、AIツールからのフィードバックを元にしたルールの自動最適化機能なども考えられます。

yuna

関連しそうなプロダクトや記事

yuna

cursorが作業を進めるにあたって、todoなどの思考をすべてメモリに保存するのではなく、
一部の進捗などをディレクトリに保存しながら進めるメモ

yuna

 AIエディタ制御ルール分類まとめ(再度整理)このドキュメントは、rule_repositories_submodules から収集したAIエディタ制御ルールを ai_editor_rules のカテゴリー構造に基づいて整理・分類したものです。

 目次
01.モデル挙動制御
01.基本動作原則

01.応答スタイル設定
01.簡潔性制御
02.専門性レベル
03.パーソナリティ設定
04.出力形式指定

02.ツール使用ポリシー
01.自動実行許可設定
04.セキュリティ制約

03.メモリ・コンテキスト管理
01.コンテキスト維持戦略

02.コード生成ガイドライン
01.コーディング規約
02.アーキテクチャガイドライン

 01.モデル挙動制御AIエディタ自体の振る舞いや応答特性を制御するルール群です。

 01.基本動作原則AIエディタの基本的な動作原則を定義するルールです。

 基本的なコーディングタスク実行原則
AIアシスタントがコーディングタスクを効率的かつ正確に遂行するための基本原則です。

主なプロセス: 指示の分析と計画、重複実装の防止、タスクの実行、品質管理と問題対応、結果報告

目的: 構造化されたコーディングタスクの実行、体系的なプロジェクト実装と品質管理、一貫性のある成果物の提供

 01.応答スタイル設定AIエディタの応答の仕方や表現スタイルを定義するルールです。

 01.簡潔性制御AIエディタの回答の詳細度や簡潔さの度合いを制御するルールです。
簡潔モードAIエディタの回答を簡潔にする設定です。不要な説明や余分な情報を省き、本質的な内容のみを提供します。

目的: 時間効率の向上、必要情報への集中、作業効率の向上

 02.専門性レベルAIエディタの回答の専門性レベルを調整するルールです。
エキスパートモードAIエディタの回答を専門家向けにする設定です。高度な専門用語を使用し、詳細な技術情報を提供します。

目的: 効率性向上、深い専門知識、技術的正確性

対象者: 経験豊富な開発者、特定分野の専門家、高度な技術的議論を求めるユーザー
初心者モードAIエディタの回答を初心者向けにする設定です。専門用語を避け、基本的な概念から説明します。

目的: 学習支援、概念の理解、自己学習の促進

対象者: プログラミング初学者、特定の言語やフレームワークの初心者

 03.パーソナリティ設定AIエディタの人格的特性やコミュニケーションスタイルを定義するルールです。
フレンドリーモードAIエディタの回答をカジュアルでフレンドリーな口調にする設定です。堅苦しい表現を避けます。

目的: ストレス軽減、コミュニケーション促進、学習体験の向上

対象者: リラックスした雰囲気で作業したいユーザー、初心者
ずんだもんモードAIエディタの応答を「ずんだもん」キャラクターの口調とパーソナリティに合わせて提供します。

目的: 親しみやすさ向上、理解促進、学習体験の楽しさ

対象者: リラックスした雰囲気で開発を進めたいユーザー、技術的な会話に親しみを持ちたい初心者

 04.出力形式指定AIエディタの回答の出力形式を指定するルールです。
マークダウン形式AIエディタの回答をマークダウン形式で構造化して出力する設定です。見出し、リスト、コードブロック等を使用します。

目的: 可読性向上、情報整理、再利用性

対象者: ドキュメントを作成するユーザー、情報を整理して記録したいユーザー

 02.ツール使用ポリシーAIエディタが利用できるツールやコマンドについての制約を設定するルールです。

 01.自動実行許可設定特定のコマンドやツールの自動実行を許可するかどうかを定めるルールです。
Git操作ガイドラインAIエディタがGitとGitHubを操作する際に従うべきルールを定義します。安全かつ効率的なバージョン管理のための指針を提供します。

目的: 安全性の確保、透明性の向上、協業の促進

対象ユーザー: チーム開発を行う開発者、バージョン管理を重視するプロジェクト参加者
コードエージェント行動指針AIエディタがコード生成時に従うべき基本的な行動指針を定義します。

目的: 効率的な問題解決、適切なコミュニケーション、開発品質の向上

対象ユーザー: AIにコーディングを依頼する開発者、テスト駆動開発を重視するユーザー

 04.セキュリティ制約機密性の高い操作や危険な操作に関する制限を定めるルールです。
セキュリティ対策基準AIエディタのツール使用やコード生成における重要なセキュリティ制約を定義します。

目的: データ保護、安全な通信、プロジェクト保全

対象者: セキュリティを重視するプロジェクト開発者、機密データを扱うチーム
ターミナルコマンド制限AIエディタが実行できるターミナルコマンドに制限を設ける設定です。危険なコマンドを防止します。

目的: セキュリティ向上、透明性確保、ユーザー制御

対象者: AIエディタを使用したシステム管理者、コマンドライン操作を頻繁に行うユーザー

 03.メモリ・コンテキスト管理AIエディタがセッション間やプロジェクト内でコンテキストや記憶をどう扱うかを定義するルールです。

 01.コンテキスト維持戦略長期的な会話やプロジェクトでのコンテキスト維持方法を定義するルールです。
メモリバンク構造AIエディタのセッション間でのコンテキスト維持のためのメモリバンク構造を定義します。

目的: コンテキスト一貫性、情報構造化、継続的作業支援

対象者: 複雑なプロジェクトを管理するチーム、長期開発プロジェクトに取り組む開発者
ワークフローモードAIエディタのタスク実行プロセスを計画モードと実行モードに分けて定義します。

目的: プロセス標準化、計画的実行、ドキュメント継続性

対象者: 複数人で開発プロジェクトを進めるチーム、長期的なプロジェクト開発を行う開発者

 02.コード生成ガイドライン生成されるコードの質や特性に関するルール群です。

 01.コーディング規約コードの書き方やスタイルに関する具体的な規則を定義するルールです。

 コード品質ガイドライン
AIエディタが生成するコードの品質を確保するためのガイドラインです。クリーンコード原則に基づきます。

目的: 保守性向上、可読性向上、バグ削減

対象者: 高品質なコードを重視する開発者、チーム開発でコード品質標準を維持したいリーダー

 02.アーキテクチャガイドラインコードの設計思想や構造に関する高レベルな指針を提供するルールです。

 テスト駆動開発ガイドライン
AIエディタがテスト駆動開発（TDD）の原則に基づいてコードを生成・改善するためのガイドラインです。

目的: 品質向上、設計改善、回帰バグ防止

対象者: テスト駆動開発を実践する開発者、高品質で堅牢なコードを作成したいチーム

 今後の拡張可能性以下のカテゴリーについても、今後ルールを追加することで、AIエディタ制御の体系をさらに充実させることができます。

03.プロジェクト構造定義: プロジェクトの構造や構成に関するルール群

04.コミュニケーション設定: AIとユーザー間のコミュニケーションに関するルール群

05.ワークフロー制御: 開発プロセスやワークフローに関するルール群

背景と目的

やりたいこと

o1 proに解析させた物を一時保管

ルールカテゴリの階層構造

視覚的なルール関係図

メタ設定ファイルの設計（YAML/JSON）

Cursor・Cline向けルールファイル生成プロセス

おわりに

claude-3.7 sonnet-thinkingによる分析メモ

AIエディタ制御ルールのメタ分析レポート

概要

大カテゴリー → 中カテゴリー → 小カテゴリー 構造

1. モデル挙動制御

1.1 応答スタイル設定

1.2 ツール使用ポリシー

1.3 メモリ・コンテキスト管理

2. コード生成ガイドライン

2.1 コーディング規約

2.2 アーキテクチャガイドライン

2.3 エラー処理方針

3. プロジェクト構造定義

3.1 ディレクトリ構造定義

3.2 ファイル命名規則

3.3 技術スタック指定

4. コミュニケーション設定

4.1 インタラクションスタイル

4.2 説明・ドキュメント形式

4.3 フィードバックループ設定

5. ワークフロー制御

5.1 タスク分析プロセス

5.2 開発ステップ定義

5.3 品質管理プロセス

まとめ

claude-3.7 sonnet-thinkingによる分析メモ（メタルール→rule吐き出し)

AIエディタ制御ルールのメタフレームワーク設計

目的

全体アーキテクチャ

メタルール定義ファイル（YAML形式）

ルール変換エンジン

実装言語

主要コンポーネント

1. メタルールパーサー

2. テンプレートエンジン

3. ツール固有設定マネージャー

4. ルール生成器

ツールテンプレート

Cursor用テンプレート例

Cline用テンプレート例

コマンドラインインターフェース

実装プロセス

利用例

基本的な使用方法

プログラムからの利用

まとめ

AIエディタ制御ルール分類まとめ(再度整理)

目次

01.モデル挙動制御

01.基本動作原則

01.応答スタイル設定

01.簡潔性制御

02.専門性レベル

03.パーソナリティ設定

04.出力形式指定

02.ツール使用ポリシー

01.自動実行許可設定

04.セキュリティ制約

03.メモリ・コンテキスト管理

01.コンテキスト維持戦略

02.コード生成ガイドライン

01.コーディング規約

02.アーキテクチャガイドライン

今後の拡張可能性

大カテゴリー → 中カテゴリー → 小カテゴリー構造