わんのすけを滑らせて

わんのすけぇ

もっかい言えばやってくれるからまあいい

途中で割り込むと3〜5割くらいの確率で元のやるべき処理忘れちゃうけど

ドキュメントに書かせるほうが再利用できていい

planモード使うとどうしてもイテレーションが遅くなっちゃうんだよねえ

Clineのときはどんどんお金吸われた

copilotとClineとRoo codeとwindsurfとreplitとcodexとjulesとbolt newとかなんやかんや使って一番安くて品質がいいのがCursorだなあという感じ

うちのルールは全部ではないけどこんな感じ ``` 以下の原則を守ってください - 設計原則 - SOLID原則：柔軟・拡張性・保守性のある設計のための5つの基本原則（SRP, OCP, LSP, ISP, DIP）。 - KISS / YAGNI / DRY：シンプルに、不要なものは作らず、重複を避ける。 - Demeterの法則：他のモジュールの内部構造に依存しない。 - 最小権限の原則：必要最小限の機能に留める。 - モジュール設計と構造 - 関心の分離（SoC）：機能ごとに明確に分離。 - 高凝集・低結合：内部は密接、外部との依存は最小限に。 - レイヤードアーキテクチャ：UI/ビジネスロジック/データ層を分離。 - クリーンアーキテクチャ：ビジネスロジックを中心に据える。 - デザインパターンの活用 再利用性や拡張性を高めるための定番手法： - Factory：生成処理の分離。 - Strategy：動的な処理切替。 - Observer：状態変化の通知。 - Facade：複雑なAPIのシンプル化。 - コード構成とドキュメント - 意味単位で分割：機能・役割ごとにファイルを整理。500行を超える場合は長すぎるので分割を検討すること。 - 命名ルールの統一：一貫性を保って可読性を高く。 - リテラリープログラミング：コードと意図を同時に表現。 - ディレクトリの階層ごとにマークダウンに設計情報を記載すること。 - 機能を追加したり使用を変更したら必ずドキュメントに反映すること。 - **実行中のタスクの目的以外の既存のコードの修正を絶対にしないこと。** - テストと継続的改善 - ユニットテスト：最小単位の検証を自動化。 - インテグレーションテスト：複数コンポーネントの結合確認。 - CI/CDの導入：変更の品質を保ちつつ素早く反映。 - リファクタリング：技術的負債を定期的に解消。ただし、進行中のタスクのついでに行うようなことは絶対にせず、リファクタリングを行う場合はユーザーに内容を提案して可否を確認すること ユーザーからの指示を守り、以下の原則に従って作業を進めます 1. ソースコードを1ファイル修正したら必ずビルドしてエラーを確認し、複数のファイルを一気に修正しないこと 2. エラーを一つ一つ確実に修正する 不具合が発生している時は可能性で行き当たりばったりに実装せず、適切なログの追加などで問題を切り分けして確実に次に進めること。 原因が明確に判明していないエラーの対策は 0. どの範囲で不具合が起きているのか必要最低限のログを入れて、二分探索して発生箇所を絞り込む 1. 仮説を立てる 2. 仮説が正しいかどうかのエビデンスを得る 3. データを見て仮説が間違っていたら1に戻る。仮説が正しければ4に進む 4. 対策方法を検討する 5. 修正する が基本。これを必ず守ること。 フォールバック処理は問題を複雑にするのでユーザーからの明示的な指示がない限り絶対に入れないこと 仕様の変更点はソースコードではなくコミットログに書くこと。 ```

毎回指示待ちで止まっても困るから修正内容を宣言してからやって欲しい