القائمة
在编码之前生成结构化的规格文档。当用户要求写 spec、设计功能、规划新项目，或需求模糊时使用（如"我想做一个X"、"帮我设计Y"）。触发词：写spec、写规格、需求不清晰、新功能设计、帮我设计、技术方案、spec。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | spec-driven-development |
| description | 在编码之前生成结构化的规格文档。当用户要求写 spec、设计功能、规划新项目，或需求模糊时使用（如"我想做一个X"、"帮我设计Y"）。触发词：写spec、写规格、需求不清晰、新功能设计、帮我设计、技术方案、spec。 |
生成结构化规格文档（spec）——定义构建什么、为什么、怎样算完成。不负责规划任务或写代码。spec 确认后交给 planning-and-task-breakdown。
spec 结束时不应留下未决问题。 每一个模糊点要么从代码库找到答案，要么逐个向用户推荐默认方案并当场决策。
不适用： 单行修复、需求已明确的改动。已有 spec 只需拆解任务——直接用 planning-and-task-breakdown。
探索代码库 ──→ 逐个澄清 ──→ 撰写 ──→ 确认 & 保存
│ │ │ │
▼ ▼ ▼ ▼
能自己找到 每次只问 填充模板 人类审阅通过
的答案不问 一个问题 后保存到仓库
能从代码库推断的答案，绝不要问用户。 只在以下情况才提问：代码库没有答案、存在多种合理选择、或者选择不可逆且后果重大。
列出你认为确定的事实（从代码库推断出的结论），然后一次只问一个问题。 使用 ‘AskQuestion’ 工具进行提问 每个问题必须附带一个推荐方案——告诉用户你建议怎么做、为什么，让用户只需说是或否。
从代码库确认的事实：
- 技术栈：Spring Boot 2.x + MyBatis-Plus + MySQL（来自 pom.xml）
- 认证方案：Spring Security + JWT，session 无状态（来自 SecurityConfig.java）
- 前端：Vue 3 + Element Plus + TypeScript（来自 package.json）
需要确认的第 1 个问题：
推荐方案——数据模型用两张表：dict_type（类型）和 dict_item（字典项），
类型含 name/code/sort，项含 label/value/type_id/sort。
理由：与项目现有 Complaint 模块的两级结构一致，且支持按编码获取字典的公开 API。
→ 这样可以吗？
逐个推进。 等用户回答前一个问题，再问下一个。不要批量抛出。
当用户给出了你的推荐方案之外的回答，接受它——用户是领域专家。但当用户的回答与你从代码库观察到的事实矛盾时，指出来："但代码中 User 表已有 phone 字段，不需要新增——用现有字段就行，对吗？"
每解决一个问题，就立即填入 spec 对应位置。不要等所有问题问完才动笔——边问边写。
Spec 覆盖六个核心领域：
npm run build、npm test -- --coverage）Spec 模板：
# Spec: [项目/功能名称]
## 目标
[构建什么、为什么。用户故事或验收标准。]
## 技术栈
[框架、语言、关键依赖及版本]
## 命令
[构建、测试、lint、开发——完整命令]
## 项目结构
[目录布局及说明]
## 代码风格
[示例代码 + 关键约定]
## 测试策略
[框架、测试位置、覆盖率要求、测试级别]
## 边界
- 必须做: [...]
- 先问再做: [...]
- 绝不: [...]
## 成功标准
[如何判断完成——具体的、可测试的条件]
## 决策记录
[在澄清过程中做出的关键决策及理由。每条一句话。]
- 决策: 用两张表（dict_type + dict_item）而非单表——理由：支持按编码获取、避免 category 字段冗余
- 决策: 删除类型级联软删除其下字典项——理由：与项目 Complaint 模块的 complaint→complaint_reply 处理一致
注意：模板中没有"待澄清问题"章节。所有问题应在步骤 1 中逐个解决并记录到决策记录中。
将模糊描述转化为可测试的标准：
需求："让仪表盘更快"
转化：
- 仪表盘 LCP < 2.5s（4G 网络）
- 初始数据加载 < 500ms
- 加载中无布局偏移（CLS < 0.1）
→ 这些目标是否正确？
将 spec 提交给人类审阅。确认：
保存到 docs/features/[功能名称]/spec.md。根据目标推导功能名称（如 "用户认证"、"支付集成"）。保存前与用户确认路径。
保存后，明确告知用户： spec 已完成，下一步用 planning-and-task-breakdown 将 spec 拆解为可执行任务。
对于小改动，写最小 spec：
# Spec: [功能名称]
## 目标
[一行——做什么、为什么]
## 成功标准
- [2-3 条可测试的条件]
## 边界
- [实施的约束条件]
6 行 spec 远胜于没有 spec。
| 技能 | 做什么 |
|---|---|
planning-and-task-breakdown | 将 spec 拆解为有依赖关系的可执行任务 |
incremental-implementation | 逐任务实现 |
test-driven-development | 用红-绿-重构验证每个任务 |
| 借口 | 真相 |
|---|---|
| "这个很简单，不需要 spec" | 简单任务仍需验收标准。两行 spec 就可以。 |
| "我先写代码，写完再补 spec" | 那是文档不是规格。spec 的价值在编码之前迫使你想清楚。 |
| "写 spec 太慢了" | 15 分钟写 spec 避免 15 小时返工。 |
| "需求反正会变" | 过时的 spec 仍比没有 spec 强。需求变了就更新它。 |
| "用户很清楚自己要什么" | 再清晰的需求也有隐含假设。spec 暴露这些假设。 |
| 症状 | 应对 |
|---|---|
| 没有书面需求就开始写代码 | 停。问："什么叫'做完'？怎么验证？" |
| "直接开始做吧"而不先澄清 | 引导："先花 5 分钟定一下成功标准。" |
| 做出架构决策却不记录 | 暂停，两句话写下决策和理由。 |
| 因为"很明显"而跳过 spec | 每个"明显"的任务至少藏着一个未说出口的假设。 |
| spec 结尾出现了"待澄清问题"列表 | 违反了核心原则——回到步骤 1，逐个解决。 |
"这点改动写 spec 太麻烦了。" → 用轻量级 spec：目标（1 行）+ 成功标准（2-3 条）+ 边界。
"我知道要什么，直接做就行。" → "好的，我复述一下理解——30 秒。"写出 2-3 条成功标准。有不对的恰好证明 spec 的价值。
"我们边走边看吧。" → 只为第一个切片写 spec，做完再为下一个切片写。保持节奏，避免跑偏。
把任意主题（技术概念、框架、API、产品、算法、流程等）讲成新手能一口气读懂的「深度讲解」内容，输出可为 HTML 长页、Markdown 文章或其它格式。核心方法是「懂→用→慎」三幕递进动线：先用生活类比建立直觉，再给真实应用，最后才讲限制与风险，并按主题类型自适应选节。当用户要求新手向解读、通俗讲解、生活化比喻、把文档讲清楚、调整讲解顺序、消除重复章节、或做成可分享的 explainer 时触发。关键词：深度讲解、新手向、通俗解读、生活类比、讲解动线、explainer、递进结构、把概念讲清楚。
从 PRD 文档或产品描述自动生成高保真移动端 App 原型 HTML 页面。Use when the user provides a PRD, product requirements doc, feature description, or app idea and wants to generate high-fidelity mobile app prototypes, create UI mockups, visualize product features as mobile screens, or build interactive HTML prototypes. Also triggers on "原型图", "高保真原型", "mockup", "app prototype", "UI 设计稿", "手机界面", "移动端原型", or when user pastes product requirements and asks for visual output. Covers the full pipeline — UX analysis, interface planning, UI design, HTML implementation with iPhone 15 Pro device frames.
根据产品说明、页面描述、模块功能、数据库表结构、字段清单、业务规则推理出 RESTful API 接口设计文档，包含接口名称、HTTP 方法、路径、入参、出参、校验规则和 Mermaid 流程图。当用户提到"推理接口"、"设计接口"、"API 文档"、"接口设计"、"推断接口"、"帮我设计接口"、"推导 API"、"根据表结构生成接口"时使用此技能。也适用于用户给出页面、模块、表结构或碎片化需求，需要产出接口文档的场景。
将完整的HTML网页设计稿（含CSS、图片资源）转化为微信小程序原生页面（WXML/WXSS/JS）。Use when the user wants to: (1) Convert an HTML design/mockup to a WeChat Mini Program page, (2) Transform web frontend code to WXML/WXSS, (3) Port a web UI layout to mini-program with 1:1 visual fidelity, (4) Generate mini-program pages from HTML/CSS snippets or screenshots. 特别注意小程序顶部导航栏（自定义/系统默认）和底部tabBar的配置差异，项目使用Skyline渲染器。
根据用户提供的页面地址（URL 或路由路径）为该页面生成完整的 Playwright e2e 测试，覆盖页面上所有可见功能（筛选、表格、按钮、弹窗、跳转、导出等）。先询问使用真实 API 还是 Mock 数据两种模式，再读取组件源码推断功能点，最后生成并运行测试。适用于用户说“给这个页面生成 e2e”“测一下 /xxx 页的功能”“写 playwright 测试”“为 xxx 页补 e2e”等场景。
将 spec 或需求拆解为有序、可执行的任务列表。当用户有一份 spec 需要落地、感觉任务太大无从下手、需要评估工作量、或需要编排并行工作时使用。触发词：拆任务、任务拆解、出计划、实施计划、排期、task list、plan。