Cursorの機能を使って複数ファイルのコードの形式を一括編集させる
まるべいじ雑に書いて後でまとめる
まるべいじこんな感じで使ってみる
- 正規表現使ってプロジェクトない検索
- Cursor Composer開く
- 1で検索したものをサイドバーから全選択してドラッグ&ドロップする
- Composerで以下のプロンプト実行
@xxxx.ts @yyyy.tx ....
このファイルにあるxxxxWithSentryの関数からWithSentryがつかない関数名に既存のファイルを編集して変えたいです。変更方針は下記の通りにしてください。
全てのファイルに対する変更提案してください。
before code
````
const xxAction = async () => {
// ...process
};
export const xxActionWithSentry = withSentry(
"xxActionWithSentry",
xxAction,
);
````
after code
````
const xxAction = withSentry("xxAction", () => {
// ...process
});
````
新規ファイルで作ろうとしてくる。
対策として禁止事項追加して、新規ファイルの追加禁止にする項目入れたのに。
まるべいじ先に編集対象のpath列挙させてからやったら何回か行けるパターンがある
まるべいじコメント消したりへんな変更してくる。
許容して、AI Review（Bata）使って最後に全てレビューさせて検知するようしてみたけど、レビューで全然指摘してくれない。
まるべいじComposerではなくChat機能使ったらいけた
けど、ChatだとAcceptしていく作業がめんどいからComposer使いたい。
まるべいじ@Filesでファイル指定してるのに、よくわからないpathでファイル新規生成してくるのなんでだ
本来のディレクトリ
- frontend/apps/user
Cursorが頑なに生成してくるファイルのディレクトリ
- frontend/user
(pathの列挙させた時もこのpathがプレフィックスになって出てくる)
まるべいじ原因を聞いてみればいいんだ
まるべいじ原因を聞いたらこのworkspace設定のnameを元にしたからへんな解釈してるっぽい。
xxxx.code-workspace
{
"name": "frontend/user",
"path": "frontend/apps/user"
},
この原因と本来のディレクトリ構造教えたチャットで追加でpath列挙させても同じこと起きるのはなぜ。
workspaceで開いてる状態で@Filesに追加すると、workspaceの名前をpathの最初に入れる習性があるのか。
まるべいじそうしたらpath列挙させて、正しいpathにさせてから本来やりたい処理実行させればOKかな
まるべいじStep 1
全てのpathを`- xxx`のリストで列挙して。
pathのプレフィックスがfrontend/userの場合はfrontend/apps/userに変更して。
Step 2
それら全てに編集を加えたいので、まずは、1つ変更内容を出してください。
＜修正方針＞
- 既存ファイルを変更して修正を行う
- xxxxWithSentryの関数からWithSentryがつかない関数名に変更
- xxxxWithSentry関数を呼び出していたファイルにimportや関数呼び出しの変更を加える
- 変更内容は/frontend/apps/userディレクトリの配下に適用して
- 変更方針は下記
before code
```
const xxAction = async () => {
// ...process
};
export const xxActionWithSentry = withSentry(
"xxActionWithSentry",
xxAction,
);
```
after code
```
const xxAction = withSentry("xxAction", () => {
// ...process
});
```
＜禁止事項＞
- 新規ファイルの追加
- 既存ファイルにあるコードからxxActionWithSentryの削除をする目的以外のコード追加と削除
Step 3
終わるまでStep 3のプロント送る
同様に残りのファイルも変更して
完璧すぎる回答が返ってくるぞ
まるべいじ関数を使ってるファイルも変更内容に合わせて習性させるようにしてみよう
まるべいじ関連ファイルのpathを全て列挙して。出力形式は関連元と関連先のファイルバスがわかるようにして。pathのプレフィックスがfrontend/userの場合はfrontend/apps/userに変更して。
ポイント
- Step 1で聞いたファイルを元に回答してくる
- 出力形式を限定しないとよくわからない括りでグルーピングして列挙してくる
これでやろうと思ったけど、うまく一覧で一気に回答してくれないのでStep 2のプロンプトを変更してやってみる。
まるべいじそれら全てに編集を加えたいので、まずは、1つ変更内容を出してください。
＜修正の実行手順＞
1. 修正しようとしているファイルのパスを確認し出力する
2. このファイルで定義されている関数がどこで使用されているか、@Codebase から探してください
3. 見つかった使用箇所のファイルパスを<related_file>タグで提示してください
4. 修正による影響範囲を確認できたら、修正案を提示してください
1. 実際のコードの依存関係を確認できましたか？
2. 提案された変更がすべての使用箇所で動作することを確認できましたか？
3. 修正による副作用が考えられる箇所はありますか？
4. 禁止事項に違反をした修正を加えていませんか？
＜修正方針＞
- 関数を定義している既存ファイルを変更して修正を行う
- 関数を呼び出しているファイルに修正を反映する
- xxxxWithSentryの関数からWithSentryがつかない関数名に変更
- xxxxWithSentry関数を呼び出していたファイルにimportや関数呼び出しの変更を加える
- 変更内容は/frontend/apps/userディレクトリの配下に適用して
- 変更方針は下記
before code
```
const xxAction = async () => {
// ...process
};
export const xxActionWithSentry = withSentry(
"xxActionWithSentry",
xxAction,
);
```
after code
```
const xxAction = withSentry("xxAction", () => {
// ...process
});
＜禁止事項＞
- 新規ファイルの追加
- 既存ファイルにあるコードからxxActionWithSentryの削除をする目的以外のコード追加と削除
- 実行手順を追加しないと、関連ファイルの変更提案してくれるがコードブロックでの提案になる
プロンプトを実行 => 結果を確認 => プロンプトを考え直して再度実行 => ....
この手順でやってたけど、思うような修正ができなかった。
プロンプトを実行 => 結果を確認 => 想定と違う回答をした原因を聞く => 原因を回避するプロンプトを聞いてみる => 聞いたプロンプトと元々のプロンプトをマージする
これでやると結構いい感じに動く
@Codebaseを文章の途中に入れるとそこから探してくれるらしい？
まるべいじそれら全てに編集を加えたいので、まずは、1つ変更内容を出してください。
＜修正の実行手順＞
1. 修正しようとしているファイルのパスを確認し出力する
2. 1のファイルを修正方針と禁止事項に則り修正してください。
3. 修正による影響範囲を確認できたら、修正案を提示してください
1. 禁止事項に違反をした修正を加えていませんか？
＜修正方針＞
- 既存ファイルを変更して修正を行う
- xxxxWithSentryの関数からWithSentryがつかない関数名に変更
- xxxxWithSentry関数を呼び出していたファイルにimportや関数呼び出しの変更を加える
- 変更内容は/frontend/apps/userディレクトリの配下に適用して
- 変更方針は下記
before code
```
const xxAction = async () => {
// ...process
};
export const xxActionWithSentry = withSentry(
"xxActionWithSentry",
xxAction,
);
```
after code
```
const xxAction = withSentry("xxAction", () => {
// ...process
});
```
＜禁止事項＞
- 新規ファイルの追加
- 以下の変更は一切禁止:
- 型定義の変更や追加(Promise<T>の追加なども含む)
- インデントやフォーマットの変更
- 改行の追加や削除
- 関数の引数の括弧のスタイル変更
- コメントの追加、削除、変更
- 許可される変更は以下のみ:
- xxActionWithSentryの削除
- xxActionの新しい実装の追加
- Sentryのaction名の変更
禁止事項の規制が弱くて貫通してくる時ある。例えば勝手に型定義変えてきたり
禁止事項を明確にするようなプロンプトを聞いて反映した
まるべいじ続けて変更をする時には先にファイル名をだしてもらう方が一回の修正ファイル数が多くなる感じがする
残りのファイルも続けて。修正する時に以下の手順にして
1. 修正する次のファイルのリストを出力
2. 修正ファイルを並列で修正
一度このプロンプトを実行したら残りは「続けて」で直してくれる
まるべいじ最終的に使ったプロンプト
Step 1
@Filesで指定
@xxxx.ts @yyyy.tx ....
全てのpathを`- xxx`のリストで列挙して。
pathのプレフィックスがfrontend/userの場合はfrontend/apps/userに変更して。
Step 2
それら全てに編集を加えたいので、まずは、1つ変更内容を出してください。
＜修正の実行手順＞
1. 修正しようとしているファイルのパスを確認し出力する
2. 1のファイルを修正方針と禁止事項に則り修正してください。
3. 修正による影響範囲を確認できたら、修正案を提示してください
1. 禁止事項に違反をした修正を加えていませんか？
＜修正方針＞
- 既存ファイルを変更して修正を行う
- xxxxWithSentryの関数からWithSentryがつかない関数名に変更
- xxxxWithSentry関数を呼び出していたファイルにimportや関数呼び出しの変更を加える
- 変更内容は/frontend/apps/userディレクトリの配下に適用して
- 変更方針は下記
before code
```
const xxAction = async () => {
// ...process
};
export const xxActionWithSentry = withSentry(
"xxActionWithSentry",
xxAction,
);
```
after code
```
const xxAction = withSentry("xxAction", () => {
// ...process
});
```
＜禁止事項＞
- 新規ファイルの追加
- 以下の変更は一切禁止:
- 型定義の変更や追加(Promise<T>の追加なども含む)
- インデントやフォーマットの変更
- 改行の追加や削除
- 関数の引数の括弧のスタイル変更
- コメントの追加、削除、変更
- 許可される変更は以下のみ:
- xxActionWithSentryの削除
- xxActionの新しい実装の追加
- Sentryのaction名の変更
Step 3
残りのファイルも続けて。修正する時に以下の手順にして
1. 修正する次のファイルのリストを出力
2. 修正ファイルを並列で修正
Step 4
続けて修正を提案して
xxxx.code-workspaceが悪さしてたっぽい。
モノレポで以下の構成とってて、workspaceの設定でnameとpathがあった場合にnameの方を基準にファイルパスの解決してしまうっぽい。
backend
frontend
|- apps
|- user
|- business
|- admin
{
"name": "backend",
"path": "backend"
},
{
"name": "frontend/user",
"path": "frontend/apps/user"
},
{
"name": "frontend/business",
"path": "frontend/apps/business"
},
{
"name": "frontend/packages",
"path": "frontend/packages"
},
対策方法1
nameとpathに同じ値を入れることで解消できる。
ただ、これだとnameの意味があまりない。
対策方法2
.cursorrulesに説明テキストを追加する。
基本的にこのファイルはデフォルトでコンテキストに追加されるので、実行時に自動で考慮される。
ただ、最初のチャットでこの2ファイルをコンテキストに含んでも、修正指示をするチャットの時点では無視されることが多々あるので、修正指示をするときに再度この2ファイルをコンテキストについかするのが良い。
## workspace
shogun.code-workspaceのfoldersの設定を参考にする。
nameがワークスペース名で、pathがディレクトリパス。
ファイルのパスはディレクトリパスを基準にする。
ターミナルのtypecheckでエラーになったものをComposerで直すために、ターミナルからComposerにエラー内容のコンテキストを渡す機能がある。
それを使ってファイルを修正したときに、正しいpathで直すものと推測したファイル名で直すものがあった。
原因はターミナルのウィンドウ幅がテキスト量を超えた時に省略されるようになっていた。
対策としてcursorの設定でテキスト折り返しを探したができなかった。
terminalでstty cols 1000を打ったら1行当たり1000文字まで出力するようになった。
これは開いているウィンドウでしか適用されないので、~/.zshrcにstty cols 1000を追加することで対応。
まるべいじやっぱり先に修正対象のファイルパス全てを列挙させると、後の修正指示で正しいファイルを修正してくれるようになる。
列挙させた後にBのテキストで指示を出すと対象ファイルを間違えることがほぼない。
A. これらのファイル全て
B. 列挙したファイルパス全て
まるべいじ修正指示出す時は、@Codebaseも含めておくほうが変なファイルを作ったり編集したりしないぽい