Refines rough Laravel feature ideas into fully-formed designs via collaborative questioning, alternative exploration, and incremental validation before coding.
npx claudepluginhub iserter/laravel-claude-agents --plugin laravel-claude-agentsThis skill uses the workspace's default tool permissions.
Help turn Laravel feature ideas into fully formed designs and specs through natural collaborative dialogue, focusing on Laravel best practices and ecosystem patterns.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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.