refactor: 通用技能按类别拆分为独立目录

skills/ → skills-dev(9), skills-req(10), skills-ops(4),
skills-integration(8), skills-biz(4), skills-workflow(7)

generate-marketplace.py 改为自动扫描所有 skills-* 目录。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

skills-req/req-plugin/prd-review-guide.md

@@ -0,0 +1,126 @@
+# PRD 评审方法论
+
+> 评审 PRD 是需求流程中的关键质量关卡。
+
+## 评审流程
+
+1. **结构完整性检查** - 检查 PRD 是否包含所有必要章节
+2. **需求清晰度评估** - 验证需求描述是否明确无歧义
+3. **技术可行性分析** - 评估技术方案是否可实现
+4. **数据模型验证** - 检查数据结构设计是否合理
+5. **API 设计审查** - 验证接口设计是否符合规范
+
+## PRD 评审检查清单
+
+### 一、结构完整性检查
+
+| 检查项 | 必须 | 说明 |
+|--------|------|------|
+| 基本信息 | ✓ | 需求编号、标题、创建日期、作者 |
+| 需求背景 | ✓ | 为什么需要这个功能 |
+| 目标用户 | ✓ | 明确功能面向的用户群体 |
+| 功能描述 | ✓ | 详细的功能需求说明 |
+| 用户故事 | ○ | As a... I want... So that... |
+| 数据模型 | ✓ | 数据库表结构设计 |
+| API 设计 | ✓ | RESTful 接口定义 |
+| 页面原型 | ○ | 界面布局和交互说明 |
+| 非功能需求 | ○ | 性能、安全、可用性要求 |
+| 验收标准 | ✓ | 明确的功能验收条件 |
+
+> ✓ = 必须包含, ○ = 建议包含
+
+### 二、需求清晰度评估（SMART 原则）
+
+| 原则 | 检查点 | 示例 |
+|------|--------|------|
+| **S**pecific | 需求描述是否具体明确 | ❌ "支持搜索" → ✅ "支持按需求编号、标题模糊搜索" |
+| **M**easurable | 是否有量化指标 | ❌ "快速响应" → ✅ "响应时间 < 200ms" |
+| **A**chievable | 技术上是否可行 | 评估现有技术栈能否支持 |
+| **R**elevant | 是否与业务目标相关 | 功能是否解决实际问题 |
+| **T**ime-bound | 是否有明确的时间范围 | 开发周期、上线日期 |
+
+### 三、技术可行性分析
+
+| 检查维度 | 评估内容 |
+|----------|----------|
+| 技术栈兼容性 | 现有技术栈是否支持所需功能 |
+| 系统架构影响 | 是否需要修改现有架构 |
+| 第三方依赖 | 是否引入新的外部依赖 |
+| 性能影响 | 对系统性能的潜在影响 |
+| 安全考量 | 是否存在安全风险 |
+| 数据迁移 | 是否需要数据迁移方案 |
+
+### 四、数据模型验证
+
+| 检查项 | 说明 |
+|--------|------|
+| 表结构设计 | 字段类型、约束、索引是否合理 |
+| 关联关系 | 外键、多对多关系是否正确 |
+| 命名规范 | 表名、字段名是否符合项目规范 |
+| 扩展性 | 是否预留扩展字段 |
+| 数据量预估 | 数据增长预估和存储方案 |
+| 查询性能 | 常用查询是否有索引支持 |
+
+### 五、API 设计审查
+
+| 检查项 | 标准 |
+|--------|------|
+| RESTful 规范 | URL 使用名词、HTTP 方法语义正确 |
+| 响应格式 | 统一的响应结构 `{success, data, message}` |
+| 错误处理 | 明确的错误码和错误信息 |
+| 分页设计 | 列表接口支持分页 `?page=1&page_size=20` |
+| 参数验证 | 必填参数、类型、范围说明 |
+| 版本控制 | API 路径包含版本 `/api/v1/...` |
+
+## 评审意见模板
+
+### 通过模板
+
+```
+✅ PRD 评审通过
+
+【评审结论】
+PRD 文档结构完整，需求描述清晰，技术方案可行，建议批准进入开发阶段。
+
+【肯定之处】
+- 需求背景阐述清晰
+- 数据模型设计合理
+- API 接口规范
+
+【建议改进】（非阻塞）
+- 建议补充性能测试用例
+- 建议增加边界条件说明
+
+【评审人】xxx
+【评审时间】2026-01-24 10:00
+```
+
+### 驳回模板
+
+```
+❌ PRD 评审驳回
+
+【驳回原因】
+1. 数据模型缺少索引设计
+2. API 接口缺少错误处理说明
+3. 搜索功能需求描述模糊
+
+【修改要求】
+□ 补充数据表索引设计
+□ 明确 API 错误码定义
+□ 细化搜索功能的具体实现方式
+
+【驳回人】xxx
+【驳回时间】2026-01-24 10:00
+```
+
+## 常见驳回原因
+
+| 类别 | 常见问题 | 改进建议 |
+|------|----------|----------|
+| 结构缺失 | 缺少数据模型或 API 设计 | 补充完整的技术设计章节 |
+| 需求模糊 | 功能描述不够具体 | 按 SMART 原则重新描述 |
+| 边界不清 | 缺少边界条件和异常处理 | 补充边界条件和错误场景 |
+| 设计缺陷 | 数据模型或 API 设计不合理 | 重新设计并说明理由 |
+| 范围过大 | 需求范围过大难以实现 | 拆分为多个小需求 |
+| 验收不明 | 缺少验收标准 | 补充可验证的验收条件 |