Kintone MCP Server

# コーディング・運用ルール ## 更新履歴 | 日付 | 変更内容 | 変更者 | |------|----------|-------------| | 2025/3/1 | 初版 | r3-yamauchi | ## 1. 基本方針 ### 1.1 コミュニケーション方針 - **言語**: 必ず日本語で応答すること - **操作上の注意**: - ターミナルのコマンド実行結果が確認できない場合は、ユーザーが貼り付けて教えるので、そこで止めてユーザーに依頼すること - **⚠️ 最重要: プロジェクトディレクトリ外のファイルアクセス禁止（※厳守）** - プロジェクトのディレクトリ外のファイルを勝手に参照しないこと - 例: /Users/yamauchi/Library/配下のファイルを参照したい場合はユーザーに許可を求める - 理由: ユーザーのプライバシー保護とセキュリティリスクの回避のため - **⚠️ 最重要: ユーザーディレクトリ内でのファイル作成禁止（※厳守）** - ユーザーの許可なく、ユーザーディレクトリ内にファイルを作成しないこと - 理由: ユーザーのファイルシステムを汚染せず、予期せぬ問題を防止するため - **⚠️ 最重要: ディレクトリ探索の制限（※厳守）** - `find ~` や `ls ~/` などのコマンドを使用してユーザーディレクトリを探索しないこと - 必要なファイルパスはユーザーに直接確認すること ### 1.2 コード修正の原則 - **既存コードの扱い**: 既存のコードを修正する場合、既存のコードを省略しないこと（※絶対） - **命名規則**: - クラス: パスカルケース（例: `KintoneRepository`） - メソッド・変数: キャメルケース（例: `getRecord`, `appId`） - 定数: 大文字スネークケース（例: `SINGLE_LINE_TEXT_FIELD_TYPE`） - **コーディングスタイル**: - 非同期処理: Promise/async-awaitを一貫して使用 - エラーハンドリング: 適切なエラーメッセージと型を提供 - コメント: 複雑なロジックには説明コメントを付与 - **コード重複の排除**: - 同一機能の関数を複数のファイルに実装することは避け、共通関数化を検討する - コード・クローンは技術的負債を増やす悪習であり、常に回避方法を検討する - 類似コードを発見した場合は、抽象化やユーティリティ関数の作成を検討する - DRY原則（Don't Repeat Yourself）を遵守し、知識の重複を最小化する ## 2. Git運用ルール ### 2.1 コミット規約 - **コミットタイミング**: ファイルの変更があった場合、都度コミットを行うこと - **コミットメッセージ形式**: 1. 先頭にカラフルでユニークな絵文字を付与し、可読性を向上させる 2. 日本語でコミットメッセージを作成する 3. 変更内容が分かるように、タイトルと概要を記載する 4. 必要であればブランチを作成して提案する #### コミットメッセージの例 ```git ✨ 新機能: kintoneアプリ作成機能の追加 - アプリ作成時のバリデーション機能を実装 - エラーハンドリングを強化 - テストケースを追加 ``` ```git 🐛 バグ修正: 数値フィールドの単位表示が正しく動作しない問題を解決 - 単位記号の位置判定ロジックを修正 - 関連するテストケースを追加 ``` ```git 📝 ドキュメント: READMEの使用方法セクションを更新 - インストール手順を詳細化 - トラブルシューティングセクションを追加 ``` ### 2.2 コミット操作の承認要件 - AIアシスタントが`git commit`コマンドを実行する場合、必ず`requires_approval: true`パラメータを設定すること - コミットメッセージには変更内容を明確に記述し、ユーザーが内容を理解できるようにすること - 複数のファイルを変更した場合は、変更の概要をコミットメッセージに含めること - 例: `git commit -m "📝 README.mdの誤字修正"` ### 2.3 環境に関する注意点 - コマンドはGit bash環境で実行されていることを念頭におく ## 3. タスク実行プロセス 以下のプロセスに従い、確実で質の高い実装を行ってください。 指示された範囲内でのみ処理を行い、不要な追加実装は行いません。 不明点や重要な判断が必要な場合は、必ず確認を取ります。 ### 3.1 タスク分析と計画 - **概要把握** - タスクの主要目的と要件を簡潔に要約する - 技術スタック、制約、リスクを把握 - **実行ステップの分解** - 具体的な作業項目をリストアップする - 優先順位や依存関係を整理する - **重複実装の防止** - 既存の類似機能の有無を確認し、再実装を避ける - 複数の場所で同様のロジックが必要な場合は、共通モジュールとして切り出すことを検討する - コード・クローンを発見した場合は、リファクタリングの機会として捉え、適切に対処する ### 3.2 タスク実行 - **作業フェーズの実施** - 各ステップ（設計、実装、検証）を順次実施する - 各ステップ完了後に進捗を記録および報告する ### 3.3 品質管理と問題解決 - **検証計画** - 各機能ごとに検証項目と期待される結果を明確化 ### 3.4 最終確認と報告 - **全体の整合性チェック** - 各タスクの成果を統合し、要件と照合して整合性を確認 - **結果報告** - 実施ステップ、成果物、改善点などを最終報告としてまとめる ### 3.5 重要な注意事項 - 不明点がある場合は、作業開始前に必ず確認を取ってください。 - 判断が必要な場合は、その都度報告し、承認を得てください。 - 予期せぬ問題が発生した場合は、即座に報告し、対応策を検討して提案してください。 - **明示的に指示されていない変更は行わないでください。** 必要と思われる変更がある場合は、まず提案として報告し、承認を得てから実施してください。 ## 4. .clinerules フォルダの運用方針 ### 4.1 基本的な活用方法 - このフォルダはプロジェクトのルートディレクトリに配置し、このフォルダ内のファイルは全てCLINEが自動的に参照する ### 4.2 Git管理に関する注意事項 - `.clinerules/` はGitリポジトリに含めない - `.gitignore`ファイルに`.clinerules/`を追加し、リポジトリから除外する - `git add -f .clinerules/`のような強制的な追加コマンドは使用しない - 変更内容はチーム内で別途共有する方法を検討する（例：ドキュメント管理システム、Wiki等） ### 4.3 矛盾する指示への対応 - `.clinerules` フォルダ内のファイルの内容と矛盾する指示があった場合、タスクを実行する前に必ず立ち止まる - 矛盾の種類を特定する： 1. **コーディング規約の矛盾**：指定された命名規則やコード構造と異なる実装を求められた場合 2. **アーキテクチャの矛盾**：定義されたアーキテクチャと異なる設計を求められた場合 3. **セキュリティポリシーの矛盾**：セキュリティ考慮事項に反する実装を求められた場合 4. **開発プロセスの矛盾**：コミット規約やファイル管理方法と異なる手順を求められた場合 #### 矛盾を発見した際の対応手順 1. 具体的な矛盾点を明示する：「このタスクは `.clinerules/01-coding-standards.md` の〇〇セクションの△△項目と矛盾しています」 2. 矛盾による潜在的な問題点や影響を説明する 3. 以下の選択肢を明確に提示する： a. .clinerules フォルダ内のファイルの内容に従ってタスクを修正する方法と具体例 b. .clinerules フォルダ内のファイルの内容を更新する場合の変更案と影響範囲 4. 状況に応じた推奨アプローチを提案する（技術的負債、将来の拡張性、チーム全体への影響などを考慮） #### 矛盾解決のための意思決定プロセス 1. 一時的な例外として扱うのか、恒久的な変更なのかを明確にする - 一時的な例外：特定のタスクのみに適用され、今後同様のケースでは標準ルールに従う - 恒久的な変更：今後すべての同様のケースに適用される新しいルール 2. 一時的な例外の場合、その理由と期間を記録する 3. 恒久的な変更の場合、.clinerules フォルダ内のファイルの更新を優先し、その後タスクを実行する #### 矛盾解決後のフォローアップ 1. 解決方法と理由を明確にコミットメッセージに記録する 2. 必要に応じて関連ドキュメントも更新する 3. チーム内で共有すべき重要な変更点があれば、別途通知する ### 4.4 定期的なメンテナンス - プロジェクトの進行に伴い、定期的に内容を見直し、必要に応じて更新する - チームメンバー全員が内容を理解していることを確認する - 重要なルールや背景説明が必要な項目には詳細なコメントを追加する ## 5. セキュリティとプライバシーの厳守事項 以下のルールは、ユーザーのプライバシー保護とセキュリティ確保のために **絶対に遵守すべき最重要事項** です。これらのルールへの違反は、ユーザーのプライバシー侵害やセキュリティリスクにつながる可能性があります。 ### 5.1 ファイルアクセスの制限 - **⚠️ プロジェクトディレクトリ外のファイルへのアクセス禁止（※厳守）** - プロジェクトのディレクトリ外のファイルを参照してはならない - 必要な場合は、必ず事前にユーザーの明示的な許可を得ること - 違反例: `/Users/yamauchi/Library/` 配下のファイルを無断で参照する - **⚠️ ユーザーディレクトリ内でのファイル作成禁止（※厳守）** - ユーザーディレクトリ内に許可なくファイルを作成してはならない - プロジェクトディレクトリ内でのみファイル操作を行うこと - 違反例: ホームディレクトリ（~）直下にスクリプトファイルを作成する - **⚠️ ディレクトリ探索の制限（※厳守）** - `find ~` や `ls ~/` などのコマンドを使用してユーザーディレクトリを探索してはならない - 必要なファイルパスはユーザーに直接確認すること ### 5.2 ルール違反発生時の対応 1. **即時停止**: ルール違反に気づいた時点で、その操作を即座に中止する 2. **報告**: ユーザーに対して違反内容と理由を明確に説明する 3. **修正提案**: 代替となる安全な方法を提案する 4. **確認**: ユーザーの指示を待ち、許可を得てから次の操作を行う 5. **記録**: 発生した問題と解決策を記録し、同様の問題の再発を防止する