2025年8月12日

Cursor cliでできることを尋ねてみた

プロンプト1

あなたは何ができますか?

回答1

簡潔に自己紹介します。あなたの開発作業を支援するために、できることを要点でまとめます。

できること

• リポジトリ理解: コード検索・読解、依存関係の把握、設計の要約 • 実装/編集: 新機能追加、既存機能の改修、型付け、API/CLI作成 • デバッグ/修正: エラー再現、原因特定、修正、回帰を防ぐテスト追加 • テスト: ユニット/E2E作成、テスト実行、カバレッジ向上 • パフォーマンス: ボトルネック特定、プロファイル、最適化 • リファクタリング: 可読性/保守性改善、分割、命名整理 • セキュリティ/品質: 静的解析、脆弱性指摘、lint整備 • ビルド/CI: ビルド修正、GitHub Actions 等のCI設定 • Git運用: ブランチ作成、コミット、PR作成・要約 • 環境/インフラ: Dockerfile/docker-compose 作成・修正、基本的なIaC • ドキュメント: README/設計メモ/使用方法の整備 • 画像対応: エラー画面や図のスクショからの原因推測

対応スタックの例

• 言語: TypeScript/JavaScript, Python, Go, Rust, Java, Kotlin, Swift, Ruby, Bash • フロント: React/Next.js, Vue/Nuxt, SvelteKit 他 • バックエンド: Node/Express/Fastify, Python(FastAPI/Django), Go, Java(Spring) • DB: Postgres/MySQL/SQLite, Prisma/TypeORM/SQLAlchemy 等

進め方(安全運用)

• 変更はリポジトリ内の該当ファイルに直接「編集」を行い、必要ならテスト/ビルドを実行 • コミットやPRもこちらで作成可能(リモートへの push は指示がある場合のみ) • 永続プロセスは実行しません

すぐ試せる依頼例

• 「テストが落ちているので直してコミットまでお願い」 • 「api/user.ts に一覧APIを追加して、単体テストも」 • 「このPRを作って、要約とテスト手順を書いて」 • 「この関数を高速化して、ベンチ結果を見せて」 • 「Dockerで起動できるようにして」

いまこのリポジトリで、まず何を達成したいですか?ファイルパスやエラーメッセージ、スクショがあればそのまま貼ってください。 • 概要を提示し、対応できる作業範囲と進め方を明確化しました。準備OKです。

プロンプト2

cursorのagentモードやaskモードと何が決定的に違うの?

回答2

要点だけで。

決定的な違い

• ゴール志向の自動遂行: 依頼をエンドツーエンドで完了まで実行(編集→テスト→コミット→PR)。Askは提案中心、Agentは自動化するが完了までの流れが一定でないことが多い。 • 強い運用ガードレール: • 長時間常駐コマンドは実行しない • リモートへの push は明示依頼がない限りしない • Git設定は変更しない、対話的コマンドは使わない • コミットはHEREDOCでメッセージ固定化、PR本文も定型で作成 • 決まったGit/PRフロー: 変更検出→要約→ステージング→コミット→(必要なら)ブランチ/PR作成までを定型手順で実施。失敗時はフック反映を1回だけリトライ。 • 並列最適化がデフォルト: 検索・読み込み・差分取得などは原則並列実行で高速化。Agent/Askはここが一貫していないことがある。 • 安全なファイル操作規約: パスのクォート徹底、親ディレクトリ検証、ripgrep優先、危険なfind/grepや長出力の読み取りを避ける。 • 変更は“提示”でなく“編集”: コードは画面に長文を貼らず、直接リポジトリを編集(テスト/ビルドも実行)。Askは提案止まりになりやすい。 • 定期的な進捗と短いサマリ: 各まとまりで進捗を述べ、最後に簡潔なサマリを返す運用が必須。 • コード品質規約の強制: 明快な命名、早期return、例外処理方針、コメント方針、長行の折返し等を守って実装。レビュー前提の読みやすさ重視。 • ユーザー確認に依存しない前進: ブロックされない限り自己判断で進める(ただし安全ガードは順守)。

ひとことで

• Ask: チャット助言中心 • Agent: 自動化タスク実行 • 私: ガードレール付きで“終わりまでやる”実務フロー(編集→検証→Git/PR)を標準化して遂行 • 決定的な違いを短く対比しました。要は、私は「安全ガイドラインに沿ったエンドツーエンド実務」を既定運用でやり切ります。