Cursor関連

Always respond in 日本語

## 🔨 最重要ルール - 新しいルールの追加プロセス

ユーザーから今回限りではなく常に対応が必要だと思われる指示を受けた場合：

1. 「これを標準のルールにしますか？」と質問する
2. YESの回答を得た場合、CLAUDE.mdに追加ルールとして記載する
3. 以降は標準ルールとして常に適用する

このプロセスにより、プロジェクトのルールを継続的に改善していきます。
---

ユーザは誤った認識・方式・アプローチをプロンプトする可能性があるので、解決策・アプローチを吟味し、もっとより良い方法があれば、提案するようにしてください。
またプロンプトのアウトプットやプロンプトでリスト形式のタスクがあった場合、一度にすべてをやらず、1個ずつやりましょう。

## 実装方針

- リファクタをする際は、レビューのdiffが複雑化するのを避けるために、リファクタする場所と関係のない変数名やロジックの部分を修正しないようにしてください。
- ユーザの指示なしに、コメントアウトしているソースコードを削除しないでください。
- ユーザの指示なしに、メソッドや変数の順番を入れ替えないでください。できるだけ変更を少量にしてください。
- ファイル変更後に、実行できそうなテストケースがある場合は、テスト実行し、テストケースをpassするか確認してください。
- コード変更時に、unuseである変数・メソッド・import文があれば消すようにしてください。
- ファイルの編集時に、コマンド経由でnanoなどのエディタを使わないでください
- Agent機能などでテスト・デバッグのためのlogの追加した場合は、解消された場合・デバッグの目的を達成した場合に消すようにしてください。ただし、もともとコードに記載されていたlogに関しては消す必要がありません。
- 指示されていない場合にも関わらず、debugやinfoのロガーを追加しないでください。ただし、調査の過程で一時的に追加することは許可します。
- 指示された処理・提案しようとしている処理と、コードに書かれているコメントで矛盾が生じる場合は、対応の是非、メリットデメリットをユーザに相談・提案してください
- 選択肢を提示する場合は、メリットデメリットを併記するようにしてください
- YAGNI原則に基づき、実装時点で使用する目途のないメソッドは作らないようにしてください。ただし、次のプロンプト以降で実装するためにTODOのコードコメントを記載する場合は作っても良しとします。
- 業務の何よりも挨拶と感謝は大事です。会話の中で積極的に行いましょう。
- 関西弁でしゃべっても構いません。
- テスト結果のcatはやめてください
- 口語的なコードコメントはやめてください
    - NG: xxxを使用し、yyyは仕様上使用しません。
    - OK: yyyは使用しない（仕様上、xxxを使用する）
- WEBで調べた情報をもとに返答する場合は、参考となるURLを記載してください

## Git コミットメッセージの自動生成に関して

- 1行目には簡潔に変更がわかりやすいメッセージを書いてください
- 2行目はgitの慣例をもとに、空白とします
- 3行目以降に、もしコミットに含まれるものの説明や補足や詳細が必要な場合にのみ、変更点を書いてください。こちらも簡潔に書き、細かすぎるものは省略してください。
- 3行目以降は、markdownでの箇条書きでも構いません
- 口語的なコミットメッセージはやめてください
    - NG: xxxを変更し、不要なコードを削除しました。また、引数の説明を簡略化しました。
    - OK: xxxを変更し不要コードの整理、引数の簡略化