关于 laravel:prompt-structure
laravel:prompt-structure 是面向 Laravel 开发者的提示词编写指南，帮助将开发请求组织得清晰、可执行。内容涵盖任务拆分、排序、验收标准和重构说明。
主要功能
- 01每个请求聚焦单一事项
- 02按依赖关系安排任务顺序
- 03明确验收标准
- 04将大型工作拆成阶段
- 05说明重构问题与目标
适用场景
- 01规划 Laravel 功能开发
- 02拆分大型应用需求
- 03为实现结果定义标准
- 04描述代码重构请求
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/laravel:prompt-structure确认已加载。
详细介绍
提示词结构
结构良好的提示词能获得完整且可执行的回复。结构不佳则会导致来回澄清，解决方案也不完整。
分开处理不同事项
效果不佳
“更新 User 模型以添加电子邮件验证，同时创建密码重置 API 端点，并为个人资料更新表单添加验证”
效果良好
将请求拆分为重点明确的事项：
- “使用 Laravel 的 MustVerifyEmail trait 为 User 模型添加电子邮件验证”
- “在 POST /api/password/reset 创建密码重置 API 端点”
- “为 ProfileUpdateRequest 中的 name、email 和 bio 字段添加验证”
每项请求都有一个明确目标，更容易审查、测试和迭代。
确定优先级和顺序
效果不佳
“需要身份验证、用户仪表板、管理面板和电子邮件通知”
效果良好
“我们先构建身份验证：
- 配置 Sanctum 以实现 API 身份验证
- 创建登录和注册端点
- 添加中间件来保护路由
身份验证正常后，再添加用户仪表板、管理功能，最后添加通知。”
顺序很重要。先构建基础，再添加依赖于基础的功能。
明确验收标准
含糊
“让结账流程正常运行”
明确
“实现结账流程，要求如下：
- 用户必须通过身份验证
- 购物车中至少有一件商品
- 计算含税总额（8.5%）
- 创建状态为 'pending' 的 Order 记录
- 将 ProcessOrderJob 派发到队列
- 返回订单 ID 和确认消息
- 妥善处理付款失败”
标准明确，实施方案也就明确。
拆分工作
范围过大
“构建一个完整的博客系统，包含文章、评论、分类、标签和搜索”
合适的范围
“我们先从核心文章功能开始：
阶段 1：基本文章
- 创建 Post 模型（title、content、published_at）
- 添加 CRUD 端点
- 编写创建、读取、更新和删除的功能测试
阶段 2：分类
- 添加带有 belongsToMany 关系的 Category 模型
- 更新文章端点以处理分类
- 测试分类分配
阶段 3：评论（依此类推……）
每个阶段都可测试、可交付。”
重构请求
不清楚
“这段代码很乱，整理一下”
清楚
“重构 UserController@store：
当前问题：
- 一个方法有 80 行
- 混杂了验证、业务逻辑和电子邮件发送
- 难以单独测试各部分
期望改进：
- 将验证提取到 UserStoreRequest
- 将用户创建逻辑移至 UserService
- 派发 SendWelcomeEmail 任务，而不是在代码中直接发送
- 控制器应负责协调，而非具体实现”
说明问题和期望状态。
规划功能
效果不佳
“添加社交登录”
效果良好
“添加 GitHub OAuth 登录：
验收标准：
- 用户点击“使用 GitHub 登录”按钮
- 重定向到 GitHub OAuth
- 回调时，根据 github_id 创建或查找用户
- 存储 github_token 以便访问 API
- 使用会话重定向到仪表板
可测试的增量：
- 配置 Socialite 和 GitHub provider
- 为 users 添加 github_id 和 github_token 列
- 创建包含重定向和回调方法的 OAuth 控制器
- 为完整 OAuth 流程编写功能测试
- 在登录页面添加“使用 GitHub 登录”按钮”
拆分工作，使其可测试。
快速参考
组织提示词时：
- 每项请求只涉及一个事项 - 不要混合不相关的更改
- 按逻辑安排顺序 - 先构建依赖项
- 定义成功标准 - “完成”是什么样的？
- 拆分大型工作 - 以可测试的增量为目标
- 说明重构内容 - 当前问题 + 期望状态
结构清晰，结果也就清晰。
评论
支持 Markdown