laravel:prompt-structure について
laravel:prompt-structureは、明確で実行可能なプロンプトを書くためのLaravel開発者向けガイドです。作業の分割、順序付け、受け入れ条件、リファクタリングの伝え方を扱います。
主な機能
- 01依頼ごとに論点を一つに絞る
- 02依存関係に沿って作業を順序付け
- 03受け入れ条件を定義
- 04大きな作業を段階に分割
- 05リファクタリングの問題と目標を説明
活用シーン
- 01Laravel機能の開発を計画
- 02大規模なアプリ要件を分割
- 03実装の完了条件を設定
- 04コードのリファクタリングを依頼
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/laravel:prompt-structureを入力して読み込まれたか確認します。
詳細
プロンプトの構成
構成の整ったプロンプトは、完全で実行可能な回答を引き出します。構成が不十分だと、確認のやり取りが何度も必要になり、解決策も不完全になります。
懸念事項を分ける
効果的でない例
「User モデルにメール認証を追加し、パスワードリセット用の API エンドポイントも作成して、プロフィール更新フォームにバリデーションを追加してください」
効果的な例
焦点を絞った依頼に分けます。
- 「Laravel の MustVerifyEmail トレイトを使って、User モデルにメール認証を追加してください」
- 「POST /api/password/reset にパスワードリセット用の API エンドポイントを作成してください」
- 「ProfileUpdateRequest に name、email、bio フィールドのバリデーションを追加してください」
各依頼には明確な目標が1つあります。レビュー、テスト、反復がしやすくなります。
優先順位を付け、順序を決める
効果的でない例
「認証、ユーザーダッシュボード、管理パネル、メール通知が必要です」
効果的な例
「まず認証を構築しましょう。
- API 認証用に Sanctum を設定する
- ログイン／登録のエンドポイントを作成する
- ルートを保護するミドルウェアを追加する
認証が動作したら、ユーザーダッシュボードを追加し、その後に管理機能、最後に通知を追加します。」
順序が重要です。まず土台を構築し、その後、それに依存する機能を追加します。
受け入れ基準を明確にする
曖昧な例
「チェックアウトの処理を動くようにしてください」
具体的な例
「次の要件でチェックアウト処理を実装してください。
- ユーザーが認証済みであること
- カートに商品が1つ以上入っていること
- 税金（8.5%）を含めて合計金額を計算すること
- 'pending' ステータスの Order レコードを作成すること
- ProcessOrderJob をキューにディスパッチすること
- 注文 ID と確認メッセージを返すこと
- 支払いの失敗を適切に処理すること」
基準が明確であれば、実装も明確になります。
作業を分割する
大きすぎる例
「投稿、コメント、カテゴリー、タグ、検索機能を備えたブログシステム全体を構築してください」
適切な規模の例
「まず投稿の基本機能から始めましょう。
フェーズ1：基本的な投稿
- Post モデルを作成する（title、content、published_at）
- CRUD エンドポイントを追加する
- 作成／読み取り／更新／削除の機能テストを書く
フェーズ2：カテゴリー
- belongsToMany リレーションシップを持つ Category モデルを追加する
- カテゴリーを扱えるように投稿エンドポイントを更新する
- カテゴリーの割り当てをテストする
フェーズ3：コメント（以降同様）
各フェーズはテスト可能で、成果物として提供できます。」
リファクタリングの依頼
不明確な例
「このコードはごちゃごちゃしているので、きれいにしてください」
明確な例
「UserController@store をリファクタリングしてください。
現在の問題：
- 1つのメソッドが80行ある
- バリデーション、ビジネスロジック、メール送信が混在している
- 個々の処理をテストしにくい
望ましい改善：
- バリデーションを UserStoreRequest に切り出す
- ユーザー作成ロジックを UserService に移す
- インラインでのメール送信の代わりに、SendWelcomeEmail ジョブをディスパッチする
- コントローラーは処理を実装するのではなく、各処理を調整する」
問題と望ましい状態を説明しましょう。
機能の計画
効果的でない例
「ソーシャルログインを追加してください」
効果的な例
「GitHub OAuth ログインを追加してください。
受け入れ基準：
- ユーザーが「GitHub でログイン」ボタンをクリックする
- GitHub OAuth にリダイレクトする
- コールバック時に、github_id でユーザーを作成するか検索する
- API アクセス用に github_token を保存する
- セッションを維持したままダッシュボードにリダイレクトする
テスト可能な段階：
- GitHub プロバイダーを使って Socialite を設定する
- users に github_id と github_token のカラムを追加する
- リダイレクトとコールバックのメソッドを備えた OAuth コントローラーを作成する
- OAuth の全体的なフローを対象とする機能テストを書く
- ログインページに「GitHub でログイン」ボタンを追加する」
細分化しましょう。テスト可能な形にしましょう。
クイックリファレンス
プロンプトを構成する際は、次の点を意識しましょう。
- 依頼ごとに懸念事項を1つにする - 関連のない変更を混在させない
- 論理的な順序にする - まず依存関係を構築する
- 成功の基準を定める - 「完了」とはどのような状態か？
- 大きな作業を分割する - テスト可能な段階を目指す
- リファクタリングの内容を説明する - 現在の問題と望ましい状態
構成が明確であれば、結果も明確になります。