メニュー
Use when creating or developing Laravel features, before writing code or implementation plans - refines rough ideas into fully-formed Laravel designs through collaborative questioning, alternative exploration, and incremental validation.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Best practices for Laravel Eloquent ORM including query optimization, relationship management, and avoiding common pitfalls like N+1 queries.
Best practices for Laravel API Resources including resource transformation, collection handling, conditional attributes, and relationship loading.
Best practices for Laravel authorization including Gates, Policies, middleware auth, and Blade directives for access control.
Best practices for Laravel Blade components including class-based and anonymous components, slots, attribute bags, and reusable UI patterns.
Best practices for Laravel caching including cache patterns, tags, atomic locks, flexible cache, and cache invalidation strategies.
Best practices for Laravel events and listeners including event discovery, queued listeners, subscribers, and model events for decoupled architecture.
| name | laravel-brainstorming |
| description | Use when creating or developing Laravel features, before writing code or implementation plans - refines rough ideas into fully-formed Laravel designs through collaborative questioning, alternative exploration, and incremental validation. |
Help turn Laravel feature ideas into fully formed designs and specs through natural collaborative dialogue, focusing on Laravel best practices and ecosystem patterns.
Start by understanding the current Laravel project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
Understanding the idea:
Example Questions:
Exploring approaches:
Example:
For the notification system, I see three approaches:
1. Laravel Notifications with database channel (recommended)
- Built-in, follows Laravel conventions
- Easy to add email/Slack later
- Simple to mark as read
Trade-off: Less flexible for complex notification logic
2. Custom Event/Listener system
- Maximum flexibility
- Can add complex rules
Trade-off: More code to maintain
3. Third-party package (like Laravel Echo)
- Real-time out of the box
Trade-off: External dependency, overkill if not needed
I'd recommend #1 for most cases - start simple, Laravel's notification system is excellent and you can always extend it later if needed.
Which approach feels right for your use case?
Presenting the design:
First, let's look at the database design:
We'll need three tables:
1. `posts` - title, slug, content, status, published_at
2. `tags` - name, slug
3. `post_tag` - pivot table for many-to-many
The posts table will have a foreign key to users, indexed on status and published_at for common queries. We'll use an enum for status (draft, published, archived) to keep it clean.
Does this schema structure make sense for what we're building?
For the models, we'll have:
Post model with:
- belongsTo relationship to User
- belongsToMany relationship to Tag
- Scopes: published(), draft(), recent()
- Casts: published_at as datetime, metadata as array
- Factory for testing
Tag model with:
- belongsToMany relationship to Post
- Slug auto-generation on save
Should we add soft deletes to posts, or will hard deletes work?
For the API endpoints, following RESTful conventions:
GET /api/posts - List posts (paginated)
POST /api/posts - Create post
GET /api/posts/{post} - Show post
PUT /api/posts/{post} - Update post
DELETE /api/posts/{post} - Delete post
Authentication via Sanctum, rate limited to 60 requests/minute.
API resources will transform the output, hiding sensitive data.
Does this API structure cover your needs?
The posting workflow:
When a post is published:
1. PostService validates the post is ready (has title, content)
2. Sets published_at timestamp
3. Dispatches NotifySubscribers job to queue
4. Fires PostPublished event for other listeners
5. Clears related caches
We'll use a service class to keep controllers thin, and queues for email notifications so publishing is fast.
Is this flow what you had in mind?
Documentation:
docs/designs/YYYY-MM-DD-<feature>-design.mdImplementation (if continuing):
When brainstorming Laravel features, consider:
Architecture:
Database:
Performance:
Testing:
Security:
Claude: I see you want to add a comment system. Let me understand the requirements.
First question: Should comments be nested (replies to replies) or just one level deep (replies to posts only)?
User: Just one level - comments on posts.
Claude: Got it. And for moderation, which approach:
A) All comments published immediately
B) Comments from new users require approval
C) All comments require approval
User: B - new users need approval.
Claude: Perfect. For notifications when someone comments:
A) Real-time via Laravel Echo and WebSockets
B) Email only
C) In-app notifications (database)
User: In-app notifications.
Claude: Excellent. Let me present the design...
[Design sections follow]
The goal is to arrive at a clear, actionable Laravel design that:
Ask questions until you understand, then design in small validatable chunks.