-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path.clinerules
129 lines (115 loc) · 6.71 KB
/
.clinerules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
# Rules
- Don't read .env. you must not check environment like API Key. you can just read .env.sample for environment name, not value. Or ask user to set envrionment.
- Don't read config file. just ask to user.
- User Personalizeからユーザーの好みの傾向を加味して方針を立てなさい
- ユーザー指定のルールは原則守ること
## タスク完了前に必ず実施すること（優先度順）
1. 実施内容をdocs/reflection_notes_cline_tasks配下にMarkdown形式`<taskname_<timestamp>.md`でtaskの振り返りをフォーマットに従い出力しなさい
- 振り返りノートの作成は必須。これがないとタスクは未完了とみなされます
- 特に「自力で解決できなかった問題」は必ず記載してください
2. 今回のタスクのユーザーの質問を分析し、.clinerulesファイルのUser Personalizeに追記、統合しなさい
3. タスク実行中に受けた指摘は、同様の指摘を防ぐために必ず.clinerulesファイルのユーザー指定のルールに追記すること。特に以下の項目は重点的に記録する：
- コマンド実行の方法や注意点
- エラー処理の方法
- 環境依存の問題への対処方法
- セキュリティに関する考慮事項
---
# ユーザー指定のルール
- コマンド実行ツールがある場合は、必ず自分でコマンドを実行すること。ユーザーに実行を依頼しない。
- コマンドのエラーは適切に処理すること。特にTerraformのようなインフラ管理ツールでは、既存リソースの状態を正しく把握し、必要に応じてimportコマンドを使用する。
- ディレクトリ移動（cd）を行う場合は、エラーを防ぐため絶対パスを使用する。
- コマンドの出力が確認できない場合は、必ずユーザーに確認を行うこと。
- 外部ツール（jqなど）は、環境にインストールされているかどうかわからないため、シンプルなコマンドを使用すること。
- エラーハンドリングは、メインの処理フローに影響を与えないように分離すること。
- 外部ツールを使用する場合は、必ず環境依存性を考慮し、基本的なコマンドラインツールのみを使用する。
- スクリプトの実行パスは、必ずスクリプトのディレクトリを基準にすること。
- エラー発生時のログは構造化して出力し、デバッグ可能な情報を含めること。
- 実装計画などのドキュメントは、`<タスク名>_<タイムスタンプ>.md`の形式で保存し、既存ファイルとの混同を避けること。
---
# User Personalize
- 疎結合にこだわる
- プロトタイプ開発を重視：品質よりも迅速な実装を優先する
- シンプル志向：過度に複雑な設計を避け、必要最小限の実装を好む
- 段階的な実装：StepByStepでの実装と動作確認を重視
- MVPファースト：必要最小限の機能から始め、後から拡張できる設計を好む
- デバッグ重視：開発者ツールを活用した問題解決を好む
- UXフィードバック重視：操作結果の視覚的な確認を重要視する
- エラー情報の詳細化：デバッグログやエラーメッセージの充実を求める
- タスク優先順位の重視：本質的な機能の実装を最優先する
- 実装の方向性の明確化：タスクの目的に沿った実装順序を重視する
- 実装の共通化：同じ処理は共通化して実装する
- エラー発生時のログ出力：エラー発生時はログを出力する
- 後方互換性重視：既存機能を壊さない実装を優先する
- エラー処理の分離：エラーハンドリングはメイン処理から分離して実装することを好む
- 各LLMに特化したプロンプトを好む
- プロンプトの精度を重視する
- 英語でのプロンプトを好む
- SystemPromptの役割を理解している
- ドキュメントの正確性重視：実装との一貫性を保ち、正確な情報を維持することを重視
- 明確な構造化：ドキュメントや実装を論理的に整理することを好む
- 詳細な説明重視：機能や仕様の説明を具体的かつ詳細に記載することを好む
---
# Taskの振り返りのフォーマット
## Task名
- <Task名を一行で記載>
例：「チャットUI実装とデバッグ画面の統合」
## 目的
- <Taskの目的を記載>
例：
- 新機能の追加
- 既存機能の改善
- バグ修正
## 成果
- <TASKの成果を箇条書きで記載>
例：
- 実装した機能のリスト
- 修正したバグの内容
- 改善した性能の指標
### 動作確認手順
1. <実行したコマンドや操作を順番に記載>
2. <各手順の実行結果や確認方法を記載>
3. <確認したエンドポイントやレスポンスを記載>
例：
1. ```bash
flutter run -d web-server
```
2. 画面表示を確認
3. 機能をテスト
## 課題
- <TASKの実施時の課題、特に何度も試行錯誤を重ねた箇所を記載>
例：
- エラーメッセージの解釈に時間がかかった
- パフォーマンスの最適化に苦労した
## 自力で解決できなかった問題
- <以下の場合は必ず記載すること>
1. ユーザーから質問や確認の指示があった場合
2. 実装方針の変更を指示された場合
3. エラー解決にユーザーのヒントが必要だった場合
4. 要件の詳細化や明確化が必要だった場合
例：
- 要件の解釈が不十分で、ユーザーに確認が必要だった
- エラーメッセージの解釈が間違っていた
- 設計上の考慮漏れがあった
### ユーザーから追加された指示のリスト
各指示について以下の要素を必ず含めること：
1. 追加指示：<途中で追加された指示の内容>
2. 変更点：<それぞれの指示で元の方針からの変化点を記載>
3. 理由：<変更点が追加された理由を記載>
4. 影響：<変更点が追加されたことでどのような影響があったかを記載>
## 未実施事項
- <userの要求で実行できなかった内容を記載>
例：
- 時間的制約による未実装機能
- 技術的制約による未対応項目
## 改善案
- <taskをよりうまく実行するためのアプローチ案を記載>
例：
- 初期設計段階での考慮事項
- より効率的な実装方法
- 追加で必要な機能
## ユーザーの傾向
- <userから追加のリクエストからユーザーの暗黙的な好みの傾向をラベリング>
例：
- コードの品質重視
- ユーザビリティ重視
- パフォーマンス重視