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>
2026-03-14 11:31:58 +10:30
parent ea266e9cce
commit 712063071c
170 changed files with 341 additions and 346 deletions
--- a/skills-req/executing-plans-plugin/.claude-plugin/plugin.json
+++ b/skills-req/executing-plans-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "executing-plans-plugin",
+  "description": "Plugin for executing-plans",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/executing-plans-plugin/skills/SKILL.md
+++ b/skills-req/executing-plans-plugin/skills/SKILL.md
@@ -0,0 +1,96 @@
+---
+name: executing-plans
+description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
+---
+
+# Executing Plans
+
+## Overview
+
+Load plan, review critically, create branch, execute tasks in batches, report for review between batches.
+
+**Core principle:** Batch execution with checkpoints for architect review.
+
+**Announce at start:** "I'm using the executing-plans skill to implement this plan."
+
+## The Process
+
+### Step 1: Load and Review Plan
+1. Read plan file
+2. Review critically - identify any questions or concerns about the plan
+3. If concerns: Raise them with your human partner before starting
+4. If no concerns: Proceed to branch setup
+
+### Step 2: Setup Branch
+**Before any implementation, ensure proper branch isolation.**
+
+1. Check if already on a feature branch for this task
+2. If not, use `/pr start` to create one:
+   ```bash
+   /pr start <type> <REQ-id> <name>
+   # Example: /pr start feature REQ-123 user-login
+   ```
+3. If no REQ-id available, ask user or create branch manually:
+   ```bash
+   git fetch origin
+   git checkout -b <type>/<descriptive-name> origin/main
+   ```
+4. Confirm branch is ready before proceeding
+
+**Branch types:** `feature`, `fix`, `refactor`
+
+### Step 3: Create Tasks and Execute Batch
+**Default: First 3 tasks**
+
+1. Create TodoWrite tasks from plan
+2. For each task in batch:
+   - Mark as in_progress
+   - Follow each step exactly (plan has bite-sized steps)
+   - Run verifications as specified
+   - Mark as completed
+
+### Step 4: Report
+When batch complete:
+- Show what was implemented
+- Show verification output
+- Say: "Ready for feedback."
+
+### Step 5: Continue
+Based on feedback:
+- Apply changes if needed
+- Execute next batch
+- Repeat until complete
+
+### Step 6: Complete Development
+
+After all tasks complete and verified:
+- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
+- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
+- Follow that skill to verify tests, present options, execute choice
+
+## When to Stop and Ask for Help
+
+**STOP executing immediately when:**
+- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
+- Plan has critical gaps preventing starting
+- You don't understand an instruction
+- Verification fails repeatedly
+
+**Ask for clarification rather than guessing.**
+
+## When to Revisit Earlier Steps
+
+**Return to Review (Step 1) when:**
+- Partner updates the plan based on your feedback
+- Fundamental approach needs rethinking
+
+**Don't force through blockers** - stop and ask.
+
+## Remember
+- Review plan critically first
+- **Create feature branch before implementation**
+- Follow plan steps exactly
+- Don't skip verifications
+- Reference skills when plan says to
+- Between batches: just report and wait
+- Stop when blocked, don't guess
--- a/skills-req/req-commands-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-commands-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-commands-plugin",
+  "description": "需求命令详细参考。含撰写命令（new/draft/edit/check/split/history/compare）和流程命令（submit/review/phase/next/deploy/done）。",
+  "version": "2.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-commands-plugin/skills/SKILL.md
+++ b/skills-req/req-commands-plugin/skills/SKILL.md
@@ -0,0 +1,436 @@
+---
+name: req-commands
+description: 需求命令详细参考。当需要查看 /req 命令的详细用法、参数、示例时使用。
+---
+
+# req 命令参考
+
+## 基础命令
+
+### `/req` 或 `/req list`
+列出所有需求，按状态分组显示。
+
+### `/req new [标题]`
+创建新需求。
+- 参数：`--priority=high|medium|low`，`--project=<name>`，`--category=feature|bug|improvement`
+- 创建后提示使用 `req-prd` 技能编写 PRD
+
+### `/req status [REQ-ID]`
+查看需求详情、进度、关联任务。
+
+## 阶段管理命令
+
+### `/req phase [REQ-ID]`
+查看需求当前开发阶段和任务状态。
+
+**执行逻辑**：
+1. `get_requirement(id)` → 获取 `delivery_stage`
+2. `get_requirement_tasks(id)` → 获取所有关联任务
+3. 按 linkRole 分组展示，标注当前阶段任务完成度
+
+**输出示例**：
+```
+REQ-20260218-0013 | 阶段: dev (开发)
+────────────────────────────────────
+✅ analysis (评审)
+   ✅ #6035 【评审】PRD: 需求全生命周期阶段化管理
+   ✅ #6040 【评审】技术设计: 数据模型
+▶ dev (开发) ← 当前阶段
+   🔄 #6042 【开发-后端】实现阶段管理 API [in_progress]
+   ⬜ #6043 【开发-前端】阶段可视化组件 [todo]
+⬜ review (代码评审)
+   (无任务)
+⬜ testing (测试)
+   (无任务)
+```
+
+### `/req next [REQ-ID]`
+检测当前阶段完成度，推进到下一阶段。
+
+**执行逻辑**：
+1. 获取当前 `delivery_stage` 和该阶段所有任务
+2. 检查任务完成度：
+   - 全部完成 → 提示「当前阶段已完成，是否推进到 {下一阶段}？」
+   - **部分未完成 → 显示未完成任务列表 + AskUserQuestion**：
+     - 选项 A: "强制推进（需说明原因）"
+     - 选项 B: "返回完成任务"
+     - 用户选 A → 输入跳过原因 → `advance_delivery_stage(force=true)`
+     - 记录到需求历史: `POST /requirements/{id}/history`，comment 包含跳过原因
+   - **⚠️ 禁止 AI 自动使用 force=true，必须经过 AskUserQuestion 确认**
+3. **智能跳阶段检测**（推进前）：
+   - `get_requirement_tasks(id)` → 收集所有 linkRole
+   - 如果目标阶段与当前 linkRole 不匹配，主动建议跳过：
+     - 无 `implementation` → 推进到 review/testing 时提示「该需求无代码任务，建议跳过此阶段」
+     - 无 `code_review` → 推进到 review 时提示跳过
+     - 无 `test` → 推进到 testing 时提示跳过
+   - 通过 AskUserQuestion 确认：「跳过」或「仍然创建任务」
+4. 用户确认推进后：
+   - 更新 `delivery_stage` 到下一阶段
+   - **自动创建**目标阶段的建议任务（`create_stage_task` 批量创建，无需询问）
+   - 展示已创建任务列表：「✅ 已创建: #XXXX 【代码评审】CR: {需求标题}。如需撤销请说明」
+   - ⚠️ 仅当用户主动要求撤销时才删除已创建任务
+
+**阶段顺序**：
+```
+analysis → design → dev → review → testing → [待部署池] → released
+                                                ↑ /req deploy 批量推进
+```
+
+**linkRole 到阶段的映射**：
+| linkRole | 所属阶段 |
+|----------|----------|
+| prd | analysis |
+| design | design |
+| implementation | dev |
+| code_review | review |
+| test | testing |
+| deploy (staging) | staging |
+| deploy (prod) | released |
+
+## 会话恢复命令
+
+### `/req resume [REQ-ID]`
+从上次中断的位置恢复工作。**会话被截断后的首选命令**。
+
+**执行逻辑**：
+1. 若无 REQ-ID → `list_requirements(status=approved)` 找到最近活跃的需求
+2. `get_requirement(id)` → 获取需求基本信息和 `delivery_stage`
+3. `get_requirement_tasks(id)` → 获取所有关联任务及状态
+4. 汇总展示恢复上下文
+
+**输出格式**：
+```
+📋 恢复工作上下文
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+需求: REQ-20260218-0016 | 需求全生命周期 AI 开发管理优化
+状态: approved | 阶段: dev (开发)
+
+📊 任务进度: 2/4 完成
+  ✅ #6051 【开发-后端】实现 advance_delivery_stage MCP 工具
+  ✅ #6052 【开发-后端】实现 create_stage_task 组合 MCP 工具
+  🔄 #6053 【开发-Skill】req-commands 阶段 checklist 模板化 [in_progress]
+  ⬜ #6054 【开发-Skill】会话断点恢复机制 [todo]
+
+▶ 建议操作:
+  1. 继续任务 #6053（当前 in_progress）
+  2. 执行 /req next 推进阶段
+  3. 执行 /req phase 查看完整阶段视图
+```
+
+**自动行为**：
+- 如果有 `in_progress` 任务，提示继续该任务
+- 如果当前阶段所有任务已完成，提示执行 `/req next`
+- 如果需求已 `archived`，告知用户无需操作
+
+## 评审命令
+
+### `/req review [REQ-ID]`
+提交评审。**前置条件**：必须有 PRD 文档。
+
+**评审等待机制（强制）**：
+1. `submit_requirement(id)` → status 变为 pending
+2. 展示 PRD 要点摘要：
+   ```
+   PRD 评审摘要
+   ─────────────────────
+   标题: {需求标题}
+   核心方案: {1-2句总结}
+   验收标准: {N}项
+   改动范围: {文件列表}
+   ```
+3. **AskUserQuestion**: "请确认 PRD 是否通过评审"
+   - "通过评审" → `approve_requirement(id)`
+   - "需要修改" → 回到编辑流程
+4. **⚠️ 禁止 AI 自动审批**，必须等待用户明确选择
+
+### `/req review pass [REQ-ID]`
+评审通过。支持多人审批。参数：`--comment="审批意见"`
+
+### `/req review reject [REQ-ID] [原因]`
+评审驳回。必须提供驳回原因。
+
+### `/req review status [REQ-ID]`
+查看审批进度（多人审批时）。
+
+## 开发命令
+
+### `/req dev [REQ-ID]`
+启动开发，自动选择优先级最高的 todo 任务并开始计时。
+- 参数：`--task=<task-id>` 指定任务
+- 优先启动 `implementation` 角色任务
+- **自动设置** `delivery_stage = dev`（如尚未设置）
+
+### `/req cr [REQ-ID]`
+代码评审。**前置条件**：开发任务完成。
+- 显示 Git diff 摘要
+- 生成代码评审检查清单
+- **自动设置** `delivery_stage = review`
+
+### `/req test [REQ-ID]`
+启动测试。**前置条件**：代码评审通过。
+- 参数：`--skip-cr --reason="原因"` 跳过代码评审
+- **自动设置** `delivery_stage = testing`
+- **⭐ 遵循 `req-test-gate` v2 技能的 5 道门禁**
+
+**执行逻辑（5-Gate 流程，详见 `req-test-gate` 技能）**：
+1. **Gate 1 前置条件**：CR 已通过 + 开发任务全部完成（不可跳过）
+2. **Gate 2 测试执行**：推断需求类型（code/skill/ops），分阶段验证
+   - **code 类型四阶段**：
+     - **2A 静态验证**：编译 + 单元测试 + 条件前端/iOS 测试
+     - **2B 集成验证**：API 端点 + DB 约束 + 错误处理
+     - **2C 冒烟测试**：Staging 环境健康检查 + 核心流程（已部署时）
+     - **2D 原型符合性**：对比原型 HTML 的结构/字段/交互/状态（有原型时）
+   - **skill**: 关键词一致性 + 规则无歧义 + 边界情况（至少 3 项）
+   - **ops**: 部署命令可执行 + 健康检查
+3. **Gate 3 质量验证**：派遣 test-validator 子代理审查测试质量
+   - code 类型：总是触发 | skill 类型：≥5 测试项时触发 | ops 类型：不触发
+   - Critical 缺陷必须修复，Important 缺陷需 AskUserQuestion 确认
+4. **Gate 4 文档持久化（不可跳过）**：`create-and-attach` 将完整测试报告写入测试任务文档
+   - 文档模板见 `req-test-gate` 技能的「最小必填模板」（含 2A-2D 阶段标记）
+   - 必须包含：前置条件结果 + 测试执行表格 + 质量验证摘要 + 通过/失败结论
+   - 无此文档 → `/req deploy` 前置检查会警告
+5. **Gate 5 回归贡献（code 类型）**：检查是否有 linkRole=regression 任务和用例文档
+   - v2.0 过渡期为警告级别，不阻塞
+   - 提醒补充回归测试用例到回归池
+
+### `/req deploy [--project <name>] [--env <environment>]`
+**项目级批量部署**。收集所有待部署需求，一次构建部署。
+
+- **这是项目级动作**，不是单需求操作
+- `--project` 默认为当前项目，`--env` 默认为 `staging`
+- 参数：`--platform=web|ios|android`
+- **⭐ 遵循 `req-test-gate` v2 的 Deploy Gates (DG1-DG6)**
+
+**执行逻辑**：
+1. **前置检查（强制）**：
+   - 对每个待部署需求，检查 testing 阶段任务是否有文档附件（`has_task_document`）
+   - ✅ 有文档 → 继续
+   - ⚠️ 无文档 → AskUserQuestion「测试任务 #XXXX 无测试记录文档，确认继续部署？」
+2. **收集待部署需求**：
+   - `delivery_stage = testing` 且所有 test 任务 completed
+   - 有 implementation 任务（排除纯运维/文档需求）
+3. **展示待部署列表** → `AskUserQuestion` 确认部署范围
+4. **创建部署批次任务**：
+   - 标题：`【部署】{project} {date} ({N} requirements)`
+   - 对每个选中需求：`link_tasks_to_requirement(role=deploy)`
+5. **Deploy Gates (DG1-DG6)**（详见 `req-test-gate/deploy-gates.md`）：
+   - **DG1 迁移检查（不可跳过）**：对比 migrations/ vs 数据库，有新 migration 先备份再执行
+   - **DG2 Staging 部署**：构建镜像 + 部署到 singapore
+   - **DG3 冒烟测试**：健康检查 + 登录 + 新 API 验证
+   - **DG4 影响域回归**：根据 module-deps.json 运行对应回归套件（无套件时跳过）
+   - **DG5 性能基线（推荐）**：关键 API 响应时间检查
+   - **DG6 生产部署（不可跳过）**：部署 + 健康检查，失败立即回滚
+6. **部署后强制检查点**：
+   - ✅ **部署文档创建**（必须）：`create-and-attach` 到部署任务，包含 Deploy Gates 结果表格
+   - ☑️ **截图验证**（可选）：有 chrome-dev MCP → 执行截图；无 → 记录跳过
+7. **部署成功后**：
+   - 所有关联需求 `advance_delivery_stage → released`
+   - `complete_task(部署任务)`
+
+**单需求兼容**：当仅 1 个需求待部署时，流程自动退化为单需求部署。
+
+### `/req done [REQ-ID]`
+完成归档。参数：`--force` 强制归档。
+
+**类型化归档门禁（强制）**：
+
+1. `get_requirement_tasks(id)` → 获取所有关联任务
+2. **推断需求类型**（从 linkRole 集合判断）：
+   - **code**: 有 `implementation` 角色任务 → 代码需求
+   - **skill**: 无 `implementation`，有 `prd`/`code_review`/`test` → Skill/文档需求
+   - **ops**: 仅 `deploy` 角色任务 → 运维需求
+3. **按类型执行检查清单**：
+
+| 检查项 | code | skill | ops |
+|--------|------|-------|-----|
+| delivery_stage = released | ✅ | - | - |
+| delivery_stage >= testing | - | ✅ | - |
+| deploy 任务已完成 | ✅ | - | ✅ |
+| 部署文档存在 | ✅ | - | - |
+| 所有关联任务已完成 | ✅ | ✅ | ✅ |
+
+4. **检查结果处理**：
+   - 全部通过 → 展示检查清单 + AskUserQuestion "确认归档？"
+   - 有缺失 → 显示缺失项 + AskUserQuestion "是否强制归档？"
+   - 用户确认 → 进入步骤 5
+5. **Git 提交（强制）**：
+   - `git add` 本需求相关变更文件
+   - `git commit -m "feat(skill): REQ-XXXX 需求标题"`（或 `fix`/`refactor` 等合适的 type）
+   - `git push origin <current-branch>`
+   - ⚠️ 提交前确认无敏感文件（.env、credentials 等）
+6. `archive_requirement(id)`
+7. 归档后生成生命周期总结，触发同步
+
+### `/req regression [--module <name>] [--mode <mode>]`
+**运行回归测试**。系统级持续质量活动。
+
+- `--module` 指定模块（okr/task/auth/...），不指定则按影响域推断
+- `--mode` 执行模式：`impact`（影响域）| `critical`（关键路径）| `full`（全量）
+- 默认模式：`impact`（根据最近变更推断影响域）
+
+**执行逻辑**（详见 `req-test-gate/regression.md`）：
+1. **确定范围**：
+   - 指定 module → 直接运行该模块回归套件
+   - 未指定 → `git diff --name-only` 获取变更 → 查 `module-deps.json` → 推断影响域
+2. **运行回归套件**：
+   - 执行 `regression-suite/suites/` 下对应脚本
+   - 记录每个用例的 PASS/FAIL 状态
+3. **回归判定**：
+   - 对比上次运行结果
+   - 上次 PASS + 本次 FAIL → 标记为「回归」
+4. **结果处理**：
+   - 全部通过 → 展示通过率
+   - 有回归 → AskUserQuestion「是否为回归项创建 bug 需求？」
+   - 有新失败 → 展示失败列表，建议排查
+5. **报告输出**：
+   ```
+   回归测试结果 - {module/all}
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   模式: {impact/critical/full}
+   套件: {N} 个 | 用例: {M} 个
+   ✅ 通过: {P} | ❌ 失败: {F} | 🔴 回归: {R}
+   ```
+
+**当前状态**：回归套件待初始化，首次运行会提示建立基线。
+
+## 辅助命令
+
+### `/req link [REQ-ID] --task-id [TASK-ID]`
+关联任务到需求。
+
+### `/req decompose [REQ-ID]`
+分解需求为任务。**创建时自动加阶段前缀**。
+
+### `/req generate-tasks [REQ-ID]`
+根据 PRD 自动生成开发任务。**所有任务带【开发】前缀**。
+
+### `/req priority [REQ-ID] [low|medium|high]`
+设置需求优先级。
+
+### `/req stats [REQ-ID|--all]`
+查看需求统计信息。
+
+## 阶段任务 Checklist 模板
+
+当 `/req next` 推进到新阶段时，根据目标阶段自动建议创建的任务。使用 `create_stage_task` 组合工具一步完成（创建+关联+可选启动）。
+
+### analysis（评审）
+```
+☐ 【评审】PRD: {需求标题}          (linkRole: prd)
+☐ 【评审】技术设计: {需求标题}      (linkRole: design) [可选]
+```
+
+### design（设计）
+```
+☐ 【设计】技术方案: {需求标题}      (linkRole: design)
+☐ 【设计】数据模型设计              (linkRole: design) [可选]
+```
+
+### dev（开发）
+```
+☐ 【开发-后端】{需求标题}           (linkRole: implementation)
+☐ 【开发-前端】{需求标题}           (linkRole: implementation) [可选]
+☐ 【开发-MCP】{需求标题}            (linkRole: implementation) [可选]
+```
+
+### review（代码评审）
+```
+☐ 【代码评审】{需求标题}            (linkRole: code_review)
+```
+
+### testing（测试）
+```
+☐ 【测试】单元测试: {需求标题}       (linkRole: test)
+☐ 【测试】集成测试: {需求标题}       (linkRole: test) [可选]
+```
+
+**按需求类型的最低测试标准**：
+
+| 需求类型 | 最低测试要求 |
+|----------|-------------|
+| **code** | `go test` 或前端测试通过 + API 验证 + 截图验证 |
+| **skill** | 关键词跨文件一致性 + 规则无歧义验证 + 边界情况检查（至少 3 项） |
+| **ops** | 部署命令可执行 + 健康检查通过 |
+
+**skill 类型测试 checklist**（最低 3 项）：
+```
+☐ 关键词一致性：grep 验证核心概念在所有相关 skill 文件中对齐
+☐ 规则无歧义：每条规则的触发条件和执行动作明确，无二义性
+☐ 边界情况：至少验证 1 个边界场景（如混合类型需求的分类）
+☐ 交叉引用：文件间的引用（如"见 xxx 技能"）指向正确 [可选]
+```
+
+### 部署（项目级，由 `/req deploy` 触发）
+
+部署不再按单需求创建任务，而是通过 `/req deploy` 批量收集待部署需求：
+```
+testing 完成的需求 → 进入「待部署池」
+/req deploy → 创建批次任务：【部署】{project} {date} ({N} requirements)
+              关联到所有选中需求 (linkRole: deploy)
+              部署成功后批量推进 → released
+```
+
+### `/req next` 执行流程（更新版）
+
+1. `get_requirement(id)` → 获取 `delivery_stage`
+2. `get_requirement_tasks(id)` → 获取关联任务，收集 linkRole 集合
+3. **智能跳阶段检测**：检查目标阶段是否与 linkRole 匹配
+   - 不匹配 → AskUserQuestion「建议跳过 {阶段}，是否同意？」
+   - 用户同意跳过 → 递归检测下一阶段
+   - 用户拒绝 → 继续推进到该阶段
+4. **门禁检查**：`advance_delivery_stage(id, nextStage)` 自动检查
+   - 通过 → 进入步骤 4.5
+   - 未通过 → 显示阻塞任务，AskUserQuestion 确认 force（禁止自动 force）
+4.5. **⭐ 内容门禁检查（防空转）**：对关键阶段的已完成任务验证文档附件
+   - **适用阶段**: review（CR 报告）、testing（测试结果）、staging（部署文档）
+   - **检查逻辑**：
+     ```
+     对当前阶段的每个 completed 任务:
+       has_task_document(taskId) → 有文档？
+         ✅ 有 → get_task_document(taskId) → 检查质量:
+           - review: ≥500字符 + 含 file:line 代码引用 + 含结论章节
+           - testing: 含测试项表格 + 含通过/失败结论 + ≥200字符
+                      （详见 req-test-gate 技能 Gate 4 文档质量门禁）
+           - staging: 含健康检查结果 + 含镜像/commit 信息
+         ❌ 无 → 阻止推进，提示「任务 #XXXX 缺少 {类型} 文档」
+     ```
+   - **未通过处理**：AskUserQuestion「内容门禁未通过，选择操作」
+     - 选项 A: "补充文档后重试"
+     - 选项 B: "强制跳过（记录原因）" → 记录跳过原因到需求历史
+   - **⚠️ 禁止 AI 自动跳过**，必须经过 AskUserQuestion
+5. **自动创建阶段任务**：`create_stage_task` 批量创建目标阶段建议任务
+   - 展示已创建列表：「✅ 已创建: #XXXX {任务名}。如需撤销请说明」
+   - 用户主动要求撤销时才删除
+
+## MCP 工具映射
+
+| 命令 | MCP 工具 |
+|------|----------|
+| `/req` | `list_requirements` |
+| `/req new` | `create_requirement` |
+| `/req phase` | `get_requirement` + `get_requirement_tasks` |
+| `/req next` | `advance_delivery_stage` (门禁检查+推进) + `create_stage_task` (创建任务) |
+| `/req resume` | `get_requirement` + `get_requirement_tasks` (断点恢复) |
+| `/req dev` | `get_requirement` + `get_requirement_tasks` + `start_task_with_timer` |
+| `/req cr` | `get_requirement_tasks` + Git diff |
+| `/req test` | `req-test-gate` v2 5-Gate 流程: 前置检查 → 类型化测试(2A-2D) → test-validator 子代理 → `create-and-attach` 持久化 → 回归贡献检查 |
+| `/req deploy` | 前置检查 + Deploy Gates(DG1-DG6): 迁移→staging→冒烟→回归→性能→生产 + 部署文档 |
+| `/req regression` | `git diff` 影响域推断 + 运行回归套件 + 回归判定 + 可选创建 bug 需求 |
+| `/req done` | 类型推断 + 检查清单 + `AskUserQuestion` + `archive_requirement`（⚠️ 禁止直接调用 archive） |
+| `/req review` | `submit_requirement` |
+| `/req review pass` | `approve_requirement` |
+| `/req review reject` | `reject_requirement` |
+| `/req link` | `link_tasks_to_requirement` |
+
+## 任务关联类型
+
+| link_role | 说明 | 阶段前缀 | 进度权重 |
+|-----------|------|----------|----------|
+| prd | PRD 文档 | 【评审】 | 0.1 |
+| design | 技术设计 | 【评审】 | 0.05 |
+| implementation | 开发实现 | 【开发】 | 0.5 |
+| code_review | 代码评审 | 【代码评审】 | 0.05 |
+| test | 测试验证 | 【测试】 | 0.15 |
+| deploy | 部署发布 | 【部署】 | 0.1 |
+| regression | 回归用例 | 【回归】 | 0.0 |
+| documentation | 文档编写 | 【文档】 | 0.05 |
--- a/skills-req/req-deploy-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-deploy-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-deploy-plugin",
+  "description": "Plugin for req-deploy",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-deploy-plugin/skill.json
+++ b/skills-req/req-deploy-plugin/skill.json
@@ -0,0 +1,18 @@
+{
+  "name": "req-deploy",
+  "version": "1.0.0",
+  "description": "需求部署技能。用于 Docker 镜像构建、Staging/Production 环境部署、API 验证、前端截图验证、部署文档创建。当用户执行 /req deploy 或需要部署需求时自动激活。",
+  "triggerPatterns": [
+    "部署",
+    "deploy",
+    "staging",
+    "production",
+    "镜像构建",
+    "docker build",
+    "Jenkins",
+    "生产环境",
+    "预发布"
+  ],
+  "autoActivate": false,
+  "hidden": false
+}
--- a/skills-req/req-deploy-plugin/skills/SKILL.md
+++ b/skills-req/req-deploy-plugin/skills/SKILL.md
--- a/skills-req/req-dev-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-dev-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-dev-plugin",
+  "description": "Plugin for req-dev",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-dev-plugin/README.md
+++ b/skills-req/req-dev-plugin/README.md
@@ -0,0 +1,193 @@
+# req-dev Skill
+
+需求开发计划编写技能 - 从 PRD 到代码实现的桥梁
+
+## 快速开始
+
+### 使用方式
+
+```bash
+# 方式1: 通过 req 命令调用（推荐）
+/req doc REQ-20260126-0008
+
+# 方式2: 直接调用 skill
+/req-dev REQ-20260126-0008
+```
+
+## 核心功能
+
+### 1. PRD 分析
+- 自动提取功能点和技术要求
+- 识别改动范围（前端/后端/数据库）
+
+### 2. 代码库智能探索
+- 使用 Task(Explore) 搜索相关代码
+- 定位需要修改的文件
+- 分析现有实现模式
+
+### 3. 分层架构引导
+
+**Go 后端**：
+```
+Model → Repository → Service → Handler → Route → Migration
+```
+
+**React 前端**：
+```
+Types → Services → Components → Pages → Router
+```
+
+### 4. 自动任务拆分
+- 根据修改文件自动拆分子任务
+- 每个子任务对应一个模块或文件
+- 使用 `mcp__ai-proj__create_subtask` 创建
+
+### 5. 完整开发文档
+生成包含以下内容的开发计划：
+- 需求概述
+- 代码库分析
+- 技术方案设计
+- 开发任务拆分
+- 实施顺序
+- 技术风险评估
+- 测试策略
+
+## 输出示例
+
+```markdown
+# [需求标题] 开发计划
+
+## 1. 需求概述
+- 需求编号：REQ-20260126-0008
+- 功能点清单
+- 技术要求
+
+## 2. 代码库分析
+| 文件 | 层级 | 是否修改 | 改动类型 |
+|------|------|----------|---------|
+| backend/models/manual.go | Model | ❌ 无需修改 | - |
+| backend/handlers/manual_handler.go | Handler | ✅ 需修改 | 新增接口 |
+| frontend/src/pages/ManualListPage.tsx | Page | ✅ 需修改 | 新增功能 |
+
+## 3. 技术方案设计
+### 3.1 后端改动（Go）
+- Model 层：数据结构
+- Repository 层：数据访问
+- Service 层：业务逻辑
+- Handler 层：HTTP 处理
+- Route 层：路由注册
+
+### 3.2 前端改动（React）
+- Types：类型定义
+- Services：API 服务
+- Components：组件开发
+- Pages：页面修改
+
+## 4. 开发任务拆分
+├── [Model] 修改 manual.go
+├── [Handler] 修改 manual_handler.go
+├── [Page] 修改 ManualListPage.tsx
+└── [Test] 添加单元测试
+
+## 5. 技术风险评估
+...
+```
+
+## 与其他技能的配合
+
+| 技能 | 使用场景 | 配合方式 |
+|------|----------|---------|
+| req-prd | PRD 编写 | req-dev 基于 req-prd 生成的 PRD 进行分析 |
+| dev-arch | 系统架构设计 | 大重构时先用 dev-arch 设计，再用 req-dev 实施 |
+| dev-coding | 编码实现 | req-dev 生成计划后，dev-coding 执行编码 |
+| dev-test | 测试 | req-dev 生成测试策略，dev-test 执行测试 |
+
+## 工作流程
+
+```
+1. 获取需求信息（PRD 文档、关联任务）
+   ↓
+2. 分析 PRD，提取功能点
+   ↓
+3. 探索代码库（Task Explore）
+   ↓
+4. 生成技术方案（分层架构）
+   ↓
+5. 拆分开发子任务
+   ↓
+6. 生成开发计划文档
+   ↓
+7. 评估技术风险
+```
+
+## 最佳实践
+
+### 1. 充分探索代码库
+- 先精确搜索，再模糊搜索
+- 识别可复用的代码模式
+- 分析现有依赖关系
+
+### 2. 合理拆分任务
+- 按 2-4 小时粒度拆分
+- 每个任务对应一个文件或模块
+- 遵循 SMART 原则
+
+### 3. 评估技术风险
+- 数据库影响（Migration、索引）
+- API 兼容性（版本管理）
+- 性能影响（查询复杂度、缓存）
+- 业务风险（核心流程、回退方案）
+
+### 4. 按分层架构开发
+- 后端：Model → Repository → Service → Handler → Route
+- 前端：Types → Services → Components → Pages
+- 先下层，后上层（依赖关系）
+
+## 常见问题
+
+### Q: req-dev 和 dev-arch 有什么区别？
+**A**:
+- **dev-arch**：系统级架构设计（新系统、大重构）
+- **req-dev**：功能级实现规划（需求开发、小改动）
+
+### Q: 什么时候需要创建子任务？
+**A**:
+- 需要修改 3 个以上文件
+- 预估总工时 > 4 小时
+- 涉及多个层级（Model + Service + Handler）
+
+### Q: 如何确保开发文档质量？
+**A**:
+- 基于真实代码探索（不猜测）
+- 提供具体文件路径和代码示例
+- 评估技术风险和性能影响
+- 给出清晰的实施顺序
+
+## 技术栈支持
+
+### 后端
+- ✅ Go + Gin + GORM（ai-proj 项目）
+- ⚠️ 其他技术栈需要调整分层架构
+
+### 前端
+- ✅ React + TypeScript + Ant Design（ai-proj 项目）
+- ⚠️ 其他技术栈需要调整目录结构
+
+### 数据库
+- ✅ PostgreSQL + Migration（ai-proj 项目）
+
+## 更新日志
+
+- **V1.0** (2026-01-26): 初始版本
+  - 支持 Go 后端分层架构
+  - 支持 React 前端架构
+  - 自动任务拆分
+  - 代码库智能探索
+  - 技术风险评估
+
+## 相关文档
+
+- [SKILL.md](./SKILL.md) - 完整技能文档
+- [req SKILL.md](../req/SKILL.md) - 需求管理流程
+- [req-prd SKILL.md](../req-prd/SKILL.md) - PRD 编写
+- [CLAUDE.md](../../../CLAUDE.md) - 项目说明
--- a/skills-req/req-dev-plugin/skills/SKILL.md
+++ b/skills-req/req-dev-plugin/skills/SKILL.md
--- a/skills-req/req-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-plugin",
+  "description": "需求工作流管理入口。用于 /req 命令使用、需求生命周期管理、需求撰写（含草稿门禁）。",
+  "version": "2.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-plugin/README.md
+++ b/skills-req/req-plugin/README.md
@@ -0,0 +1,111 @@
+# req - 需求全流程工作流管理技能
+
+> 版本: v3.9.0 | 更新日期: 2026-01-25
+
+## 概述
+
+`req` 技能是一个深度集成 ai-proj MCP 工具的需求管理解决方案，支持需求全生命周期管理：从创建、评审、开发、测试到发布归档。
+
+## 快速开始
+
+```bash
+# 列出待处理需求
+/req list
+
+# 创建新需求
+/req new 商品管理模块
+
+# 开始开发
+/req dev REQ-2026-0001
+
+# 提交评审
+/req review REQ-2026-0001
+
+# 归档完成
+/req done REQ-2026-0001
+```
+
+## 核心命令
+
+| 命令 | 功能 |
+|------|------|
+| `/req` 或 `/req list` | 列出需求 |
+| `/req new [标题]` | 创建新需求 |
+| `/req dev [REQ-ID]` | 开始开发 |
+| `/req test [REQ-ID]` | 执行测试 |
+| `/req review [REQ-ID]` | 提交评审 |
+| `/req done [REQ-ID]` | 归档需求 |
+| `/req status [REQ-ID]` | 查看状态 |
+
+## 扩展命令 (v3.3.0+)
+
+| 命令 | 功能 |
+|------|------|
+| `/req priority [REQ-ID] [high/medium/low]` | 设置优先级 |
+| `/req depends [REQ-ID] --on [REQ-ID]` | 设置依赖 |
+| `/req deadline [REQ-ID] [日期]` | 设置截止日期 |
+| `/req sprint [REQ-ID] [sprint-id]` | 分配迭代 |
+| `/req assign [REQ-ID] [用户]` | 指派负责人 |
+| `/req generate-tasks [REQ-ID]` | 自动生成任务 |
+| `/req stats [REQ-ID]` | 查看统计 |
+
+## Hook 自动同步 (v3.5.0+)
+
+支持在以下事件自动触发同步：
+- `requirement.created` - 创建需求
+- `requirement.approved` - 需求审批通过
+- `requirement.archived` - 需求归档
+- `task.completed` - 任务完成
+- `document.updated` - 文档更新
+
+## 多人审批 (v3.7.0+)
+
+```bash
+/req review pass REQ-2026-0001    # 审批通过
+/req review reject REQ-2026-0001  # 审批拒绝
+/req review status REQ-2026-0001  # 查看审批状态
+```
+
+## 需求状态流转
+
+```
+draft → pending → reviewing → approved → archived
+                     ↓
+                  rejected
+```
+
+## 文件结构
+
+```
+~/.claude/skills/req/
+├── SKILL.md              # 完整技能文档
+├── README.md             # 本文件
+├── notify.sh             # 邮件通知脚本
+└── update-siyuan-release.sh  # 思源笔记更新脚本
+```
+
+## 依赖
+
+- **ai-proj MCP 服务** - 需求、任务、文档管理
+- **思源笔记 MCP** - 文档同步（可选）
+- **邮件服务** - 通知功能（可选）
+
+## 详细文档
+
+完整命令说明、配置选项和使用示例请参阅 [SKILL.md](./SKILL.md)。
+
+## 版本历史
+
+| 版本 | 日期 | 主要变更 |
+|------|------|----------|
+| v3.9.0 | 2026-01-25 | 生产环境截图验证必须步骤 |
+| v3.8.0 | 2026-01-13 | 废弃命令文档化 |
+| v3.7.0 | 2026-01-13 | 多人审批增强 |
+| v3.6.0 | 2026-01-13 | new/dev/done 命令增强 |
+| v3.5.0 | 2026-01-13 | Hook 自动同步机制 |
+| v3.4.0 | 2026-01-13 | generate-tasks, stats 命令 |
+| v3.3.0 | 2026-01-13 | priority/depends/deadline/sprint/assign 命令 |
+
+---
+
+*由 Claude AI 维护*
--- a/skills-req/req-plugin/code-review-guide.md
+++ b/skills-req/req-plugin/code-review-guide.md
@@ -0,0 +1,115 @@
+# 代码评审指南 (Code Review Guide)
+
+代码评审是测试阶段的前置条件，确保代码质量在测试前得到验证。
+
+## 评审时机
+
+```
+开发完成 → 代码评审 → 测试
+    ↑          ↓
+    └── 发现问题，修复后重新评审
+```
+
+## 评审检查清单
+
+### 1. 代码风格
+- [ ] 符合项目编码规范（Go/TypeScript）
+- [ ] 命名清晰有意义
+- [ ] 代码格式统一（已运行 lint/format）
+
+### 2. 安全性
+- [ ] 无 SQL 注入风险
+- [ ] 无 XSS 漏洞
+- [ ] 无敏感信息硬编码（密码、密钥）
+- [ ] 权限检查完善
+
+### 3. 错误处理
+- [ ] 异常捕获完善
+- [ ] 错误信息友好（不暴露内部细节）
+- [ ] 边界条件处理
+
+### 4. 性能
+- [ ] 无 N+1 查询
+- [ ] 无不必要的循环/递归
+- [ ] 大数据量有分页处理
+
+### 5. 日志与监控
+- [ ] 关键操作有日志
+- [ ] 日志级别适当
+- [ ] 无敏感信息输出到日志
+
+### 6. 测试覆盖
+- [ ] 关键逻辑有单元测试
+- [ ] 测试用例有效
+
+### 7. 文档
+- [ ] 复杂逻辑有注释
+- [ ] API 有文档说明
+
+## 评审方式
+
+| 方式 | 适用场景 |
+|------|----------|
+| 自评 (Self Review) | AI 开发的代码，Claude 自动检查 |
+| 他人评审 (Peer Review) | 团队协作，提交 PR 等待评审 |
+| 结对评审 (Pair Review) | 复杂功能，实时讨论 |
+
+## 执行流程
+
+### `/req cr` 命令执行步骤
+
+1. **验证开发完成**
+   ```
+   检查所有 implementation 任务状态 = completed
+   ```
+
+2. **生成变更摘要**
+   ```bash
+   git diff --stat HEAD~N  # N = 开发期间的提交数
+   git diff --name-only HEAD~N
+   ```
+
+3. **显示检查清单**
+   - 输出上述检查清单
+   - 逐项确认或标记问题
+
+4. **记录评审结果**
+   - 通过：创建 code_review 任务并标记 completed
+   - 不通过：列出问题，等待修复后重新评审
+
+## 常见问题
+
+### Go 后端
+- 未检查 `error` 返回值
+- 缺少 `defer` 关闭资源
+- 并发访问未加锁
+
+### TypeScript 前端
+- `any` 类型滥用
+- 缺少空值检查
+- 未处理异步错误
+
+### 数据库
+- 缺少索引
+- 大事务未拆分
+- 未考虑并发更新
+
+## 评审不通过时
+
+```
+/req cr REQ-XXXX
+
+→ 发现问题:
+  ⚠️ handlers/task_handler.go:245 - 缺少错误处理
+  ⚠️ pages/TaskList.tsx:88 - 存在 XSS 风险
+
+→ 请修复后重新执行 /req cr
+```
+
+## 跳过评审（紧急情况）
+
+```bash
+/req test REQ-XXXX --skip-cr --reason="紧急生产修复"
+```
+
+> 跳过评审需记录原因，事后补充评审。
--- a/skills-req/req-plugin/deploy-guide.md
+++ b/skills-req/req-plugin/deploy-guide.md
@@ -0,0 +1,273 @@
+# 部署指南
+
+## 部署流程概览
+
+```
+Staging 部署（手动）          Production 部署（Jenkins）
+       ↓                              ↓
+本地构建 :test 镜像            本地构建 :latest 镜像
+       ↓                              ↓
+推送到 DockerHub               推送到 DockerHub
+       ↓                              ↓
+显示部署命令                   调用 Jenkins API
+       ↓                              ↓
+用户手动执行                   自动触发部署
+       ↓                              ↓
+验证 API                       轮询构建状态
+                                      ↓
+                               验证 API
+```
+
+## 环境说明
+
+| 环境 | 触发方式 | 镜像标签 | 用途 |
+|------|----------|----------|------|
+| staging | 手动 SSH | `:test` | 预发布测试 |
+| production | Jenkins API | `:latest` | 正式生产 |
+
+## 镜像构建规范
+
+> ⚠️ **重要**: 必须理解 Dockerfile target 和镜像标签的区别
+
+### Dockerfile Target vs 镜像标签
+
+| 概念 | 说明 | 示例 |
+|------|------|------|
+| **Dockerfile Target** | 构建阶段，决定镜像内容 | `--target production`, `--target test` |
+| **镜像标签** | 版本标识，决定部署环境 | `:test`, `:latest` |
+
+### 正确的构建方式
+
+| 用途 | Dockerfile Target | 镜像标签 | 镜像大小 |
+|------|-------------------|----------|----------|
+| **Staging 部署** | `--target production` | `:test` | ~50MB |
+| **Production 部署** | `--target production` | `:latest` | ~50MB |
+| **运行单元测试** | `--target test` | 无需推送 | ~900MB+ |
+
+### 常见错误
+
+❌ **错误做法**：用 `--target test` 构建部署镜像
+```bash
+# 错误！这会生成 900MB+ 的镜像，包含测试框架和源代码
+docker buildx build --target test -t xxx:test ...
+```
+
+✅ **正确做法**：用 `--target production` 构建部署镜像
+```bash
+# 正确！生成 ~50MB 的精简镜像，只包含二进制文件
+docker buildx build --target production -t xxx:test ...
+```
+
+### Staging vs Production 镜像区别
+
+两者都使用 `--target production` 构建，区别在于：
+
+| 区别点 | Staging (`:test`) | Production (`:latest`) |
+|--------|-------------------|------------------------|
+| 镜像标签 | `:test` | `:latest` |
+| 前端 API URL | `staging.ai.pipexerp.com` | `ai.pipexerp.com` |
+| 后端代码 | 完全相同 | 完全相同 |
+| 部署服务器 | singapore | tools_ai_proj |
+
+> **注意**: 不是把 staging 镜像部署到生产，而是测试通过后用生产 URL **重新构建** `:latest` 镜像
+
+## Staging 部署
+
+### 前置条件
+
+> ⚠️ **必须完成本机测试才能部署 staging**
+
+| 检查项 | 说明 |
+|--------|------|
+| 代码评审 | `/req cr` 已完成 |
+| 后端单元测试 | `go test ./... -v` 全部通过 |
+| **前端截图验证** | 使用 chrome-dev MCP 截图确认 UI 正确显示 |
+
+如果本机测试未通过，将拒绝部署并提示：
+```
+→ ❌ 本机测试未完成，禁止部署到 staging
+→ 请先执行: /req test REQ-XXX
+```
+
+### 命令格式
+
+```bash
+/req deploy REQ-XXX --env staging [--service <service>]
+```
+
+### 支持的服务
+
+| 服务 | 说明 |
+|------|------|
+| `backend` | 后端 API 服务 |
+| `frontend` | 前端 Web 应用 |
+| `all` | 全部服务（默认） |
+
+### 执行流程
+
+1. **构建镜像**（本地执行）
+   ```bash
+   # 后端
+   docker buildx build --platform linux/amd64 \
+     -f backend/Dockerfile --target production \
+     -t saltthing123/ai-proj-backend:test --push backend/
+
+   # 前端（注意 API URL 配置）
+   docker buildx build --platform linux/amd64 \
+     -f frontend/Dockerfile.prod --target production \
+     --build-arg REACT_APP_API_URL=https://staging.ai.pipexerp.com/api/v1 \
+     --build-arg REACT_APP_API_BASE_URL=https://staging.ai.pipexerp.com/api/v1 \
+     -t saltthing123/ai-proj-frontend:test --push frontend/
+   ```
+
+2. **部署命令**（用户手动执行）
+   ```bash
+   ssh singapore "cd /opt/ai-project-staging && \
+     sudo docker-compose pull && \
+     sudo docker-compose up -d"
+   ```
+
+3. **验证**
+   ```bash
+   curl -s https://staging.ai.pipexerp.com/api/v1/health | jq .
+   ```
+
+## Production 部署
+
+### 命令格式
+
+```bash
+/req deploy REQ-XXX --env production [--service <service>]
+```
+
+### 支持的服务
+
+| 服务 | 镜像名 | Jenkins 参数 |
+|------|--------|--------------|
+| `backend` | saltthing123/ai-proj-backend | SERVICE=backend |
+| `frontend` | saltthing123/ai-proj-frontend | SERVICE=frontend |
+| `ios` | - | SERVICE=ios |
+| `android` | - | SERVICE=android |
+| `all` | 全部 | SERVICE=all（默认） |
+
+### 执行流程
+
+1. **构建镜像**（本地执行）
+   ```bash
+   # 后端
+   docker buildx build --platform linux/amd64 \
+     -f backend/Dockerfile --target production \
+     -t saltthing123/ai-proj-backend:latest --push backend/
+
+   # 前端
+   docker buildx build --platform linux/amd64 \
+     -f frontend/Dockerfile.prod --target production \
+     --build-arg REACT_APP_API_URL=https://ai.pipexerp.com/api/v1 \
+     --build-arg REACT_APP_API_BASE_URL=https://ai.pipexerp.com/api/v1 \
+     -t saltthing123/ai-proj-frontend:latest --push frontend/
+   ```
+
+2. **触发 Jenkins 部署**
+   ```bash
+   source ~/.config/devops/credentials.env
+   curl -X POST "$JENKINS_URL/job/ai-proj/buildWithParameters" \
+     -u "$JENKINS_USER:$JENKINS_TOKEN" \
+     --data "SERVICE=backend&IMAGE_TAG=latest"
+   ```
+
+3. **查看构建状态**
+   ```bash
+   source ~/.config/devops/credentials.env
+   curl -s "$JENKINS_URL/job/ai-proj/lastBuild/api/json" \
+     -u "$JENKINS_USER:$JENKINS_TOKEN" | jq '.result, .building'
+   ```
+
+4. **验证**
+   ```bash
+   curl -s https://ai.pipexerp.com/api/v1/health | jq .
+   ```
+
+## 安全约束
+
+- **禁止自动 SSH 部署到生产服务器**
+- 生产环境部署必须通过 Jenkins API 触发
+- Staging 部署命令只显示，由用户手动执行
+- 构建失败时必须显示错误原因和解决方案
+
+## 项目配置
+
+### AI-Proj
+
+| 配置项 | 值 |
+|--------|-----|
+| Jenkins Job | ai-proj |
+| Staging 服务器 | singapore |
+| Production 服务器 | tools_ai_proj |
+| DockerHub 用户 | saltthing123 |
+
+### Coolbuy-Paas
+
+| 配置项 | 值 |
+|--------|-----|
+| Jenkins Job | coolbuy-paas |
+| Staging 服务器 | fnos 测试环境 |
+| Production 服务器 | 39.106.88.83 |
+| DockerHub 用户 | saltthing123 |
+
+## 常见问题
+
+### Docker 推送失败
+
+**错误**: `push access denied`
+
+**解决**:
+```bash
+docker login
+# 输入 Docker Hub 凭据
+```
+
+### Jenkins 构建失败
+
+**查看日志**:
+```bash
+source ~/.config/devops/credentials.env
+curl -s "$JENKINS_URL/job/ai-proj/lastBuild/consoleText" \
+  -u "$JENKINS_USER:$JENKINS_TOKEN" | tail -100
+```
+
+### 镜像架构不匹配
+
+**错误**: `exec format error`
+
+**原因**: 在 ARM64 (M1/M2 Mac) 构建的镜像部署到 AMD64 服务器
+
+**解决**: 构建时必须指定 `--platform linux/amd64`
+
+### 镜像体积异常大（900MB+）
+
+**错误**: 构建的镜像超过 100MB
+
+**原因**: 使用了错误的 Dockerfile target
+
+**检查**:
+```bash
+# 查看镜像层大小
+docker history <image>:<tag> --no-trunc --format "{{.Size}}\t{{.CreatedBy}}" | head -10
+```
+
+**常见原因**:
+| 层内容 | 大小 | 说明 |
+|--------|------|------|
+| `go mod download` | 600MB+ | Go 依赖包（不应出现在生产镜像） |
+| `ginkgo/gomega` | 200MB+ | 测试框架（不应出现在生产镜像） |
+| `COPY . .` | 100MB+ | 源代码（不应出现在生产镜像） |
+
+**解决**: 确保使用 `--target production` 而不是 `--target test`
+
+```bash
+# 错误
+docker buildx build --target test ...
+
+# 正确
+docker buildx build --target production ...
+```
--- a/skills-req/req-plugin/docs/code-review-guide.md
+++ b/skills-req/req-plugin/docs/code-review-guide.md
@@ -0,0 +1,115 @@
+# 代码评审指南 (Code Review Guide)
+
+代码评审是测试阶段的前置条件，确保代码质量在测试前得到验证。
+
+## 评审时机
+
+```
+开发完成 → 代码评审 → 测试
+    ↑          ↓
+    └── 发现问题，修复后重新评审
+```
+
+## 评审检查清单
+
+### 1. 代码风格
+- [ ] 符合项目编码规范（Go/TypeScript）
+- [ ] 命名清晰有意义
+- [ ] 代码格式统一（已运行 lint/format）
+
+### 2. 安全性
+- [ ] 无 SQL 注入风险
+- [ ] 无 XSS 漏洞
+- [ ] 无敏感信息硬编码（密码、密钥）
+- [ ] 权限检查完善
+
+### 3. 错误处理
+- [ ] 异常捕获完善
+- [ ] 错误信息友好（不暴露内部细节）
+- [ ] 边界条件处理
+
+### 4. 性能
+- [ ] 无 N+1 查询
+- [ ] 无不必要的循环/递归
+- [ ] 大数据量有分页处理
+
+### 5. 日志与监控
+- [ ] 关键操作有日志
+- [ ] 日志级别适当
+- [ ] 无敏感信息输出到日志
+
+### 6. 测试覆盖
+- [ ] 关键逻辑有单元测试
+- [ ] 测试用例有效
+
+### 7. 文档
+- [ ] 复杂逻辑有注释
+- [ ] API 有文档说明
+
+## 评审方式
+
+| 方式 | 适用场景 |
+|------|----------|
+| 自评 (Self Review) | AI 开发的代码，Claude 自动检查 |
+| 他人评审 (Peer Review) | 团队协作，提交 PR 等待评审 |
+| 结对评审 (Pair Review) | 复杂功能，实时讨论 |
+
+## 执行流程
+
+### `/req cr` 命令执行步骤
+
+1. **验证开发完成**
+   ```
+   检查所有 implementation 任务状态 = completed
+   ```
+
+2. **生成变更摘要**
+   ```bash
+   git diff --stat HEAD~N  # N = 开发期间的提交数
+   git diff --name-only HEAD~N
+   ```
+
+3. **显示检查清单**
+   - 输出上述检查清单
+   - 逐项确认或标记问题
+
+4. **记录评审结果**
+   - 通过：创建 code_review 任务并标记 completed
+   - 不通过：列出问题，等待修复后重新评审
+
+## 常见问题
+
+### Go 后端
+- 未检查 `error` 返回值
+- 缺少 `defer` 关闭资源
+- 并发访问未加锁
+
+### TypeScript 前端
+- `any` 类型滥用
+- 缺少空值检查
+- 未处理异步错误
+
+### 数据库
+- 缺少索引
+- 大事务未拆分
+- 未考虑并发更新
+
+## 评审不通过时
+
+```
+/req cr REQ-XXXX
+
+→ 发现问题:
+  ⚠️ handlers/task_handler.go:245 - 缺少错误处理
+  ⚠️ pages/TaskList.tsx:88 - 存在 XSS 风险
+
+→ 请修复后重新执行 /req cr
+```
+
+## 跳过评审（紧急情况）
+
+```bash
+/req test REQ-XXXX --skip-cr --reason="紧急生产修复"
+```
+
+> 跳过评审需记录原因，事后补充评审。
--- a/skills-req/req-plugin/docs/deploy-guide.md
+++ b/skills-req/req-plugin/docs/deploy-guide.md
@@ -0,0 +1,273 @@
+# 部署指南
+
+## 部署流程概览
+
+```
+Staging 部署（手动）          Production 部署（Jenkins）
+       ↓                              ↓
+本地构建 :test 镜像            本地构建 :latest 镜像
+       ↓                              ↓
+推送到 DockerHub               推送到 DockerHub
+       ↓                              ↓
+显示部署命令                   调用 Jenkins API
+       ↓                              ↓
+用户手动执行                   自动触发部署
+       ↓                              ↓
+验证 API                       轮询构建状态
+                                      ↓
+                               验证 API
+```
+
+## 环境说明
+
+| 环境 | 触发方式 | 镜像标签 | 用途 |
+|------|----------|----------|------|
+| staging | 手动 SSH | `:test` | 预发布测试 |
+| production | Jenkins API | `:latest` | 正式生产 |
+
+## 镜像构建规范
+
+> ⚠️ **重要**: 必须理解 Dockerfile target 和镜像标签的区别
+
+### Dockerfile Target vs 镜像标签
+
+| 概念 | 说明 | 示例 |
+|------|------|------|
+| **Dockerfile Target** | 构建阶段，决定镜像内容 | `--target production`, `--target test` |
+| **镜像标签** | 版本标识，决定部署环境 | `:test`, `:latest` |
+
+### 正确的构建方式
+
+| 用途 | Dockerfile Target | 镜像标签 | 镜像大小 |
+|------|-------------------|----------|----------|
+| **Staging 部署** | `--target production` | `:test` | ~50MB |
+| **Production 部署** | `--target production` | `:latest` | ~50MB |
+| **运行单元测试** | `--target test` | 无需推送 | ~900MB+ |
+
+### 常见错误
+
+❌ **错误做法**：用 `--target test` 构建部署镜像
+```bash
+# 错误！这会生成 900MB+ 的镜像，包含测试框架和源代码
+docker buildx build --target test -t xxx:test ...
+```
+
+✅ **正确做法**：用 `--target production` 构建部署镜像
+```bash
+# 正确！生成 ~50MB 的精简镜像，只包含二进制文件
+docker buildx build --target production -t xxx:test ...
+```
+
+### Staging vs Production 镜像区别
+
+两者都使用 `--target production` 构建，区别在于：
+
+| 区别点 | Staging (`:test`) | Production (`:latest`) |
+|--------|-------------------|------------------------|
+| 镜像标签 | `:test` | `:latest` |
+| 前端 API URL | `staging.ai.pipexerp.com` | `ai.pipexerp.com` |
+| 后端代码 | 完全相同 | 完全相同 |
+| 部署服务器 | singapore | tools_ai_proj |
+
+> **注意**: 不是把 staging 镜像部署到生产，而是测试通过后用生产 URL **重新构建** `:latest` 镜像
+
+## Staging 部署
+
+### 前置条件
+
+> ⚠️ **必须完成本机测试才能部署 staging**
+
+| 检查项 | 说明 |
+|--------|------|
+| 代码评审 | `/req cr` 已完成 |
+| 后端单元测试 | `go test ./... -v` 全部通过 |
+| **前端截图验证** | 使用 chrome-dev MCP 截图确认 UI 正确显示 |
+
+如果本机测试未通过，将拒绝部署并提示：
+```
+→ ❌ 本机测试未完成，禁止部署到 staging
+→ 请先执行: /req test REQ-XXX
+```
+
+### 命令格式
+
+```bash
+/req deploy REQ-XXX --env staging [--service <service>]
+```
+
+### 支持的服务
+
+| 服务 | 说明 |
+|------|------|
+| `backend` | 后端 API 服务 |
+| `frontend` | 前端 Web 应用 |
+| `all` | 全部服务（默认） |
+
+### 执行流程
+
+1. **构建镜像**（本地执行）
+   ```bash
+   # 后端
+   docker buildx build --platform linux/amd64 \
+     -f backend/Dockerfile --target production \
+     -t saltthing123/ai-proj-backend:test --push backend/
+
+   # 前端（注意 API URL 配置）
+   docker buildx build --platform linux/amd64 \
+     -f frontend/Dockerfile.prod --target production \
+     --build-arg REACT_APP_API_URL=https://staging.ai.pipexerp.com/api/v1 \
+     --build-arg REACT_APP_API_BASE_URL=https://staging.ai.pipexerp.com/api/v1 \
+     -t saltthing123/ai-proj-frontend:test --push frontend/
+   ```
+
+2. **部署命令**（用户手动执行）
+   ```bash
+   ssh singapore "cd /opt/ai-project-staging && \
+     sudo docker-compose pull && \
+     sudo docker-compose up -d"
+   ```
+
+3. **验证**
+   ```bash
+   curl -s https://staging.ai.pipexerp.com/api/v1/health | jq .
+   ```
+
+## Production 部署
+
+### 命令格式
+
+```bash
+/req deploy REQ-XXX --env production [--service <service>]
+```
+
+### 支持的服务
+
+| 服务 | 镜像名 | Jenkins 参数 |
+|------|--------|--------------|
+| `backend` | saltthing123/ai-proj-backend | SERVICE=backend |
+| `frontend` | saltthing123/ai-proj-frontend | SERVICE=frontend |
+| `ios` | - | SERVICE=ios |
+| `android` | - | SERVICE=android |
+| `all` | 全部 | SERVICE=all（默认） |
+
+### 执行流程
+
+1. **构建镜像**（本地执行）
+   ```bash
+   # 后端
+   docker buildx build --platform linux/amd64 \
+     -f backend/Dockerfile --target production \
+     -t saltthing123/ai-proj-backend:latest --push backend/
+
+   # 前端
+   docker buildx build --platform linux/amd64 \
+     -f frontend/Dockerfile.prod --target production \
+     --build-arg REACT_APP_API_URL=https://ai.pipexerp.com/api/v1 \
+     --build-arg REACT_APP_API_BASE_URL=https://ai.pipexerp.com/api/v1 \
+     -t saltthing123/ai-proj-frontend:latest --push frontend/
+   ```
+
+2. **触发 Jenkins 部署**
+   ```bash
+   source ~/.config/devops/credentials.env
+   curl -X POST "$JENKINS_URL/job/ai-proj/buildWithParameters" \
+     -u "$JENKINS_USER:$JENKINS_TOKEN" \
+     --data "SERVICE=backend&IMAGE_TAG=latest"
+   ```
+
+3. **查看构建状态**
+   ```bash
+   source ~/.config/devops/credentials.env
+   curl -s "$JENKINS_URL/job/ai-proj/lastBuild/api/json" \
+     -u "$JENKINS_USER:$JENKINS_TOKEN" | jq '.result, .building'
+   ```
+
+4. **验证**
+   ```bash
+   curl -s https://ai.pipexerp.com/api/v1/health | jq .
+   ```
+
+## 安全约束
+
+- **禁止自动 SSH 部署到生产服务器**
+- 生产环境部署必须通过 Jenkins API 触发
+- Staging 部署命令只显示，由用户手动执行
+- 构建失败时必须显示错误原因和解决方案
+
+## 项目配置
+
+### AI-Proj
+
+| 配置项 | 值 |
+|--------|-----|
+| Jenkins Job | ai-proj |
+| Staging 服务器 | singapore |
+| Production 服务器 | tools_ai_proj |
+| DockerHub 用户 | saltthing123 |
+
+### Coolbuy-Paas
+
+| 配置项 | 值 |
+|--------|-----|
+| Jenkins Job | coolbuy-paas |
+| Staging 服务器 | fnos 测试环境 |
+| Production 服务器 | 39.106.88.83 |
+| DockerHub 用户 | saltthing123 |
+
+## 常见问题
+
+### Docker 推送失败
+
+**错误**: `push access denied`
+
+**解决**:
+```bash
+docker login
+# 输入 Docker Hub 凭据
+```
+
+### Jenkins 构建失败
+
+**查看日志**:
+```bash
+source ~/.config/devops/credentials.env
+curl -s "$JENKINS_URL/job/ai-proj/lastBuild/consoleText" \
+  -u "$JENKINS_USER:$JENKINS_TOKEN" | tail -100
+```
+
+### 镜像架构不匹配
+
+**错误**: `exec format error`
+
+**原因**: 在 ARM64 (M1/M2 Mac) 构建的镜像部署到 AMD64 服务器
+
+**解决**: 构建时必须指定 `--platform linux/amd64`
+
+### 镜像体积异常大（900MB+）
+
+**错误**: 构建的镜像超过 100MB
+
+**原因**: 使用了错误的 Dockerfile target
+
+**检查**:
+```bash
+# 查看镜像层大小
+docker history <image>:<tag> --no-trunc --format "{{.Size}}\t{{.CreatedBy}}" | head -10
+```
+
+**常见原因**:
+| 层内容 | 大小 | 说明 |
+|--------|------|------|
+| `go mod download` | 600MB+ | Go 依赖包（不应出现在生产镜像） |
+| `ginkgo/gomega` | 200MB+ | 测试框架（不应出现在生产镜像） |
+| `COPY . .` | 100MB+ | 源代码（不应出现在生产镜像） |
+
+**解决**: 确保使用 `--target production` 而不是 `--target test`
+
+```bash
+# 错误
+docker buildx build --target test ...
+
+# 正确
+docker buildx build --target production ...
+```
--- a/skills-req/req-plugin/docs/hook-sync.md
+++ b/skills-req/req-plugin/docs/hook-sync.md
@@ -0,0 +1,55 @@
+# Hook 自动同步机制
+
+Hook 机制可在特定事件发生时自动触发同步，无需手动执行。
+
+## 支持的 Hook 事件
+
+| 事件 | 触发条件 | 自动执行操作 |
+|------|---------|-------------|
+| `requirement.created` | 创建新需求 | 同步需求到远程 |
+| `requirement.submitted` | 提交评审 | 发送评审通知 |
+| `requirement.approved` | 需求评审通过 | 同步需求 + 关联任务到远程 |
+| `requirement.archived` | 需求归档 | 最终同步 + 同步到思源笔记 + 发送通知 |
+| `task.completed` | 任务完成 | 同步任务状态到远程 |
+
+## 配置 Hook
+
+在 `.claude/settings.local.json` 中配置：
+
+```json
+{
+  "hooks": {
+    "requirement.approved": {
+      "enabled": true,
+      "actions": ["sync_requirement_to_remote", "sync_tasks_to_remote"]
+    },
+    "requirement.archived": {
+      "enabled": true,
+      "actions": ["sync_requirement_to_remote", "sync_to_siyuan", "send_notification"]
+    },
+    "task.completed": {
+      "enabled": true,
+      "actions": ["sync_task_to_remote"]
+    }
+  }
+}
+```
+
+## 手动触发 Hook
+
+```bash
+/req hook trigger requirement.approved REQ-2026-0010
+```
+
+## 查看 Hook 执行历史
+
+```bash
+/req hook history REQ-2026-0010
+```
+
+## 禁用/启用 Hook
+
+```bash
+/req hook disable REQ-2026-0010
+/req hook enable REQ-2026-0010
+```
--- a/skills-req/req-plugin/docs/mcp-auth-config.md
+++ b/skills-req/req-plugin/docs/mcp-auth-config.md
@@ -0,0 +1,64 @@
+# MCP 认证配置
+
+## 环境选择原则
+
+> 需求和任务的主数据源是**生产环境 (ai.pipexerp.com)**。
+> 所有需求创建、任务创建、查询、更新操作必须在生产环境执行。
+
+| 环境 | 用途 | API 地址 |
+|------|------|----------|
+| **生产环境** | 需求创建、任务创建、数据管理 | https://ai.pipexerp.com/api/v1 |
+| 本地环境 | 代码开发调试、功能测试 | http://localhost:8080/api/v1 |
+
+## MCP 配置
+
+确保 `~/.claude/.mcp.json` 配置：
+
+```json
+{
+  "mcpServers": {
+    "ai-proj": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["/path/to/mcp-task-bridge/dist/index.js"],
+      "env": {
+        "TASK_API_BASE": "https://ai.pipexerp.com/api/v1",
+        "TASK_API_TOKEN": "aiproj_pk_xxxxxxxx...",
+        "SYNC_REMOTE_API_BASE": "https://ai.pipexerp.com/api/v1",
+        "SYNC_REMOTE_API_KEY": "aiproj_pk_xxxxxxxx..."
+      }
+    }
+  }
+}
+```
+
+## 认证方式
+
+### PAT 秘钥（推荐）
+
+- 格式: `aiproj_pk_` + 64 字符十六进制（共 74 字符）
+- 优势: 长期有效，无需频繁更新
+
+### dev-quick-login（备选）
+
+仅在 PAT 秘钥不可用时使用：
+
+```bash
+curl -s -X POST "http://localhost:8080/api/v1/auth/dev-quick-login" \
+  -H "Content-Type: application/json" \
+  -d '{"username":"qiudl"}' | jq -r '.data.access_token'
+```
+
+> JWT token 有效期 24 小时，日常使用推荐 PAT 秘钥。
+
+## 验证 PAT 秘钥
+
+```bash
+# 测试本地
+curl -s -H "X-API-Key: aiproj_pk_xxx..." \
+  "http://localhost:8080/api/v1/tasks?limit=1" | jq '.success'
+
+# 测试远程
+curl -s -H "Authorization: Bearer aiproj_pk_xxx..." \
+  "https://ai.pipexerp.com/api/v1/tasks?limit=1" | jq '.success'
+```
--- a/skills-req/req-plugin/docs/notification-config.md
+++ b/skills-req/req-plugin/docs/notification-config.md
@@ -0,0 +1,42 @@
+# 通知与自动化配置
+
+## 邮件通知
+
+### 默认邮件组
+
+| 收件人 |
+|--------|
+| qiudl@zhiyuncai.com |
+| fuxing@zhiyuncai.com |
+| haiqing@zhiyuncai.com |
+| wuweier@zhiyuncai.com |
+
+### 通知类型
+
+| 类型 | 触发时机 | 邮件主题 | 附件文档 |
+|------|----------|----------|----------|
+| `prd` | PRD完成 | [REQ-PRD] REQ-XXXX PRD文档已完成 | 01-PRD.md |
+| `dev` | 开发完成 | [REQ-开发] REQ-XXXX 开发完成 | 02-开发设计.md |
+| `test` | 测试完成 | [REQ-测试] REQ-XXXX 测试完成 | 03-测试报告.md |
+| `deploy` | 发布完成 | [REQ-发布] REQ-XXXX 已发布 | 04-发布记录.md |
+| `archive` | 归档 | [REQ-归档] REQ-XXXX 已归档 | 05-生命周期总结.md |
+
+### 使用方式
+
+```bash
+# 使用默认邮件组
+/req notify REQ-2026-0007 --type deploy
+
+# 自定义收件人
+~/.claude/skills/req/notify.sh -r REQ-2026-0007 -t deploy -e "user1@example.com,user2@example.com"
+
+# 不发送附件
+~/.claude/skills/req/notify.sh -r REQ-2026-0007 -t archive -n
+```
+
+## 脚本文件
+
+| 脚本 | 功能 | 位置 |
+|------|------|------|
+| notify.sh | 发送邮件通知 | ~/.claude/skills/req/ |
+| update-siyuan-release.sh | 更新思源笔记发布记录 | ~/.claude/skills/req/ |
--- a/skills-req/req-plugin/docs/prd-review-guide.md
+++ b/skills-req/req-plugin/docs/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 设计不合理 | 重新设计并说明理由 |
+| 范围过大 | 需求范围过大难以实现 | 拆分为多个小需求 |
+| 验收不明 | 缺少验收标准 | 补充可验证的验收条件 |
--- a/skills-req/req-plugin/docs/siyuan-integration.md
+++ b/skills-req/req-plugin/docs/siyuan-integration.md
@@ -0,0 +1,50 @@
+# 思源笔记集成
+
+需求的 5 阶段文档统一存储到思源笔记中。
+
+## 文档结构
+
+```
+需求管理/
+└── REQ-2026-XXXX/
+    ├── 01-PRD.md                 # 产品需求文档
+    ├── 02-开发设计.md            # 开发技术文档
+    ├── 03-测试报告.md            # 测试验收报告
+    ├── 04-发布记录.md            # CI/CD发布记录
+    └── 05-生命周期总结.md        # 需求归档总结
+```
+
+## 同步命令
+
+```bash
+/req sync-siyuan REQ-2026-0007
+```
+
+## 自动同步时机
+
+| 阶段 | 触发命令 | 同步文档 |
+|------|---------|---------|
+| PRD 完成 | `/req review` | 01-PRD.md |
+| 开发完成 | `/req test` | 02-开发设计.md |
+| 测试完成 | `/req deploy` | 03-测试报告.md |
+| 发布完成 | 发布任务完成 | 04-发布记录.md |
+| 归档完成 | `/req done` | 05-生命周期总结.md (全量同步) |
+
+## MCP 工具调用
+
+```python
+# 创建文档
+mcp__siyuan__createDocWithMd(
+    notebook="需求管理",
+    path="/REQ-2026-0007/01-PRD",
+    markdown=prd_content
+)
+```
+
+## 配置
+
+环境变量（可选）：
+```bash
+export SIYUAN_URL="http://100.118.62.18:6806"
+export SIYUAN_TOKEN="your-token"
+```
--- a/skills-req/req-plugin/docs/test-guide.md
+++ b/skills-req/req-plugin/docs/test-guide.md
@@ -0,0 +1,177 @@
+# 测试环境流程指南
+
+> 测试必须按照以下环境顺序依次进行，每个环境通过后才能进入下一个环境。
+
+## 测试环境流程
+
+```
+[1] 本机环境 ─── 通过 ──→ [2] 预发布环境 ─── 通过 ──→ [3] 生产环境
+      │                        │                        │
+      ↓ 失败                   ↓ 失败                   ↓ 失败
+  修复并重测              回到步骤[1]              回到步骤[1]
+```
+
+## 项目环境配置表
+
+| 项目 | 本机环境 | 预发布环境 | 生产环境 |
+|------|---------|-----------|---------|
+| ai-proj | localhost:3000/8080 | staging.ai.pipexerp.com | ai.pipexerp.com |
+| coolbuy-paas | localhost | fnos 测试环境 | 39.106.88.83:8888 |
+| coolbuy-platform | localhost | fnos 测试环境 | 生产服务器 |
+
+## 第一阶段：本机测试环境
+
+> ⚠️ **关键约束**：本机测试必须全部通过，才能部署到 staging 环境。
+
+**测试内容**：
+- 单元测试 - 测试单个函数/方法，Mock 外部依赖
+- 集成测试 - 测试模块间交互，使用测试数据库
+- 功能验证 - 验证功能逻辑正确性
+- **前端截图验证** - 使用 chrome-dev MCP 截图确认 UI 显示正确
+
+### 后端测试
+
+```bash
+# Go 后端单元测试
+go test ./... -v
+
+# 指定模块测试
+go test ./backend/handlers/... -v
+go test ./backend/services/... -v
+```
+
+### 前端截图验证（⚠️ 必须步骤）
+
+> **重要**：前端改动必须通过截图验证，不能只测后端 API。这一步经常被忽略，导致功能未正确显示。
+
+**验证流程**：
+
+1. **确保本机服务运行**
+   ```bash
+   # 终端1：后端
+   cd backend && go run main.go
+
+   # 终端2：前端
+   cd frontend && npm start
+   ```
+
+2. **使用 chrome-dev MCP 截图验证**
+   ```python
+   # 步骤1：导航到目标页面
+   mcp__chrome-dev__navigate_page(url="http://localhost:3000/requirements/686")
+
+   # 步骤2：等待页面加载完成（可选）
+   mcp__chrome-dev__wait_for(selector=".requirement-detail")
+
+   # 步骤3：截图
+   mcp__chrome-dev__take_screenshot()
+
+   # 步骤4：检查截图中功能是否正确显示
+   # - 新增的列/字段是否显示
+   # - 样式是否正确
+   # - 数据是否正确渲染
+   ```
+
+3. **常见验证场景**
+   | 改动类型 | 验证页面 | 检查项 |
+   |---------|---------|--------|
+   | 列表新增列 | 列表页面 | 新列是否显示、数据是否正确 |
+   | 表单新增字段 | 表单页面 | 字段是否显示、能否正常输入 |
+   | 样式调整 | 相关页面 | 样式是否生效、布局是否正确 |
+   | 权限控制 | 相关页面 | 按钮/菜单是否正确显示/隐藏 |
+
+4. **截图保存**
+   - 截图应保存到测试任务文档中作为验证记录
+   - 命名规范：`REQ-XXXXX-本机测试-功能名称.png`
+
+### 前端截图验证示例
+
+```
+/req test REQ-20260125-0002
+
+→ 检查代码评审... ✓ 已完成
+→ 验证开发任务... ✓ 已完成
+
+=== 本机测试阶段 ===
+
+1. 后端单元测试
+   → go test ./backend/handlers/requirement_handler_test.go -v
+   → ✓ 3/3 测试通过
+
+2. 前端截图验证
+   → 启动 chrome-dev MCP...
+   → 导航到: http://localhost:3000/requirements/687
+   → 截图验证...
+   → ✓ 任务ID列正确显示 (#5284 格式)
+   → ✓ 列宽度和样式正确
+   → 截图已保存
+
+=== 本机测试通过 ===
+→ 可以执行: /req deploy REQ-20260125-0002 --env staging
+```
+
+### 通过标准
+
+- [ ] 所有后端单元测试通过
+- [ ] **前端截图验证通过**（有前端改动时必须）
+- [ ] 功能在本地环境正常运行
+- [ ] 无控制台错误
+- [ ] 截图已保存到测试文档
+
+### 跳过前端验证
+
+仅当改动不涉及前端时，可使用 `--backend-only` 参数：
+
+```bash
+/req test REQ-XXXXX --backend-only
+```
+
+## 第二阶段：预发布环境
+
+**测试内容**：
+- E2E 测试 - 测试完整用户流程
+- 跨浏览器测试 - Chrome、Firefox、Safari
+- 性能测试 - 页面加载时间、API 响应时间
+
+**通过标准**：
+- [ ] 功能在预发布环境正常运行
+- [ ] 与生产环境配置一致
+- [ ] 无跨环境兼容性问题
+
+## 第三阶段：生产环境
+
+**测试内容**：
+- UAT 验收 - 用户验收测试
+- 冒烟测试 - 核心功能快速验证
+- 回归测试 - 确保未破坏现有功能
+
+**通过标准**：
+- [ ] 功能在生产环境正常运行
+- [ ] 用户验收通过
+- [ ] 无生产环境特有问题
+
+## API 验证清单
+
+```bash
+# 1. 本机环境
+curl -s "http://localhost:8080/api/v1/requirements?search=REQ-2026" \
+  -H "Authorization: Bearer $TOKEN" | jq '.data | length'
+
+# 2. 预发布环境
+curl -s "https://staging.ai.pipexerp.com/api/v1/requirements?search=REQ-2026" \
+  -H "X-API-Key: $SYNC_REMOTE_API_KEY" | jq '.data | length'
+
+# 3. 生产环境
+curl -s "https://ai.pipexerp.com/api/v1/requirements?search=REQ-2026" \
+  -H "X-API-Key: $SYNC_REMOTE_API_KEY" | jq '.data | length'
+```
+
+## 测试失败处理
+
+| 失败阶段 | 处理方式 |
+|---------|---------|
+| 本机测试 | 修复代码，重新运行本机测试 |
+| 预发布测试 | 修复代码，重新从本机测试开始 |
+| 生产环境测试 | 修复代码，重新从本机测试开始 |
+
+> 任何阶段测试失败，修复后必须从本机测试环境重新开始。
--- a/skills-req/req-plugin/docs/workflow-example.md
+++ b/skills-req/req-plugin/docs/workflow-example.md
@@ -0,0 +1,120 @@
+# 完整开发工作流示例
+
+以「酷采3.0 标签管理模块」为例的完整需求生命周期。
+
+## 第一步：创建需求
+
+```bash
+/req new 酷采3.0 商品标签管理模块
+```
+
+执行：`mcp__ai-proj__create_requirement` → 自动分配 display_id（如 REQ-2026-0006）
+
+## 第二步：编写 PRD 文档
+
+调用 `req-prd` 技能：
+1. 创建 PRD 任务并关联到需求
+2. 调用 `mcp__ai-proj__create-and-attach` 写入 PRD 文档
+
+## 第三步：创建开发子任务
+
+```python
+# 创建子任务
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：数据模型设计")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：Store/Biz实现")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：API Handler实现")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="前端：页面开发")
+
+# 批量关联到需求
+mcp__ai-proj__link_tasks_to_requirement(requirementId=需求ID, taskIds=[...])
+```
+
+## 第四步：提交并审批需求
+
+```bash
+/req review          # draft → pending
+/req review pass     # pending → approved
+```
+
+## 第五步：执行开发任务
+
+```bash
+/req dev REQ-2026-0006
+```
+
+按分层架构开发：Model → Store → Biz → Handler → Router
+
+## 第六步：代码评审
+
+```bash
+/req cr REQ-2026-0006
+```
+
+开发完成后必须进行代码评审，评审通过后才能进入测试。
+
+## 第七步：创建测试任务
+
+```python
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="后端：单元测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="后端：集成测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="E2E：端到端测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="UAT：用户验收测试")
+```
+
+## 第八步：执行测试
+
+```bash
+/req test REQ-2026-0006
+```
+
+按环境顺序：本机 → 预发布 → 生产
+
+## 第九步：CI/CD 发布
+
+```bash
+/req deploy REQ-2026-0006 --env staging
+```
+
+## 第十步：完成归档
+
+```bash
+/req done REQ-2026-0006
+```
+
+自动生成需求生命周期总结文档，归档需求。
+
+---
+
+## 标准任务结构
+
+```
+需求: REQ-2026-XXXX
+├── PRD 任务 (父任务，包含 PRD 文档)
+│   ├── 后端：数据模型设计 (implementation)
+│   ├── 后端：业务层实现 (implementation)
+│   ├── 后端：API 实现 (implementation)
+│   └── 前端：页面开发 (implementation)
+│
+├── 代码评审任务 (code_review) ← 必须步骤
+│
+├── 测试任务 (父任务)
+│   ├── 单元测试 (test)
+│   ├── 集成测试 (test)
+│   ├── E2E测试 (test)
+│   └── UAT验收 (test, 包含测试报告)
+│
+└── 发布任务 (父任务，包含发布记录)
+    ├── Docker 镜像构建 (deploy)
+    ├── 前端资源构建 (deploy)
+    └── 部署到环境 (deploy)
+```
+
+## 5 阶段文档
+
+| 序号 | 文档 | 阶段 |
+|------|------|------|
+| 01 | PRD | 需求定义 |
+| 02 | 开发设计 | 开发实现 |
+| 03 | 测试报告 | 测试验收 |
+| 04 | 发布记录 | CI/CD部署 |
+| 05 | 生命周期总结 | 归档 |
--- a/skills-req/req-plugin/hook-sync.md
+++ b/skills-req/req-plugin/hook-sync.md
@@ -0,0 +1,55 @@
+# Hook 自动同步机制
+
+Hook 机制可在特定事件发生时自动触发同步，无需手动执行。
+
+## 支持的 Hook 事件
+
+| 事件 | 触发条件 | 自动执行操作 |
+|------|---------|-------------|
+| `requirement.created` | 创建新需求 | 同步需求到远程 |
+| `requirement.submitted` | 提交评审 | 发送评审通知 |
+| `requirement.approved` | 需求评审通过 | 同步需求 + 关联任务到远程 |
+| `requirement.archived` | 需求归档 | 最终同步 + 同步到思源笔记 + 发送通知 |
+| `task.completed` | 任务完成 | 同步任务状态到远程 |
+
+## 配置 Hook
+
+在 `.claude/settings.local.json` 中配置：
+
+```json
+{
+  "hooks": {
+    "requirement.approved": {
+      "enabled": true,
+      "actions": ["sync_requirement_to_remote", "sync_tasks_to_remote"]
+    },
+    "requirement.archived": {
+      "enabled": true,
+      "actions": ["sync_requirement_to_remote", "sync_to_siyuan", "send_notification"]
+    },
+    "task.completed": {
+      "enabled": true,
+      "actions": ["sync_task_to_remote"]
+    }
+  }
+}
+```
+
+## 手动触发 Hook
+
+```bash
+/req hook trigger requirement.approved REQ-2026-0010
+```
+
+## 查看 Hook 执行历史
+
+```bash
+/req hook history REQ-2026-0010
+```
+
+## 禁用/启用 Hook
+
+```bash
+/req hook disable REQ-2026-0010
+/req hook enable REQ-2026-0010
+```
--- a/skills-req/req-plugin/mcp-auth-config.md
+++ b/skills-req/req-plugin/mcp-auth-config.md
@@ -0,0 +1,64 @@
+# MCP 认证配置
+
+## 环境选择原则
+
+> 需求和任务的主数据源是**生产环境 (ai.pipexerp.com)**。
+> 所有需求创建、任务创建、查询、更新操作必须在生产环境执行。
+
+| 环境 | 用途 | API 地址 |
+|------|------|----------|
+| **生产环境** | 需求创建、任务创建、数据管理 | https://ai.pipexerp.com/api/v1 |
+| 本地环境 | 代码开发调试、功能测试 | http://localhost:8080/api/v1 |
+
+## MCP 配置
+
+确保 `~/.claude/.mcp.json` 配置：
+
+```json
+{
+  "mcpServers": {
+    "ai-proj": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["/path/to/mcp-task-bridge/dist/index.js"],
+      "env": {
+        "TASK_API_BASE": "https://ai.pipexerp.com/api/v1",
+        "TASK_API_TOKEN": "aiproj_pk_xxxxxxxx...",
+        "SYNC_REMOTE_API_BASE": "https://ai.pipexerp.com/api/v1",
+        "SYNC_REMOTE_API_KEY": "aiproj_pk_xxxxxxxx..."
+      }
+    }
+  }
+}
+```
+
+## 认证方式
+
+### PAT 秘钥（推荐）
+
+- 格式: `aiproj_pk_` + 64 字符十六进制（共 74 字符）
+- 优势: 长期有效，无需频繁更新
+
+### dev-quick-login（备选）
+
+仅在 PAT 秘钥不可用时使用：
+
+```bash
+curl -s -X POST "http://localhost:8080/api/v1/auth/dev-quick-login" \
+  -H "Content-Type: application/json" \
+  -d '{"username":"qiudl"}' | jq -r '.data.access_token'
+```
+
+> JWT token 有效期 24 小时，日常使用推荐 PAT 秘钥。
+
+## 验证 PAT 秘钥
+
+```bash
+# 测试本地
+curl -s -H "X-API-Key: aiproj_pk_xxx..." \
+  "http://localhost:8080/api/v1/tasks?limit=1" | jq '.success'
+
+# 测试远程
+curl -s -H "Authorization: Bearer aiproj_pk_xxx..." \
+  "https://ai.pipexerp.com/api/v1/tasks?limit=1" | jq '.success'
+```
--- a/skills-req/req-plugin/notification-config.md
+++ b/skills-req/req-plugin/notification-config.md
@@ -0,0 +1,42 @@
+# 通知与自动化配置
+
+## 邮件通知
+
+### 默认邮件组
+
+| 收件人 |
+|--------|
+| qiudl@zhiyuncai.com |
+| fuxing@zhiyuncai.com |
+| haiqing@zhiyuncai.com |
+| wuweier@zhiyuncai.com |
+
+### 通知类型
+
+| 类型 | 触发时机 | 邮件主题 | 附件文档 |
+|------|----------|----------|----------|
+| `prd` | PRD完成 | [REQ-PRD] REQ-XXXX PRD文档已完成 | 01-PRD.md |
+| `dev` | 开发完成 | [REQ-开发] REQ-XXXX 开发完成 | 02-开发设计.md |
+| `test` | 测试完成 | [REQ-测试] REQ-XXXX 测试完成 | 03-测试报告.md |
+| `deploy` | 发布完成 | [REQ-发布] REQ-XXXX 已发布 | 04-发布记录.md |
+| `archive` | 归档 | [REQ-归档] REQ-XXXX 已归档 | 05-生命周期总结.md |
+
+### 使用方式
+
+```bash
+# 使用默认邮件组
+/req notify REQ-2026-0007 --type deploy
+
+# 自定义收件人
+~/.claude/skills/req/notify.sh -r REQ-2026-0007 -t deploy -e "user1@example.com,user2@example.com"
+
+# 不发送附件
+~/.claude/skills/req/notify.sh -r REQ-2026-0007 -t archive -n
+```
+
+## 脚本文件
+
+| 脚本 | 功能 | 位置 |
+|------|------|------|
+| notify.sh | 发送邮件通知 | ~/.claude/skills/req/ |
+| update-siyuan-release.sh | 更新思源笔记发布记录 | ~/.claude/skills/req/ |
--- a/skills-req/req-plugin/notify.sh
+++ b/skills-req/req-plugin/notify.sh
@@ -0,0 +1,455 @@
+#!/bin/bash
+# REQ 需求发布通知脚本 v3.2.0
+# 用于在需求发布完成后发送邮件通知到邮件组
+# 功能：HTML正文(含文档内容) + Markdown附件
+
+# ==================== 配置 ====================
+
+# 默认邮件组
+DEFAULT_EMAIL_GROUP=(
+    "qiudl@zhiyuncai.com"
+    "fuxing@zhiyuncai.com"
+    "haiqing@zhiyuncai.com"
+    "wuweier@zhiyuncai.com"
+)
+
+# 思源笔记配置
+SIYUAN_API_URL="${SIYUAN_URL:-http://100.118.62.18:6806}"
+SIYUAN_TOKEN="${SIYUAN_TOKEN:-nfnycjb1g8vbexb2}"
+SIYUAN_NOTEBOOK_NAME="需求管理"
+
+# 发件人
+FROM_NAME="REQ 需求管理系统"
+
+# 临时目录
+TMP_DIR="/tmp/req-notify-$$"
+
+# ==================== 函数定义 ====================
+
+# 使用方法
+usage() {
+    echo "Usage: $0 -r <REQ-ID> -t <type> [-e <emails>] [-m <message>] [-a <attachment>] [-n]"
+    echo ""
+    echo "Options:"
+    echo "  -r REQ-ID       需求编号 (如 REQ-2026-0007)"
+    echo "  -t type         通知类型: prd|dev|test|deploy|archive"
+    echo "  -e emails       收件人邮箱，多个用逗号分隔 (覆盖默认邮件组)"
+    echo "  -a attachment   附件文件路径 (可选，覆盖自动获取)"
+    echo "  -n              不附加文档 (仅发送通知)"
+    echo "  -m message      附加消息"
+    echo "  -h              显示帮助"
+    echo ""
+    echo "默认邮件组 (${#DEFAULT_EMAIL_GROUP[@]} 人):"
+    for email in "${DEFAULT_EMAIL_GROUP[@]}"; do
+        echo "  - $email"
+    done
+    echo ""
+    echo "通知类型与文档映射:"
+    echo "  prd     → 01-PRD"
+    echo "  dev     → 02-开发设计"
+    echo "  test    → 03-测试报告"
+    echo "  deploy  → 04-发布记录"
+    echo "  archive → 05-生命周期总结"
+    exit 1
+}
+
+# 清理临时文件
+cleanup() {
+    rm -rf "$TMP_DIR" 2>/dev/null
+}
+trap cleanup EXIT
+
+# 从思源笔记获取文档内容
+fetch_siyuan_doc() {
+    local doc_path="$1"
+    local output_file="$2"
+
+    echo "正在从思源笔记获取文档: $doc_path"
+
+    # 1. 先查询文档 ID
+    local query="SELECT id, content FROM blocks WHERE type='d' AND hpath LIKE '%${doc_path}%' LIMIT 1"
+    local response=$(curl -s -X POST "${SIYUAN_API_URL}/api/query/sql" \
+        -H "Authorization: Token ${SIYUAN_TOKEN}" \
+        -H "Content-Type: application/json" \
+        -d "{\"stmt\": \"${query}\"}")
+
+    local doc_id=$(echo "$response" | jq -r '.data[0].id // empty')
+
+    if [ -z "$doc_id" ]; then
+        echo "警告: 未找到文档 $doc_path"
+        return 1
+    fi
+
+    # 2. 导出文档为 Markdown
+    local export_response=$(curl -s -X POST "${SIYUAN_API_URL}/api/export/exportMdContent" \
+        -H "Authorization: Token ${SIYUAN_TOKEN}" \
+        -H "Content-Type: application/json" \
+        -d "{\"id\": \"${doc_id}\"}")
+
+    local content=$(echo "$export_response" | jq -r '.data.content // empty')
+
+    if [ -z "$content" ]; then
+        echo "警告: 文档内容为空"
+        return 1
+    fi
+
+    # 3. 保存到文件
+    echo "$content" > "$output_file"
+    echo "文档已保存: $output_file ($(wc -c < "$output_file") 字节)"
+    return 0
+}
+
+# 根据通知类型获取文档路径
+get_doc_path() {
+    local req_id="$1"
+    local notify_type="$2"
+
+    case $notify_type in
+        prd)     echo "/${req_id}/01-PRD" ;;
+        dev)     echo "/${req_id}/02-开发设计" ;;
+        test)    echo "/${req_id}/03-测试报告" ;;
+        deploy)  echo "/${req_id}/04-发布记录" ;;
+        archive) echo "/${req_id}/05-生命周期总结" ;;
+        *)       echo "" ;;
+    esac
+}
+
+# 获取文档文件名
+get_doc_filename() {
+    local req_id="$1"
+    local notify_type="$2"
+
+    case $notify_type in
+        prd)     echo "${req_id}_01-PRD.md" ;;
+        dev)     echo "${req_id}_02-开发设计.md" ;;
+        test)    echo "${req_id}_03-测试报告.md" ;;
+        deploy)  echo "${req_id}_04-发布记录.md" ;;
+        archive) echo "${req_id}_05-生命周期总结.md" ;;
+        *)       echo "${req_id}_文档.md" ;;
+    esac
+}
+
+# 获取通知标题
+get_subject() {
+    local req_id="$1"
+    local notify_type="$2"
+
+    case $notify_type in
+        prd)     echo "[REQ-PRD] ${req_id} PRD文档已完成" ;;
+        dev)     echo "[REQ-开发] ${req_id} 开发完成" ;;
+        test)    echo "[REQ-测试] ${req_id} 测试完成" ;;
+        deploy)  echo "[REQ-发布] ${req_id} 已成功发布" ;;
+        archive) echo "[REQ-归档] ${req_id} 已归档" ;;
+        *)       echo "[REQ] ${req_id} 通知" ;;
+    esac
+}
+
+# 获取通知类型描述
+get_type_desc() {
+    local notify_type="$1"
+
+    case $notify_type in
+        prd)     echo "PRD文档完成" ;;
+        dev)     echo "开发完成" ;;
+        test)    echo "测试完成" ;;
+        deploy)  echo "发布完成" ;;
+        archive) echo "需求归档" ;;
+        *)       echo "状态更新" ;;
+    esac
+}
+
+# 将 Markdown 转换为 HTML (简单转换)
+markdown_to_html() {
+    local md_content="$1"
+
+    # 转义 HTML 特殊字符
+    local escaped=$(echo "$md_content" | sed 's/&/\&amp;/g; s/</\&lt;/g; s/>/\&gt;/g')
+
+    # 转换标题
+    escaped=$(echo "$escaped" | sed -E 's/^### (.*)$/<h3>\1<\/h3>/g')
+    escaped=$(echo "$escaped" | sed -E 's/^## (.*)$/<h2>\1<\/h2>/g')
+    escaped=$(echo "$escaped" | sed -E 's/^# (.*)$/<h1>\1<\/h1>/g')
+
+    # 转换粗体
+    escaped=$(echo "$escaped" | sed -E 's/\*\*([^*]+)\*\*/<strong>\1<\/strong>/g')
+
+    # 转换代码块
+    escaped=$(echo "$escaped" | sed -E 's/`([^`]+)`/<code>\1<\/code>/g')
+
+    # 转换列表项
+    escaped=$(echo "$escaped" | sed -E 's/^- (.*)$/<li>\1<\/li>/g')
+    escaped=$(echo "$escaped" | sed -E 's/^\* (.*)$/<li>\1<\/li>/g')
+
+    # 转换复选框
+    escaped=$(echo "$escaped" | sed 's/\[x\]/✅/g; s/\[ \]/⬜/g')
+
+    # 转换表格分隔线（简化处理）
+    escaped=$(echo "$escaped" | sed '/^|[-|]*$/d')
+
+    # 转换表格行
+    escaped=$(echo "$escaped" | sed -E 's/^\| (.+) \|$/<tr><td>\1<\/td><\/tr>/g')
+    escaped=$(echo "$escaped" | sed 's/ \| /<\/td><td>/g')
+
+    # 转换换行
+    escaped=$(echo "$escaped" | sed 's/$/<br>/g')
+
+    # 转换水平线
+    escaped=$(echo "$escaped" | sed 's/^---$/<hr>/g')
+
+    echo "$escaped"
+}
+
+# 生成邮件正文 (HTML格式，包含文档内容)
+generate_body_html() {
+    local req_id="$1"
+    local notify_type="$2"
+    local timestamp="$3"
+    local extra_message="$4"
+    local doc_path="$5"
+    local doc_content="$6"
+
+    local type_desc=$(get_type_desc "$notify_type")
+
+    # 转换文档内容为 HTML
+    local doc_html=""
+    if [ -n "$doc_content" ]; then
+        doc_html=$(markdown_to_html "$doc_content")
+    fi
+
+    cat <<EOF
+<!DOCTYPE html>
+<html>
+<head>
+    <meta charset="UTF-8">
+    <style>
+        body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; line-height: 1.6; color: #333; max-width: 900px; margin: 0 auto; padding: 20px; }
+        .header { background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); color: white; padding: 30px; border-radius: 10px 10px 0 0; }
+        .header h1 { margin: 0 0 10px 0; font-size: 24px; }
+        .header .req-id { font-size: 18px; opacity: 0.9; }
+        .summary { background: #f8f9fa; padding: 20px 30px; border: 1px solid #e9ecef; }
+        .info-table { width: 100%; border-collapse: collapse; margin: 15px 0; }
+        .info-table td { padding: 10px 15px; border-bottom: 1px solid #dee2e6; }
+        .info-table td:first-child { font-weight: 600; color: #495057; width: 100px; }
+        .status-badge { display: inline-block; padding: 4px 12px; border-radius: 15px; font-size: 13px; font-weight: 600; }
+        .status-success { background: #d4edda; color: #155724; }
+        .doc-section { background: #fff; border: 1px solid #e9ecef; border-top: none; padding: 30px; }
+        .doc-title { background: #343a40; color: white; padding: 15px 30px; margin: 0; font-size: 16px; }
+        .doc-content { font-size: 14px; line-height: 1.8; }
+        .doc-content h1 { font-size: 22px; color: #2c3e50; border-bottom: 2px solid #667eea; padding-bottom: 10px; margin-top: 25px; }
+        .doc-content h2 { font-size: 18px; color: #34495e; margin-top: 20px; }
+        .doc-content h3 { font-size: 16px; color: #495057; margin-top: 15px; }
+        .doc-content code { background: #f4f4f4; padding: 2px 6px; border-radius: 3px; font-family: 'SF Mono', Monaco, monospace; font-size: 13px; }
+        .doc-content table { border-collapse: collapse; width: 100%; margin: 15px 0; }
+        .doc-content td, .doc-content th { border: 1px solid #ddd; padding: 8px 12px; text-align: left; }
+        .doc-content tr:nth-child(even) { background: #f9f9f9; }
+        .doc-content li { margin: 5px 0; }
+        .doc-content hr { border: none; border-top: 1px solid #eee; margin: 20px 0; }
+        .footer { background: #f1f3f4; padding: 15px 30px; border-radius: 0 0 10px 10px; font-size: 12px; color: #666; text-align: center; }
+    </style>
+</head>
+<body>
+    <div class="header">
+        <h1>📋 需求${type_desc}通知</h1>
+        <div class="req-id">${req_id}</div>
+    </div>
+
+    <div class="summary">
+        <table class="info-table">
+            <tr><td>需求编号</td><td><strong>${req_id}</strong></td></tr>
+            <tr><td>通知类型</td><td>${type_desc}</td></tr>
+            <tr><td>完成时间</td><td>${timestamp}</td></tr>
+            <tr><td>状态</td><td><span class="status-badge status-success">✓ 已完成</span></td></tr>
+        </table>
+        $(if [ -n "$extra_message" ]; then echo "<p><strong>📝 说明：</strong>${extra_message}</p>"; fi)
+    </div>
+
+    $(if [ -n "$doc_html" ]; then
+        echo "<div class=\"doc-title\">📄 完整文档内容</div>"
+        echo "<div class=\"doc-section\"><div class=\"doc-content\">${doc_html}</div></div>"
+    fi)
+
+    <div class="footer">
+        此邮件由 <strong>REQ 需求管理系统</strong> 自动发送 | 文档同步自思源笔记：需求管理${doc_path}<br>
+        完整 Markdown 文档已作为附件发送
+    </div>
+</body>
+</html>
+EOF
+}
+
+# 发送带附件的邮件 (MIME格式)
+send_email_with_attachment() {
+    local recipient="$1"
+    local subject="$2"
+    local body_html="$3"
+    local attachment_file="$4"
+    local attachment_name="$5"
+
+    local boundary="----=_Part_$(date +%s)_$RANDOM"
+
+    # 读取附件内容并 base64 编码
+    local attachment_content=""
+    if [ -f "$attachment_file" ]; then
+        attachment_content=$(base64 < "$attachment_file")
+    fi
+
+    # 构建 MIME 邮件
+    {
+        echo "Subject: =?UTF-8?B?$(echo -n "$subject" | base64)?="
+        echo "To: $recipient"
+        echo "MIME-Version: 1.0"
+        echo "Content-Type: multipart/mixed; boundary=\"$boundary\""
+        echo ""
+        echo "--$boundary"
+        echo "Content-Type: text/html; charset=UTF-8"
+        echo "Content-Transfer-Encoding: base64"
+        echo ""
+        echo "$body_html" | base64
+
+        # 添加附件
+        if [ -n "$attachment_content" ]; then
+            echo ""
+            echo "--$boundary"
+            echo "Content-Type: text/markdown; charset=UTF-8; name=\"$attachment_name\""
+            echo "Content-Transfer-Encoding: base64"
+            echo "Content-Disposition: attachment; filename=\"$attachment_name\""
+            echo ""
+            echo "$attachment_content"
+        fi
+
+        echo ""
+        echo "--$boundary--"
+    } | msmtp "$recipient" 2>/dev/null
+
+    return $?
+}
+
+# ==================== 主程序 ====================
+
+# 解析参数
+REQ_ID=""
+NOTIFY_TYPE=""
+CUSTOM_EMAILS=""
+CUSTOM_ATTACHMENT=""
+NO_ATTACHMENT=false
+EXTRA_MESSAGE=""
+
+while getopts "r:t:e:a:m:nh" opt; do
+    case $opt in
+        r) REQ_ID="$OPTARG" ;;
+        t) NOTIFY_TYPE="$OPTARG" ;;
+        e) CUSTOM_EMAILS="$OPTARG" ;;
+        a) CUSTOM_ATTACHMENT="$OPTARG" ;;
+        n) NO_ATTACHMENT=true ;;
+        m) EXTRA_MESSAGE="$OPTARG" ;;
+        h) usage ;;
+        *) usage ;;
+    esac
+done
+
+# 验证必需参数
+if [ -z "$REQ_ID" ] || [ -z "$NOTIFY_TYPE" ]; then
+    echo "Error: -r 和 -t 参数是必需的"
+    usage
+fi
+
+# 验证通知类型
+case $NOTIFY_TYPE in
+    prd|dev|test|deploy|archive) ;;
+    *)
+        echo "Error: 未知的通知类型: $NOTIFY_TYPE"
+        echo "支持的类型: prd, dev, test, deploy, archive"
+        exit 1
+        ;;
+esac
+
+# 构建收件人列表
+declare -a RECIPIENTS
+if [ -n "$CUSTOM_EMAILS" ]; then
+    IFS=',' read -ra RECIPIENTS <<< "$CUSTOM_EMAILS"
+else
+    RECIPIENTS=("${DEFAULT_EMAIL_GROUP[@]}")
+fi
+
+# 获取时间戳
+TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
+
+# 获取文档信息
+DOC_PATH=$(get_doc_path "$REQ_ID" "$NOTIFY_TYPE")
+DOC_FILENAME=$(get_doc_filename "$REQ_ID" "$NOTIFY_TYPE")
+SUBJECT=$(get_subject "$REQ_ID" "$NOTIFY_TYPE")
+
+# 创建临时目录
+mkdir -p "$TMP_DIR"
+
+# 准备附件和文档内容
+ATTACHMENT_FILE=""
+DOC_CONTENT=""
+if [ "$NO_ATTACHMENT" = false ]; then
+    if [ -n "$CUSTOM_ATTACHMENT" ] && [ -f "$CUSTOM_ATTACHMENT" ]; then
+        ATTACHMENT_FILE="$CUSTOM_ATTACHMENT"
+        DOC_CONTENT=$(cat "$ATTACHMENT_FILE")
+        echo "使用指定附件: $ATTACHMENT_FILE"
+    else
+        # 从思源笔记获取文档
+        ATTACHMENT_FILE="${TMP_DIR}/${DOC_FILENAME}"
+        if fetch_siyuan_doc "$DOC_PATH" "$ATTACHMENT_FILE"; then
+            DOC_CONTENT=$(cat "$ATTACHMENT_FILE")
+        else
+            echo "警告: 无法获取文档，将发送不带附件的邮件"
+            ATTACHMENT_FILE=""
+        fi
+    fi
+fi
+
+# 生成邮件正文（包含文档内容）
+BODY_HTML=$(generate_body_html "$REQ_ID" "$NOTIFY_TYPE" "$TIMESTAMP" "$EXTRA_MESSAGE" "$DOC_PATH" "$DOC_CONTENT")
+
+# 显示发送信息
+echo "=========================================="
+echo "📧 发送需求通知邮件"
+echo "=========================================="
+echo "需求编号: $REQ_ID"
+echo "通知类型: $NOTIFY_TYPE ($(get_type_desc "$NOTIFY_TYPE"))"
+echo "邮件主题: $SUBJECT"
+echo "附件: $(if [ -n "$ATTACHMENT_FILE" ]; then echo "$DOC_FILENAME"; else echo "无"; fi)"
+echo "收件人列表 (${#RECIPIENTS[@]} 人):"
+for email in "${RECIPIENTS[@]}"; do
+    echo "  📬 $email"
+done
+echo "=========================================="
+
+# 发送邮件
+SUCCESS_COUNT=0
+FAIL_COUNT=0
+
+for RECIPIENT in "${RECIPIENTS[@]}"; do
+    RECIPIENT=$(echo "$RECIPIENT" | tr -d ' ')
+
+    if [ -z "$RECIPIENT" ]; then
+        continue
+    fi
+
+    if send_email_with_attachment "$RECIPIENT" "$SUBJECT" "$BODY_HTML" "$ATTACHMENT_FILE" "$DOC_FILENAME"; then
+        echo "✅ 已发送: $RECIPIENT"
+        ((SUCCESS_COUNT++))
+    else
+        echo "❌ 发送失败: $RECIPIENT"
+        ((FAIL_COUNT++))
+    fi
+done
+
+# 显示结果
+echo "=========================================="
+echo "📊 发送完成"
+echo "  ✅ 成功: $SUCCESS_COUNT"
+echo "  ❌ 失败: $FAIL_COUNT"
+echo "  🕐 时间: $TIMESTAMP"
+echo "=========================================="
+
+if [ $FAIL_COUNT -gt 0 ]; then
+    echo "部分邮件发送失败，请检查 ~/.msmtp.log"
+    exit 1
+fi
+
+exit 0
--- a/skills-req/req-plugin/prd-review-guide.md
+++ b/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 设计不合理 | 重新设计并说明理由 |
+| 范围过大 | 需求范围过大难以实现 | 拆分为多个小需求 |
+| 验收不明 | 缺少验收标准 | 补充可验证的验收条件 |
--- a/skills-req/req-plugin/siyuan-integration.md
+++ b/skills-req/req-plugin/siyuan-integration.md
@@ -0,0 +1,50 @@
+# 思源笔记集成
+
+需求的 5 阶段文档统一存储到思源笔记中。
+
+## 文档结构
+
+```
+需求管理/
+└── REQ-2026-XXXX/
+    ├── 01-PRD.md                 # 产品需求文档
+    ├── 02-开发设计.md            # 开发技术文档
+    ├── 03-测试报告.md            # 测试验收报告
+    ├── 04-发布记录.md            # CI/CD发布记录
+    └── 05-生命周期总结.md        # 需求归档总结
+```
+
+## 同步命令
+
+```bash
+/req sync-siyuan REQ-2026-0007
+```
+
+## 自动同步时机
+
+| 阶段 | 触发命令 | 同步文档 |
+|------|---------|---------|
+| PRD 完成 | `/req review` | 01-PRD.md |
+| 开发完成 | `/req test` | 02-开发设计.md |
+| 测试完成 | `/req deploy` | 03-测试报告.md |
+| 发布完成 | 发布任务完成 | 04-发布记录.md |
+| 归档完成 | `/req done` | 05-生命周期总结.md (全量同步) |
+
+## MCP 工具调用
+
+```python
+# 创建文档
+mcp__siyuan__createDocWithMd(
+    notebook="需求管理",
+    path="/REQ-2026-0007/01-PRD",
+    markdown=prd_content
+)
+```
+
+## 配置
+
+环境变量（可选）：
+```bash
+export SIYUAN_URL="http://100.118.62.18:6806"
+export SIYUAN_TOKEN="your-token"
+```
--- a/skills-req/req-plugin/skills/SKILL.md
+++ b/skills-req/req-plugin/skills/SKILL.md
@@ -0,0 +1,384 @@
+---
+name: req
+description: 需求工作流管理。用于 /req 命令使用、需求全生命周期管理（创建→PRD→评审→开发→测试→部署→归档）。当用户提到需求管理、/req 命令、REQ-XXX 相关任务时自动激活。
+arguments: <subcommand> [args]
+---
+
+# req - 需求工作流管理
+
+需求全流程工作流管理，与 ai-proj CLI 深度集成。
+
+## 需求生命周期
+
+**审批状态**（status）：
+```
+draft ──[讨论]──► draft(已讨论) ──[PRD]──► pending ──[pass]──► approved ──► archived
+          │                                    │
+      与 AI 讨论                           [reject]
+      明确方案                                 ▼
+                                           rejected
+```
+
+**开发阶段**（delivery_stage，approved 后启用）：
+```
+analysis → design → dev → review → testing → [待部署池] → released
+  评审       评审    开发   代码评审   测试    等待批量部署   已上线
+```
+
+**部署模型**：各需求独立走到 testing → 进入待部署池；`/req deploy` 一次构建批量推进到 released。
+
+## ⭐ 关键约束
+
+- **需求创建后，必须与 AI 进行一次需求讨论**，明确方案后再编写 PRD
+- **讨论结束后必须输出方案确认摘要**（强制流程：讨论 → 摘要 → 用户确认 → PRD）：
+  1. AI 输出结构化摘要（`## 讨论结论` 章节），`ai-proj req update` 追加到 description 末尾
+  2. AskUserQuestion 确认：「方案确认通过」或「需要修改」
+  3. **用户确认后才能开始 PRD 编写，禁止跳过确认**
+- 需求描述三段式（技术方案写入 PRD，不写在需求中）：
+  1. **需求描述** — 问题背景、现状痛点
+  2. **预期结果** — 期望达到的效果
+  3. **验收标准** — 可检查的完成条件（checklist，≥2 条）
+- PRD 文档是提交评审的前置条件；代码评审是测试的前置条件
+- **force=true 禁止自动使用** — 门禁未通过时必须 AskUserQuestion 确认 + 记录跳过原因
+- **评审必须用户确认** — 禁止 AI 自审批
+- **归档前门禁检查** — `/req done` 按需求类型（code/skill/ops）动态检查
+- **部署是项目级动作**，由 `/req deploy` 统一触发
+- **需求完成后必须 git 提交并 push** — commit 格式：`feat(skill): REQ-XXXX 需求标题`
+- **操作前先确认实际 ID** — 从 URL 提取 ID（如 `/requirements/897` → ID=897）
+- **务实路线关闭也必须补全关联任务** — 每个进度条阶段需创建关联任务
+- **阶段内容门禁（防空转）** — `/req next` 时检查关键阶段任务是否有实质内容
+
+## 禁止直接调用（必须走命令流程）
+
+| 禁止直接调用 | 必须通过 | 原因 |
+|-------------|---------|------|
+| `ai-proj req create` with allowSelfApprove | `/req new` | 禁止自动提交，必须创建为 draft |
+| `ai-proj req submit` (直接调用) | `/req submit` | 必须先通过 4 道门禁检查 |
+| `ai-proj req archive` | `/req done` | 必须先执行类型化门禁检查 |
+| `ai-proj req approve` | `/req review pass` | 必须先展示 PRD 摘要并等待用户确认 |
+| `ai-proj req advance --to <stage>` (force) | `/req next` | 必须先 AskUserQuestion 确认 + 记录跳过原因 |
+
+## 需求创建强制规则
+
+```bash
+# ✅ 正确：传完整业务字段
+ai-proj req create \
+  --title "需求标题" \
+  --description "## 需求描述\n...\n## 预期结果\n...\n## 验收标准\n..." \
+  --priority medium \
+  --category feature \
+  --due-date "2026-03-15"
+# → 结果必定是 draft 状态
+```
+
+### 从 draft 到 submit 的 4 道门禁
+
+```
+Gate 1: 需求讨论 ── description 末尾有「## 讨论结论」章节
+Gate 2: 方案确认 ── AskUserQuestion 获得「方案确认通过」
+Gate 3: PRD 文档 ── linkRole=prd 的任务存在且有文档
+Gate 4: 完整性检查 ── 三段式完整 + 验收标准 ≥ 2 条 + PRD 存在
+```
+
+## 完整工作流
+
+```
+1.  /req new         → 创建需求 (draft)
+2.  需求讨论         → 输出结论摘要，用户确认
+3.  req-prd 技能     → 编写 PRD（创建【评审】PRD 任务）
+4.  /req submit      → 提交评审 (pending)，含 4 道门禁
+5.  /req review pass → 评审通过 (approved, delivery_stage=analysis)
+6.  /req next        → 推进到 design/dev 阶段
+7.  /req dev         → 启动开发（创建【开发】任务, delivery_stage=dev）
+8.  /req next        → 推进到 review 阶段
+9.  /req cr          → 代码评审（创建【代码评审】任务）
+10. /req next        → 推进到 testing 阶段
+11. /req test        → 测试验收（5-Gate 流程）
+12. /req deploy      → 批量部署（DG1-DG6 Deploy Gates）
+13. /req done        → 归档 (archived) + git commit + push
+```
+
+**5 阶段文档**：
+
+| 阶段 | 文档名 | 技能 |
+|------|--------|------|
+| PRD | 01-PRD.md | `req-prd` |
+| 测试 | 02-测试报告.md | 自动生成 |
+| 发布 | 03-发布记录.md | 自动生成 |
+| 归档 | 04-生命周期总结.md | 自动生成 |
+
+## 任务命名规范
+
+| linkRole | 前缀 | 示例 |
+|----------|------|------|
+| prd | 【评审】 | 【评审】PRD: 用户认证功能 |
+| design | 【评审】 | 【评审】技术设计: 数据模型 |
+| implementation | 【开发】 | 【开发-后端】实现 API |
+| code_review | 【代码评审】 | 【代码评审】CR: 代码审查 |
+| test | 【测试】 | 【测试】集成测试验证 |
+| deploy | 【部署】 | 【部署】部署到 staging |
+| documentation | 【文档】 | 【文档】API 文档更新 |
+
+## 阶段内容门禁（防空转）
+
+`/req next` 推进时，对关键阶段检查任务**是否有实质内容**（文档附件）：
+
+| 离开阶段 | 检查标准 |
+|----------|---------|
+| **review** | CR 任务有文档，字数 ≥ 500，含 `file:line` 代码引用，含五视角扫描结果，含结论章节 |
+| **testing** | 测试任务有文档，含测试结果表格，含通过/失败结论 |
+| **staging** | 部署任务有文档，含健康检查结果 |
+
+未通过 → AskUserQuestion（补充文档 or 强制跳过+记录原因）
+
+### CR 五视角扫描法
+
+**核心原则**：实现阶段关注"怎么让它跑通"，评审阶段关注"怎么让它出错"。AI 必须**切换到对抗性思维**，逐一用以下 5 个视角扫描代码。
+
+| 视角 | 思维模式 | 扫描问题 |
+|------|---------|---------|
+| **1. 攻击者** | "我怎么绕过/滥用它？" | 跨租户数据泄露、越权访问、参数注入、重放攻击 |
+| **2. 泄露者** | "它暴露了什么不该暴露的？" | 错误消息泄露信息、日志记录敏感数据、响应包含内部细节 |
+| **3. 并发者** | "两个请求同时来会怎样？" | 竞态条件、双重扣款、幂等性缺失、锁粒度 |
+| **4. 边界者** | "极端输入会怎样？" | 空值/零值/负值/超长字符串、类型溢出、分页越界 |
+| **5. 依赖者** | "外部服务挂了会怎样？" | 超时处理、重试策略、降级方案、连接泄露 |
+
+**每个视角的具体扫描清单**：
+
+#### 视角1: 攻击者（多租户安全）
+- [ ] 所有 Store 层查询是否带 `tenant_id` 过滤？（特别是通过 ID 直接查询的方法）
+- [ ] 用户只能操作自己的数据？（consumer_id 校验）
+- [ ] URL/请求参数是否有注入风险？（SQL、URL、命令注入）
+- [ ] 外部输入是否直接拼接到查询/URL？（应使用参数化查询或编码）
+
+#### 视角2: 泄露者（信息安全）
+- [ ] 错误消息是否泄露业务状态？（如"手机号未注册"暴露用户存在性）
+- [ ] 日志是否打印了密码、token、密钥？
+- [ ] 响应是否包含不必要的内部字段？（如内部 ID、数据库字段名）
+
+#### 视角3: 并发者（数据一致性）
+- [ ] 涉及金额变更是否使用事务 + 悲观锁？
+- [ ] 关键操作是否有幂等保护？（bizNo 唯一索引）
+- [ ] 全局状态（如进程内计数器）重启后是否安全？
+
+#### 视角4: 边界者（健壮性）
+- [ ] 必填参数是否有 binding:"required" 校验？
+- [ ] 数值参数是否有范围校验？（min/max）
+- [ ] 分页参数是否有默认值和上限？
+
+#### 视角5: 依赖者（可靠性）
+- [ ] HTTP 客户端是否设置超时？
+- [ ] 外部 API 调用失败是否有合理的错误处理？
+- [ ] token 类型是否可区分？（access vs refresh 不同过期策略）
+
+### CR 报告模板
+
+```markdown
+## 代码评审报告 - {需求标题}
+日期: YYYY-MM-DD
+评审范围: {N} 个文件, {M} 行变更
+
+### 变更概要
+{1-3 句描述}
+
+### 五视角扫描结果
+
+#### 1. 攻击者视角
+{扫描发现，或 "未发现问题"}
+
+#### 2. 泄露者视角
+{扫描发现，或 "未发现问题"}
+
+#### 3. 并发者视角
+{扫描发现，或 "未发现问题"}
+
+#### 4. 边界者视角
+{扫描发现，或 "未发现问题"}
+
+#### 5. 依赖者视角
+{扫描发现，或 "未发现问题"}
+
+### 审查发现汇总
+| 严重度 | 文件:行号 | 视角 | 描述 | 建议 |
+|--------|----------|------|------|------|
+| {Critical/High/Medium/Low} | {file:line} | {攻击者/泄露者/...} | {问题} | {建议} |
+
+### 测试覆盖
+| 测试类型 | 数量 | 状态 |
+|----------|------|------|
+| ... | ... | ... |
+
+### 结论
+{通过 / 有条件通过 / 需修改}
+```
+
+## 命令参考
+
+### 撰写命令
+
+**`/req new [标题]`** — 对话式创建需求（仅 draft）
+- 参数：`--priority=high|medium|low`，`--project=<name>`，`--category=feature|bug|improvement`
+- 流程：描述→提取关键信息→用户故事→验收标准→`ai-proj req create`→ Gate 1 需求讨论
+
+**`/req draft <描述>`** — 一句话快速创建 draft，AI 自动补全
+
+**`/req edit [REQ-ID]`** — 编辑需求：`ai-proj req get` → 询问修改点 → `ai-proj req update` → 显示变更摘要
+
+**`/req check [REQ-ID]`** — 完整性检查（Gate 4）：
+```
+✅ 三段式结构完整 / ✅ 验收标准: 4 条 / ✅ 讨论结论已记录 / ❌ PRD 文档缺失
+```
+
+**`/req split [REQ-ID]`** — 拆分为开发任务（后端/前端/测试）并关联
+
+### 提交评审
+
+**`/req submit [REQ-ID]`** ⭐ — 从 draft 到 pending 的唯一合法路径：
+1. Gate 1: description 末尾有「## 讨论结论」
+2. Gate 2: 讨论结论经过用户确认
+3. Gate 3: 有 linkRole=prd 任务且附有文档
+4. Gate 4: 执行 `/req check` 全部通过
+5. → `ai-proj req submit --id <id>` → 展示 PRD 摘要 → 等待评审
+
+**`/req review pass [REQ-ID]`** — 评审通过（必须用户明确确认后才调用 `ai-proj req approve --id <id>`）
+
+**`/req review reject [REQ-ID] [原因]`** — 评审驳回，必须提供原因
+
+### 阶段管理
+
+**`/req` 或 `/req list`** — 按状态分组列出所有需求（`ai-proj req list`）
+
+**`/req status [REQ-ID]`** — 查看需求详情（`ai-proj req get --id <id>`）、进度、关联任务
+
+**`/req next [REQ-ID]`** — 推进到下一阶段：
+1. 检查当前阶段任务完成度
+2. 智能跳阶段检测（无 implementation 任务时建议跳过 review/testing）
+3. `ai-proj req advance --id <id> --to <stage>`（门禁检查，未通过→AskUserQuestion，**禁止 AI 自动 force**）
+4. ⭐ 内容门禁检查（review/testing/staging 阶段）
+5. 自动创建目标阶段建议任务
+6. 展示：「✅ 已创建: #XXXX {任务名}。如需撤销请说明」
+
+**阶段顺序**：`analysis → design → dev → review → testing → [待部署池] → released`
+
+**`/req resume [REQ-ID]`** — 会话断点恢复：`ai-proj req get --id <id>` 获取 delivery_stage + 任务状态 + 建议操作
+
+### 开发命令
+
+**`/req dev [REQ-ID]`** — 启动开发：
+1. `ai-proj req tasks --id <id>` 找 implementation 任务
+2. `ai-proj task start --id <task_id>` 更新任务状态为开发中
+3. `/pr start` 从 origin/main 建分支
+
+**`/req cr [REQ-ID]`** — 代码评审（前置：开发任务完成）：
+1. `ai-proj req tasks --id <id>` 确认所有 implementation 任务已完成
+2. `git diff` / `find` 确定变更范围（文件数、行数）
+3. 读取所有变更文件源码（非 test 文件）
+4. **五视角扫描**：逐一用攻击者/泄露者/并发者/边界者/依赖者视角审查
+5. `ai-proj task create` 创建【代码评审】任务并关联需求（linkRole=code_review）
+6. `ai-proj create-and-attach` 附加 CR 报告文档（必须含五视角扫描结果）
+7. 展示发现摘要，AskUserQuestion 确认是否创建 bug 修复任务
+8. 若有 High/Critical 发现 → `ai-proj task create` 创建关联修复任务
+
+**`/req test [REQ-ID]`** — 测试（前置：代码评审通过），遵循 dev-test 技能的 5-Gate 流程
+
+**`/req deploy [--project <name>] [--env <env>]`** — 项目级批量部署：
+1. 收集待部署需求（delivery_stage=testing + 全 test 任务 completed）
+2. AskUserQuestion 确认范围
+3. `ai-proj task create` 创建部署批次任务
+4. Deploy Gates DG1-DG6：staging 部署 → 冒烟测试 → 回归 → 生产部署
+5. `ai-proj task append-doc` 记录部署文档
+6. `ai-proj req advance --id <id> --to released` 批量推进
+
+**`/req done [REQ-ID]`** — 类型化归档门禁 + git commit + push + `ai-proj req archive --id <id>`：
+- **推断类型**：有 implementation → code；无 implementation 有 prd/test → skill；仅 deploy → ops
+- **code 检查**：delivery_stage=released + deploy 任务完成 + 部署文档 + 所有任务完成
+- **skill 检查**：delivery_stage≥testing + 所有任务完成
+- **ops 检查**：deploy 任务完成 + 所有任务完成
+
+### PRD 文档创建（通过任务中转）
+
+```bash
+# create-and-attach 只支持任务 ID（task_documents 外键约束）
+# 1. 创建任务
+ai-proj task create --title "【评审】PRD: 用户认证功能"
+
+# 2. 关联需求
+ai-proj req link --id 711 --task-ids 5214
+
+# 3. 附加文档到任务
+ai-proj task append-doc --id 5214 --content "# PRD: 用户认证功能\n..."
+```
+
+### 阶段任务 Checklist
+
+| 阶段 | 建议任务 | linkRole |
+|------|----------|----------|
+| analysis | 【评审】PRD: {需求标题} | prd |
+| design | 【评审】技术设计: {需求标题} | design |
+| dev | 【开发-后端】{需求标题}、【开发-前端】{需求标题} | implementation |
+| review | 【代码评审】{需求标题} | code_review |
+| testing | 【测试】集成测试: {需求标题} | test |
+| deploy | 由 `/req deploy` 批量创建 | deploy |
+
+## 测试环境流程
+
+```
+[本机] → 通过 → [预发布] → 通过 → [生产]
+   ↑                │              │
+   └────────────────┴─── 失败 ─────┘
+```
+
+## 任务关联规范
+
+| link_role | 阶段前缀 | 所属阶段 | 进度权重 |
+|-----------|----------|----------|----------|
+| prd | 【评审】 | analysis | 10% |
+| design | 【评审】 | design | 5% |
+| implementation | 【开发】 | dev | 50% |
+| code_review | 【代码评审】 | review | 5% |
+| test | 【测试】 | testing | 15% |
+| deploy | 【部署】 | staging/released | 10% |
+| documentation | 【文档】 | any | 5% |
+
+## 标准任务结构
+
+```
+需求 REQ-xxx
+├── 📝 analysis  → 【评审】PRD: {需求标题}                    (linkRole: prd)
+├── 📐 design    → 【评审】技术设计: {需求标题}               (linkRole: design)
+├── 💻 dev       → 【开发-后端】、【开发-前端】{描述}          (linkRole: implementation)
+├── 🔍 review    → 【代码评审】CR: {需求标题}                 (linkRole: code_review)
+├── 🧪 testing   → 【测试】集成测试: {需求标题}               (linkRole: test)
+├── 🚀 staging   → 【部署】部署到 staging                     (linkRole: deploy)
+└── 🏁 released  → 【部署】部署到 prod                        (linkRole: deploy)
+```
+
+## ai-proj CLI 速查
+
+```bash
+# 需求操作
+ai-proj req list                          # 列出需求
+ai-proj req get --id <id>                 # 查看详情
+ai-proj req create --title "..." ...      # 创建需求
+ai-proj req update --id <id> ...          # 更新需求
+ai-proj req submit --id <id>              # 提交评审
+ai-proj req approve --id <id>             # 批准需求
+ai-proj req advance --id <id> --to <stage> # 推进阶段
+ai-proj req link --id <id> --task-ids ... # 关联任务
+ai-proj req tasks --id <id>               # 查看关联任务
+```
+
+## 有效值
+
+**审批状态**: `draft`, `pending`, `reviewing`, `approved`, `rejected`, `archived`
+
+**开发阶段**: `backlog`, `analysis`, `design`, `dev`, `review`, `integration`, `testing`, `staging`, `released`
+
+**linkRole**: `prd`, `design`, `implementation`, `code_review`, `test`, `deploy`, `regression`, `documentation`
+
+## 相关技能
+
+| 技能 | 用途 |
+|------|------|
+| `req-prd` | PRD 文档编写 + 评审方法论 |
+| `dev-test` | 测试 + 质量门禁 |
--- a/skills-req/req-plugin/test-guide.md
+++ b/skills-req/req-plugin/test-guide.md
@@ -0,0 +1,177 @@
+# 测试环境流程指南
+
+> 测试必须按照以下环境顺序依次进行，每个环境通过后才能进入下一个环境。
+
+## 测试环境流程
+
+```
+[1] 本机环境 ─── 通过 ──→ [2] 预发布环境 ─── 通过 ──→ [3] 生产环境
+      │                        │                        │
+      ↓ 失败                   ↓ 失败                   ↓ 失败
+  修复并重测              回到步骤[1]              回到步骤[1]
+```
+
+## 项目环境配置表
+
+| 项目 | 本机环境 | 预发布环境 | 生产环境 |
+|------|---------|-----------|---------|
+| ai-proj | localhost:3000/8080 | staging.ai.pipexerp.com | ai.pipexerp.com |
+| coolbuy-paas | localhost | fnos 测试环境 | 39.106.88.83:8888 |
+| coolbuy-platform | localhost | fnos 测试环境 | 生产服务器 |
+
+## 第一阶段：本机测试环境
+
+> ⚠️ **关键约束**：本机测试必须全部通过，才能部署到 staging 环境。
+
+**测试内容**：
+- 单元测试 - 测试单个函数/方法，Mock 外部依赖
+- 集成测试 - 测试模块间交互，使用测试数据库
+- 功能验证 - 验证功能逻辑正确性
+- **前端截图验证** - 使用 chrome-dev MCP 截图确认 UI 显示正确
+
+### 后端测试
+
+```bash
+# Go 后端单元测试
+go test ./... -v
+
+# 指定模块测试
+go test ./backend/handlers/... -v
+go test ./backend/services/... -v
+```
+
+### 前端截图验证（⚠️ 必须步骤）
+
+> **重要**：前端改动必须通过截图验证，不能只测后端 API。这一步经常被忽略，导致功能未正确显示。
+
+**验证流程**：
+
+1. **确保本机服务运行**
+   ```bash
+   # 终端1：后端
+   cd backend && go run main.go
+
+   # 终端2：前端
+   cd frontend && npm start
+   ```
+
+2. **使用 chrome-dev MCP 截图验证**
+   ```python
+   # 步骤1：导航到目标页面
+   mcp__chrome-dev__navigate_page(url="http://localhost:3000/requirements/686")
+
+   # 步骤2：等待页面加载完成（可选）
+   mcp__chrome-dev__wait_for(selector=".requirement-detail")
+
+   # 步骤3：截图
+   mcp__chrome-dev__take_screenshot()
+
+   # 步骤4：检查截图中功能是否正确显示
+   # - 新增的列/字段是否显示
+   # - 样式是否正确
+   # - 数据是否正确渲染
+   ```
+
+3. **常见验证场景**
+   | 改动类型 | 验证页面 | 检查项 |
+   |---------|---------|--------|
+   | 列表新增列 | 列表页面 | 新列是否显示、数据是否正确 |
+   | 表单新增字段 | 表单页面 | 字段是否显示、能否正常输入 |
+   | 样式调整 | 相关页面 | 样式是否生效、布局是否正确 |
+   | 权限控制 | 相关页面 | 按钮/菜单是否正确显示/隐藏 |
+
+4. **截图保存**
+   - 截图应保存到测试任务文档中作为验证记录
+   - 命名规范：`REQ-XXXXX-本机测试-功能名称.png`
+
+### 前端截图验证示例
+
+```
+/req test REQ-20260125-0002
+
+→ 检查代码评审... ✓ 已完成
+→ 验证开发任务... ✓ 已完成
+
+=== 本机测试阶段 ===
+
+1. 后端单元测试
+   → go test ./backend/handlers/requirement_handler_test.go -v
+   → ✓ 3/3 测试通过
+
+2. 前端截图验证
+   → 启动 chrome-dev MCP...
+   → 导航到: http://localhost:3000/requirements/687
+   → 截图验证...
+   → ✓ 任务ID列正确显示 (#5284 格式)
+   → ✓ 列宽度和样式正确
+   → 截图已保存
+
+=== 本机测试通过 ===
+→ 可以执行: /req deploy REQ-20260125-0002 --env staging
+```
+
+### 通过标准
+
+- [ ] 所有后端单元测试通过
+- [ ] **前端截图验证通过**（有前端改动时必须）
+- [ ] 功能在本地环境正常运行
+- [ ] 无控制台错误
+- [ ] 截图已保存到测试文档
+
+### 跳过前端验证
+
+仅当改动不涉及前端时，可使用 `--backend-only` 参数：
+
+```bash
+/req test REQ-XXXXX --backend-only
+```
+
+## 第二阶段：预发布环境
+
+**测试内容**：
+- E2E 测试 - 测试完整用户流程
+- 跨浏览器测试 - Chrome、Firefox、Safari
+- 性能测试 - 页面加载时间、API 响应时间
+
+**通过标准**：
+- [ ] 功能在预发布环境正常运行
+- [ ] 与生产环境配置一致
+- [ ] 无跨环境兼容性问题
+
+## 第三阶段：生产环境
+
+**测试内容**：
+- UAT 验收 - 用户验收测试
+- 冒烟测试 - 核心功能快速验证
+- 回归测试 - 确保未破坏现有功能
+
+**通过标准**：
+- [ ] 功能在生产环境正常运行
+- [ ] 用户验收通过
+- [ ] 无生产环境特有问题
+
+## API 验证清单
+
+```bash
+# 1. 本机环境
+curl -s "http://localhost:8080/api/v1/requirements?search=REQ-2026" \
+  -H "Authorization: Bearer $TOKEN" | jq '.data | length'
+
+# 2. 预发布环境
+curl -s "https://staging.ai.pipexerp.com/api/v1/requirements?search=REQ-2026" \
+  -H "X-API-Key: $SYNC_REMOTE_API_KEY" | jq '.data | length'
+
+# 3. 生产环境
+curl -s "https://ai.pipexerp.com/api/v1/requirements?search=REQ-2026" \
+  -H "X-API-Key: $SYNC_REMOTE_API_KEY" | jq '.data | length'
+```
+
+## 测试失败处理
+
+| 失败阶段 | 处理方式 |
+|---------|---------|
+| 本机测试 | 修复代码，重新运行本机测试 |
+| 预发布测试 | 修复代码，重新从本机测试开始 |
+| 生产环境测试 | 修复代码，重新从本机测试开始 |
+
+> 任何阶段测试失败，修复后必须从本机测试环境重新开始。
--- a/skills-req/req-plugin/update-siyuan-release.sh
+++ b/skills-req/req-plugin/update-siyuan-release.sh
@@ -0,0 +1,142 @@
+#!/bin/bash
+# REQ 发布记录自动更新脚本
+# 用于在发布完成后自动更新思源笔记中的发布记录
+
+# 思源笔记配置
+SIYUAN_URL="${SIYUAN_URL:-http://100.118.62.18:6806}"
+SIYUAN_TOKEN="${SIYUAN_TOKEN:-nfnycjb1g8vbexb2}"
+
+# 使用方法
+usage() {
+    echo "Usage: $0 -r <REQ-ID> -d <doc-id> [-v <version>] [-e <env>] [-s <status>]"
+    echo ""
+    echo "Options:"
+    echo "  -r REQ-ID     需求编号 (如 REQ-2026-0007)"
+    echo "  -d doc-id     思源笔记文档 ID"
+    echo "  -v version    发布版本号 (默认: v1.0.0)"
+    echo "  -e env        发布环境 (默认: production)"
+    echo "  -s status     发布状态: success|failed (默认: success)"
+    echo "  -h            显示帮助"
+    exit 1
+}
+
+# 解析参数
+REQ_ID=""
+DOC_ID=""
+VERSION="v1.0.0"
+ENVIRONMENT="production"
+STATUS="success"
+
+while getopts "r:d:v:e:s:h" opt; do
+    case $opt in
+        r) REQ_ID="$OPTARG" ;;
+        d) DOC_ID="$OPTARG" ;;
+        v) VERSION="$OPTARG" ;;
+        e) ENVIRONMENT="$OPTARG" ;;
+        s) STATUS="$OPTARG" ;;
+        h) usage ;;
+        *) usage ;;
+    esac
+done
+
+# 验证必需参数
+if [ -z "$REQ_ID" ] || [ -z "$DOC_ID" ]; then
+    echo "Error: -r 和 -d 参数是必需的"
+    usage
+fi
+
+# 获取当前时间
+TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
+DATE=$(date "+%Y-%m-%d")
+
+# 状态显示
+if [ "$STATUS" = "success" ]; then
+    STATUS_ICON="✅"
+    STATUS_TEXT="已发布"
+else
+    STATUS_ICON="❌"
+    STATUS_TEXT="发布失败"
+fi
+
+# 生成追加内容
+APPEND_CONTENT=$(cat <<EOF
+
+---
+
+## 发布记录更新 - $TIMESTAMP
+
+| 项目 | 内容 |
+|------|------|
+| 发布版本 | $VERSION |
+| 发布环境 | $ENVIRONMENT |
+| 发布时间 | $TIMESTAMP |
+| 发布状态 | $STATUS_ICON $STATUS_TEXT |
+
+### 自动化流程执行记录
+
+- $STATUS_ICON 代码构建完成
+- $STATUS_ICON 服务部署完成
+- $STATUS_ICON 健康检查通过
+- $STATUS_ICON 邮件通知已发送
+
+> 此记录由 REQ 需求管理系统自动生成
+
+EOF
+)
+
+# 创建临时 JSON 文件
+TMP_FILE=$(mktemp)
+
+# 首先获取现有文档内容
+echo "正在获取文档内容..."
+EXISTING_CONTENT=$(curl -s -X POST "$SIYUAN_URL/api/block/getBlockKramdown" \
+    -H "Authorization: Token $SIYUAN_TOKEN" \
+    -H "Content-Type: application/json" \
+    -d "{\"id\": \"$DOC_ID\"}" | jq -r '.data.kramdown // ""')
+
+if [ -z "$EXISTING_CONTENT" ]; then
+    echo "Warning: 无法获取现有文档内容，将创建新内容"
+    EXISTING_CONTENT="# 发布记录\n\n## 文档信息\n\n| 属性 | 值 |\n|------|----|\n| 需求编号 | $REQ_ID |"
+fi
+
+# 追加新内容
+NEW_CONTENT="${EXISTING_CONTENT}${APPEND_CONTENT}"
+
+# 转义特殊字符用于 JSON
+ESCAPED_CONTENT=$(echo "$NEW_CONTENT" | jq -Rs '.')
+
+# 创建更新请求 JSON
+cat > "$TMP_FILE" <<EOF
+{
+    "id": "$DOC_ID",
+    "dataType": "markdown",
+    "data": $ESCAPED_CONTENT
+}
+EOF
+
+# 更新文档
+echo "正在更新思源笔记文档..."
+RESPONSE=$(curl -s -X POST "$SIYUAN_URL/api/block/updateBlock" \
+    -H "Authorization: Token $SIYUAN_TOKEN" \
+    -H "Content-Type: application/json" \
+    -d @"$TMP_FILE")
+
+# 清理临时文件
+rm -f "$TMP_FILE"
+
+# 检查结果
+CODE=$(echo "$RESPONSE" | jq -r '.code')
+
+if [ "$CODE" = "0" ]; then
+    echo "发布记录更新成功"
+    echo "  需求: $REQ_ID"
+    echo "  文档 ID: $DOC_ID"
+    echo "  版本: $VERSION"
+    echo "  环境: $ENVIRONMENT"
+    echo "  状态: $STATUS_TEXT"
+    exit 0
+else
+    MSG=$(echo "$RESPONSE" | jq -r '.msg')
+    echo "发布记录更新失败: $MSG"
+    exit 1
+fi
--- a/skills-req/req-plugin/workflow-example.md
+++ b/skills-req/req-plugin/workflow-example.md
@@ -0,0 +1,120 @@
+# 完整开发工作流示例
+
+以「酷采3.0 标签管理模块」为例的完整需求生命周期。
+
+## 第一步：创建需求
+
+```bash
+/req new 酷采3.0 商品标签管理模块
+```
+
+执行：`mcp__ai-proj__create_requirement` → 自动分配 display_id（如 REQ-2026-0006）
+
+## 第二步：编写 PRD 文档
+
+调用 `req-prd` 技能：
+1. 创建 PRD 任务并关联到需求
+2. 调用 `mcp__ai-proj__create-and-attach` 写入 PRD 文档
+
+## 第三步：创建开发子任务
+
+```python
+# 创建子任务
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：数据模型设计")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：Store/Biz实现")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="后端：API Handler实现")
+mcp__ai-proj__create_subtask(parentId=PRD任务ID, title="前端：页面开发")
+
+# 批量关联到需求
+mcp__ai-proj__link_tasks_to_requirement(requirementId=需求ID, taskIds=[...])
+```
+
+## 第四步：提交并审批需求
+
+```bash
+/req review          # draft → pending
+/req review pass     # pending → approved
+```
+
+## 第五步：执行开发任务
+
+```bash
+/req dev REQ-2026-0006
+```
+
+按分层架构开发：Model → Store → Biz → Handler → Router
+
+## 第六步：代码评审
+
+```bash
+/req cr REQ-2026-0006
+```
+
+开发完成后必须进行代码评审，评审通过后才能进入测试。
+
+## 第七步：创建测试任务
+
+```python
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="后端：单元测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="后端：集成测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="E2E：端到端测试")
+mcp__ai-proj__create_subtask(parentId=测试父任务, title="UAT：用户验收测试")
+```
+
+## 第八步：执行测试
+
+```bash
+/req test REQ-2026-0006
+```
+
+按环境顺序：本机 → 预发布 → 生产
+
+## 第九步：CI/CD 发布
+
+```bash
+/req deploy REQ-2026-0006 --env staging
+```
+
+## 第十步：完成归档
+
+```bash
+/req done REQ-2026-0006
+```
+
+自动生成需求生命周期总结文档，归档需求。
+
+---
+
+## 标准任务结构
+
+```
+需求: REQ-2026-XXXX
+├── PRD 任务 (父任务，包含 PRD 文档)
+│   ├── 后端：数据模型设计 (implementation)
+│   ├── 后端：业务层实现 (implementation)
+│   ├── 后端：API 实现 (implementation)
+│   └── 前端：页面开发 (implementation)
+│
+├── 代码评审任务 (code_review) ← 必须步骤
+│
+├── 测试任务 (父任务)
+│   ├── 单元测试 (test)
+│   ├── 集成测试 (test)
+│   ├── E2E测试 (test)
+│   └── UAT验收 (test, 包含测试报告)
+│
+└── 发布任务 (父任务，包含发布记录)
+    ├── Docker 镜像构建 (deploy)
+    ├── 前端资源构建 (deploy)
+    └── 部署到环境 (deploy)
+```
+
+## 5 阶段文档
+
+| 序号 | 文档 | 阶段 |
+|------|------|------|
+| 01 | PRD | 需求定义 |
+| 02 | 开发设计 | 开发实现 |
+| 03 | 测试报告 | 测试验收 |
+| 04 | 发布记录 | CI/CD部署 |
+| 05 | 生命周期总结 | 归档 |
--- a/skills-req/req-prd-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-prd-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-prd-plugin",
+  "description": "Plugin for req-prd",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-prd-plugin/skills/SKILL.md
+++ b/skills-req/req-prd-plugin/skills/SKILL.md
@@ -0,0 +1,659 @@
+---
+name: req-prd
+description: 产品设计与需求管理。用于 PRD 文档编写、需求分析、用户故事创建、功能设计和原型规划。当用户提到产品设计、PRD、需求文档、功能规划、用户故事相关任务时自动激活。
+---
+
+# 产品需求设计 Skill (req-prd)
+
+## 概述
+
+本技能用于辅助产品设计和需求管理工作，包括：
+- PRD 文档编写与管理
+- **参考对象对比式 PRD 编写**（核心能力）
+- 需求分析与优先级排序
+- 用户故事创建
+- 功能设计与规划
+- 与 ai-proj 任务系统集成
+
+---
+
+## 参考对象对比式 PRD 编写
+
+当进行**系统平移、功能迁移、竞品借鉴**时，应采用对比分析法编写 PRD，确保新系统功能完整且有所改进。
+
+### 适用场景
+
+| 场景 | 说明 | 示例 |
+|------|------|------|
+| 系统平移 | 旧系统迁移到新技术栈 | 酷采2.0 → 酷采3.0 |
+| 功能借鉴 | 参考竞品功能设计 | 参考飞书设计协作功能 |
+| 版本升级 | 基于当前版本优化 | V1.0 → V2.0 重构 |
+
+### 对比分析工作流
+
+```
+1. 确定参考对象
+   ├── 识别参考系统（可以是多个）
+   ├── 获取访问权限（测试环境、源代码）
+   └── 明确对比目标
+
+2. 参考对象分析
+   ├── 功能调研（前端页面操作）
+   ├── 数据模型分析（数据库表结构）
+   ├── 业务逻辑分析（后端代码）
+   └── API 接口分析
+
+3. 对比分析
+   ├── 功能对比表（保留/优化/新增/废弃）
+   ├── 数据模型对比（字段映射、新增字段）
+   ├── 技术架构对比
+   └── 用户体验对比
+
+4. PRD 编写
+   ├── 背景说明（明确参考来源）
+   ├── 功能需求（标注来源与变更）
+   ├── 数据设计（标注字段来源）
+   └── 实现建议
+```
+
+### 对比式 PRD 模板
+
+```markdown
+# [功能模块名称] PRD
+
+## 1. 文档概述
+
+### 1.1 文档信息
+| 项目 | 内容 |
+|------|------|
+| 文档名称 | [模块名称] 需求文档 |
+| 版本 | V1.0 |
+| 创建日期 | [日期] |
+| **需求来源** | **[参考系统名称] 平移/借鉴** |
+| **参考系统** | **[参考系统访问地址]** |
+
+### 1.2 背景说明
+本需求文档基于 **[参考系统]** 的 [模块名称] 功能分析，将其平移至 [目标系统]。
+
+**参考系统信息**：
+- 系统地址：[URL]
+- 技术栈：[技术栈描述]
+- 源码位置：[源码路径]（如有）
+
+---
+
+## 2. 参考系统分析
+
+### 2.1 功能截图
+[插入参考系统功能截图]
+
+### 2.2 数据模型（参考系统）
+```sql
+-- 参考系统表结构
+CREATE TABLE [表名] (
+  -- 从源代码/数据库提取
+);
+```
+
+### 2.3 API 接口（参考系统）
+| 接口 | 方法 | 说明 |
+|------|------|------|
+| /api/xxx | GET/POST | [描述] |
+
+### 2.4 业务逻辑（参考系统）
+- 核心业务规则摘要
+- 数据校验规则
+- 状态流转逻辑
+
+---
+
+## 3. 功能对比分析
+
+### 3.1 功能对比表
+| 序号 | 功能 | 参考系统 | 目标系统 | 变更类型 | 说明 |
+|------|------|----------|----------|----------|------|
+| 1 | [功能1] | ✅ | ✅ | 保留 | 直接平移 |
+| 2 | [功能2] | ✅ | ✅+ | 优化 | [优化内容] |
+| 3 | [功能3] | ❌ | ✅ | 新增 | [新增原因] |
+| 4 | [功能4] | ✅ | ❌ | 废弃 | [废弃原因] |
+
+### 3.2 数据模型对比
+| 参考系统字段 | 目标系统字段 | 类型 | 变更 | 说明 |
+|--------------|--------------|------|------|------|
+| id (varchar) | id (bigint) | PK | 优化 | 改用自增ID |
+| company_id | tenant_id | FK | 重命名 | 统一租户字段 |
+| -- | created_by | bigint | 新增 | 审计字段 |
+
+### 3.3 技术架构对比
+| 层次 | 参考系统 | 目标系统 |
+|------|----------|----------|
+| 后端框架 | [如: Spring Boot] | [如: Go Gin] |
+| 前端框架 | [如: Vue 2] | [如: React 18] |
+| 数据库 | [如: MySQL] | [如: PostgreSQL] |
+
+---
+
+## 4. 目标系统设计
+
+### 4.1 功能清单
+| 序号 | 功能 | 优先级 | 来源 | 说明 |
+|------|------|--------|------|------|
+| 1 | [功能] | P0 | 平移 | 从参考系统平移 |
+
+### 4.2 数据模型（目标系统）
+```sql
+-- 目标系统表结构（基于对比分析设计）
+CREATE TABLE [表名] (
+  id BIGINT PRIMARY KEY,
+  -- 字段设计...
+);
+```
+
+### 4.3 API 设计（目标系统）
+| 接口 | 方法 | 说明 | 参考接口 |
+|------|------|------|----------|
+| /api/v1/xxx | GET | [描述] | 参考 /api/xxx |
+
+### 4.4 业务规则
+- [ ] 规则1（沿用参考系统）
+- [ ] 规则2（优化调整）
+
+---
+
+## 5. 实现建议
+
+### 5.1 开发顺序
+1. 数据模型迁移
+2. 后端 API 实现
+3. 前端页面开发
+4. 数据迁移脚本
+
+### 5.2 注意事项
+- 参考系统中 [xxx] 逻辑需要特别注意
+- 新系统中需改进 [xxx] 问题
+```
+
+---
+
+### 参考对象分析工具
+
+#### 1. 前端分析
+```bash
+# 启动浏览器调试模式（macOS）
+/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
+  --remote-debugging-port=9222 \
+  --user-data-dir=/tmp/chrome-debug
+
+# 访问参考系统，截图、分析交互
+```
+
+#### 2. 后端代码分析
+```bash
+# 搜索相关模型
+grep -r "class.*Model" --include="*.java" /path/to/legacy/
+
+# 搜索相关控制器
+grep -r "@Controller\|@RestController" --include="*.java" /path/to/legacy/
+```
+
+#### 3. 数据库分析
+```sql
+-- 查看表结构
+SHOW CREATE TABLE table_name;
+
+-- 查看字段注释
+SELECT COLUMN_NAME, COLUMN_COMMENT
+FROM information_schema.COLUMNS
+WHERE TABLE_NAME = 'table_name';
+```
+
+---
+
+### 示例：酷采3.0标签管理模块
+
+以下是基于酷采2.0平移的标签管理模块对比分析示例：
+
+#### 参考系统（酷采2.0）
+
+**数据模型**：
+```sql
+-- 酷采2.0 prd_product_label 表
+CREATE TABLE `prd_product_label` (
+  `id` varchar(64) NOT NULL,
+  `label_name` varchar(256) DEFAULT NULL,
+  `company_id` varchar(64) DEFAULT NULL,
+  `input_user_id` varchar(64) DEFAULT NULL,
+  `input_user_name` varchar(64) DEFAULT NULL,
+  `input_time` datetime DEFAULT NULL,
+  `update_user_id` varchar(64) DEFAULT NULL,
+  `update_user_name` varchar(64) DEFAULT NULL,
+  `update_time` datetime DEFAULT NULL,
+  `version` bigint(20) DEFAULT 0,
+  `is_delete` tinyint(1) DEFAULT 0,
+  `status` tinyint(1) DEFAULT 1,
+  `remark` varchar(512) DEFAULT NULL,
+  `sort_no` int(11) DEFAULT 0,
+  PRIMARY KEY (`id`)
+);
+```
+
+**代码位置**：
+- 后端: `cool_lining/module-provider/.../dao/model/prd/PrdProductLabel.java`
+- 前端: `ln_admin/src/views/module/prd/product_label/`
+
+#### 目标系统（酷采3.0）设计
+
+**数据模型对比**：
+| 酷采2.0 | 酷采3.0 | 变更 |
+|---------|---------|------|
+| id (varchar) | id (bigint) | 改用自增ID |
+| company_id | tenant_id | 统一租户标识 |
+| input_user_id | created_by | 简化字段命名 |
+| input_time | created_at | 统一时间字段 |
+| is_delete | deleted_at | 改用软删除时间戳 |
+
+---
+
+## PRD 文档模板
+
+### 标准 PRD 结构
+
+```markdown
+# [产品/功能名称] PRD
+
+## 1. 概述
+### 1.1 背景
+[为什么需要这个功能？解决什么问题？]
+
+### 1.2 目标
+- 业务目标：[量化的业务指标]
+- 用户目标：[用户能获得什么价值]
+- 技术目标：[技术层面要达成什么]
+
+### 1.3 成功指标
+| 指标 | 当前值 | 目标值 | 衡量方式 |
+|------|--------|--------|----------|
+| ... | ... | ... | ... |
+
+## 2. 用户分析
+### 2.1 目标用户
+[用户画像描述]
+
+### 2.2 用户痛点
+1. [痛点1]
+2. [痛点2]
+
+### 2.3 用户场景
+[场景描述]
+
+## 3. 功能需求
+### 3.1 功能清单
+| 功能 | 优先级 | 描述 | 验收标准 |
+|------|--------|------|----------|
+| ... | P0/P1/P2 | ... | ... |
+
+### 3.2 功能详细说明
+#### [功能1]
+- 功能描述：
+- 触发条件：
+- 业务规则：
+- 异常处理：
+
+## 4. 交互设计
+### 4.1 用户流程
+[流程图或步骤描述]
+
+### 4.2 界面原型
+[原型链接或描述]
+
+## 5. 技术要求
+### 5.1 性能要求
+- 响应时间：
+- 并发量：
+- 数据量：
+
+### 5.2 安全要求
+- 权限控制：
+- 数据安全：
+
+### 5.3 兼容性要求
+- 浏览器：
+- 设备：
+
+## 6. 上线计划
+### 6.1 里程碑
+| 阶段 | 内容 | 完成标准 |
+|------|------|----------|
+| ... | ... | ... |
+
+### 6.2 灰度策略
+[灰度发布计划]
+
+## 7. 风险评估
+| 风险 | 影响 | 概率 | 应对措施 |
+|------|------|------|----------|
+| ... | 高/中/低 | 高/中/低 | ... |
+
+## 8. 附录
+- 相关文档链接
+- 参考资料
+```
+
+---
+
+## 需求优先级框架
+
+### RICE 评分法
+
+| 维度 | 说明 | 评分范围 |
+|------|------|----------|
+| Reach (触达) | 影响多少用户 | 1-10 |
+| Impact (影响) | 对用户的影响程度 | 0.25-3 |
+| Confidence (信心) | 估算的置信度 | 0-100% |
+| Effort (工作量) | 需要的人天数 | 实际工作量 |
+
+**计算公式**: `RICE = (Reach × Impact × Confidence) / Effort`
+
+### 优先级定义
+
+| 优先级 | 含义 | 处理方式 |
+|--------|------|----------|
+| P0 | 阻塞性需求 | 必须立即处理 |
+| P1 | 核心需求 | 本迭代必须完成 |
+| P2 | 重要需求 | 尽量本迭代完成 |
+| P3 | 优化需求 | 有余力时处理 |
+
+---
+
+## 用户故事编写
+
+### 标准格式
+
+```
+作为 [用户角色]，
+我想要 [功能/目标]，
+以便 [获得的价值/原因]。
+
+验收标准：
+- Given [前置条件]
+- When [用户行为]
+- Then [预期结果]
+```
+
+### 示例
+
+```
+作为 仓库管理员，
+我想要 扫码快速入库，
+以便 提高入库效率、减少手动输入错误。
+
+验收标准：
+- Given 已有采购单且货物到达
+- When 扫描货物条码
+- Then 自动匹配采购单并显示入库确认界面
+```
+
+### INVEST 原则检查
+
+| 原则 | 含义 | 检查点 |
+|------|------|--------|
+| I - Independent | 独立的 | 故事间无依赖 |
+| N - Negotiable | 可协商 | 非固定规格 |
+| V - Valuable | 有价值 | 交付业务价值 |
+| E - Estimable | 可估算 | 能估算工作量 |
+| S - Small | 足够小 | 可在迭代内完成 |
+| T - Testable | 可测试 | 有明确验收标准 |
+
+---
+
+## 与 ai-proj 集成
+
+### 需求管理工具
+
+使用 ai-proj MCP 工具管理需求：
+
+```bash
+# 创建需求
+mcp__ai-proj__create_requirement
+  - title: "需求标题"
+  - description: "需求描述"
+  - category: feature/bug/improvement/documentation/other
+  - priority: low/medium/high
+  - projectId: 项目ID
+
+# 查看需求列表
+mcp__ai-proj__list_requirements
+  - status: draft/pending/reviewing/approved/rejected/archived
+  - priority: low/medium/high
+
+# 需求与任务关联
+mcp__ai-proj__link_tasks_to_requirement
+  - requirementId: 需求ID
+  - taskIds: [任务ID列表]
+```
+
+### 任务分解流程
+
+1. **创建需求** → `create_requirement`
+2. **需求评审** → `submit_requirement` → `approve/reject_requirement`
+3. **分解任务** → `create_task` / `create_subtask`
+4. **关联任务** → `link_tasks_to_requirement`
+5. **跟踪进度** → `get_requirement_tasks` / `get_requirement_statistics`
+
+### 文档管理
+
+```bash
+# 创建 PRD 文档并关联任务
+mcp__ai-proj__create-and-attach
+  - taskId: 任务ID
+  - content: PRD 文档内容 (Markdown)
+  - title: 文档标题 (可选)
+
+# 更新 PRD 文档
+mcp__ai-proj__update_task_document
+  - taskId: 任务ID
+  - content: 更新后的内容
+
+# 导出 PRD 到文件
+mcp__ai-proj__export_task_document_to_file
+  - taskId: 任务ID
+```
+
+---
+
+## 功能设计流程
+
+### 1. 需求收集
+
+```
+输入：
+- 用户反馈
+- 业务需求
+- 数据分析
+- 竞品分析
+
+输出：
+- 需求池（ai-proj 需求列表）
+```
+
+### 2. 需求分析
+
+```
+方法：
+- 5W1H 分析法
+- 用户访谈
+- 数据验证
+
+输出：
+- 需求文档
+- 优先级排序
+```
+
+### 3. 方案设计
+
+```
+内容：
+- 功能架构
+- 交互流程
+- 界面原型
+- 技术方案
+
+输出：
+- PRD 文档
+- 原型设计
+```
+
+### 4. 评审验证
+
+```
+评审维度：
+- 业务价值
+- 技术可行性
+- 资源评估
+- 风险评估
+
+输出：
+- 评审结论
+- 修改意见
+```
+
+---
+
+## 竞品分析模板
+
+### 分析框架
+
+```markdown
+# [竞品名称] 分析
+
+## 1. 产品概述
+- 定位：
+- 核心功能：
+- 目标用户：
+
+## 2. 功能对比
+| 功能 | 我们 | 竞品A | 竞品B |
+|------|------|-------|-------|
+| 功能1 | ✅/❌/部分 | ... | ... |
+
+## 3. 优劣势分析
+### 优势
+1. ...
+
+### 劣势
+1. ...
+
+## 4. 可借鉴点
+- ...
+
+## 5. 差异化策略
+- ...
+```
+
+---
+
+## 产品指标体系
+
+### 北极星指标选择
+
+| 产品类型 | 典型北极星指标 |
+|----------|----------------|
+| 电商 | GMV / 订单量 |
+| SaaS | MRR / 活跃用户数 |
+| 社交 | DAU / 消息数 |
+| 工具 | 完成任务数 / 使用时长 |
+
+### 指标分层
+
+```
+北极星指标
+    ├── 一级指标（核心业务指标）
+    │   ├── 二级指标（过程指标）
+    │   │   └── 三级指标（功能指标）
+```
+
+### 常用指标
+
+| 类型 | 指标 | 计算方式 |
+|------|------|----------|
+| 获客 | 新用户数、获客成本 | 注册数 / 推广费用 |
+| 激活 | 激活率、首日留存 | 完成核心动作 / 注册数 |
+| 留存 | 次日/7日/30日留存 | 回访用户 / 新增用户 |
+| 收入 | ARPU、付费率 | 收入 / 用户数 |
+| 传播 | 推荐率、K因子 | 邀请数 / 用户数 |
+
+---
+
+## 设计检查清单
+
+### PRD 完整性检查
+
+- [ ] 背景与目标明确
+- [ ] 用户群体定义清晰
+- [ ] 功能需求完整
+- [ ] 验收标准可测试
+- [ ] 异常情况已考虑
+- [ ] 性能要求已定义
+- [ ] 上线计划合理
+- [ ] 风险已评估
+
+### 交互设计检查
+
+- [ ] 用户流程完整
+- [ ] 边界情况处理
+- [ ] 错误提示友好
+- [ ] 反馈及时
+- [ ] 操作可撤销
+- [ ] 符合用户习惯
+
+### 技术方案检查
+
+- [ ] 技术可行性验证
+- [ ] 性能影响评估
+- [ ] 扩展性考虑
+- [ ] 安全性审查
+- [ ] 兼容性测试
+
+---
+
+## 常用工具
+
+### 原型设计
+- Figma
+- Sketch
+- Axure
+
+### 流程图
+- draw.io
+- ProcessOn
+- Mermaid (Markdown)
+
+### 数据分析
+- Metabase
+- Google Analytics
+- Mixpanel
+
+### 项目管理
+- ai-proj (内部)
+- JIRA
+- Linear
+
+---
+
+## 最佳实践
+
+1. **需求先行** - 先理解问题，再设计方案
+2. **用户视角** - 始终从用户角度思考
+3. **数据驱动** - 用数据验证假设
+4. **迭代优化** - 小步快跑，持续改进
+5. **跨团队协作** - 早期与技术、设计团队对齐
+6. **文档沉淀** - 及时记录决策和变更
+
+---
+
+## 安全与合规
+
+- 用户隐私保护 (GDPR/个人信息保护法)
+- 数据安全分级
+- 敏感操作审计
+- 权限最小化原则
--- a/skills-req/req-review-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-review-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-review-plugin",
+  "description": "PRD 评审方法论。用于需求评审、PRD 文档审查、评审意见编写。当执行 /req review 或需要评审 PRD 文档时使用。",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-review-plugin/skills/SKILL.md
+++ b/skills-req/req-review-plugin/skills/SKILL.md
@@ -0,0 +1,113 @@
+---
+name: req-review
+description: PRD 评审方法论。用于需求评审、PRD 文档审查、评审意见编写。当执行 /req review 或需要评审 PRD 文档时使用。
+---
+
+# PRD 评审方法论
+
+PRD 评审是需求流程的关键质量关卡。
+
+## 评审流程
+
+```
+PRD 提交 → 结构检查 → 清晰度评估 → 技术可行性 → 数据模型 → API 审查 → 结论
+```
+
+## 结构完整性检查
+
+| 检查项 | 必须 | 说明 |
+|--------|:----:|------|
+| 基本信息 | ✓ | 编号、标题、日期、作者 |
+| 需求背景 | ✓ | 为什么需要这个功能 |
+| 目标用户 | ✓ | 面向的用户群体 |
+| 功能描述 | ✓ | 详细功能需求 |
+| 数据模型 | ✓ | 数据库表结构 |
+| API 设计 | ✓ | RESTful 接口 |
+| 验收标准 | ✓ | 验收条件 |
+| 用户故事 | ○ | As a... I want... |
+| 页面原型 | ○ | 界面布局 |
+| 非功能需求 | ○ | 性能、安全 |
+
+## 需求清晰度（SMART 原则）
+
+| 原则 | 检查点 |
+|------|--------|
+| **S**pecific | 描述是否具体明确 |
+| **M**easurable | 是否有量化指标 |
+| **A**chievable | 技术上是否可行 |
+| **R**elevant | 是否与业务目标相关 |
+| **T**ime-bound | 是否有时间范围 |
+
+**示例**：
+- ❌ "用户可以搜索需求"
+- ✅ "用户可按编号精确搜索、按标题模糊搜索、按状态筛选，结果分页显示"
+
+## 技术可行性
+
+| 维度 | 评估内容 |
+|------|----------|
+| 技术栈兼容 | 现有栈是否支持 |
+| 架构影响 | 是否需修改架构 |
+| 第三方依赖 | 是否引入新依赖 |
+| 性能影响 | 潜在性能问题 |
+| 安全考量 | 安全风险 |
+
+## 数据模型验证
+
+| 检查项 | 说明 |
+|--------|------|
+| 表结构 | 字段类型、约束、索引 |
+| 关联关系 | 外键、多对多 |
+| 命名规范 | 符合项目规范 |
+| 扩展性 | 预留扩展字段 |
+| 查询性能 | 常用查询有索引 |
+
+## API 设计审查
+
+| 检查项 | 标准 |
+|--------|------|
+| RESTful | URL 用名词，HTTP 方法语义正确 |
+| 响应格式 | `{success, data, message}` |
+| 错误处理 | 明确的错误码 |
+| 分页 | `?page=1&page_size=20` |
+| 版本控制 | `/api/v1/...` |
+
+## 评审结论模板
+
+**通过**：
+```
+✅ PRD 评审通过
+
+【结论】文档完整，需求清晰，方案可行，建议批准。
+【肯定】需求背景清晰、数据模型合理、API 规范
+【建议】（非阻塞）补充性能测试用例
+【评审人】xxx  【时间】2026-xx-xx
+```
+
+**驳回**：
+```
+❌ PRD 评审驳回
+
+【原因】
+1. 数据模型缺少索引
+2. API 缺少错误处理
+3. 搜索需求描述模糊
+
+【修改要求】
+□ 补充索引设计
+□ 明确错误码
+□ 细化搜索实现
+
+【驳回人】xxx  【时间】2026-xx-xx
+```
+
+## 常见驳回原因
+
+| 类别 | 问题 | 建议 |
+|------|------|------|
+| 结构缺失 | 缺数据模型或 API | 补充技术设计 |
+| 需求模糊 | 描述不具体 | 按 SMART 重写 |
+| 边界不清 | 缺异常处理 | 补充边界条件 |
+| 设计缺陷 | 模型/API 不合理 | 重新设计 |
+| 范围过大 | 难以实现 | 拆分为多需求 |
+| 验收不明 | 缺验收标准 | 补充验收条件 |
--- a/skills-req/req-test-gate-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-test-gate-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-test-gate-plugin",
+  "description": "测试与质量门禁制度。覆盖需求级测试(Gates 1-5，含前后端联调+视觉验证)、部署级验证(Deploy Gates)、持续回归(Regression)。",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-test-gate-plugin/skills/SKILL.md
+++ b/skills-req/req-test-gate-plugin/skills/SKILL.md
@@ -0,0 +1,450 @@
+---
+name: req-test-gate
+description: 测试与质量门禁制度。覆盖需求级测试(Gates 1-5，含前后端联调+视觉验证)、部署级验证(Deploy Gates)、持续回归(Regression)。
+---
+
+# 测试与质量门禁制度 (req-test-gate) v2.1
+
+## 概述
+
+三层质量门禁架构，确保从需求到上线每个阶段都有结构化验证。
+
+**三层架构**：
+```
+需求级 (Gates 1-5)     → /req test 触发，单需求维度
+部署级 (Deploy Gates)   → /req deploy 触发，批量部署维度
+持续维度 (Regression)    → 定时/部署后触发，系统级回归
+```
+
+## 需求级门禁 (Gates 1-5)
+
+**触发时机**：`/req test` 执行、`/req next` 从 testing 推进
+
+```
+Gate 0: Scope 分级（自动，决定后续 Gate 裁剪）
+    ↓
+Gate 1: 前置条件检查（自动）
+    ↓
+Gate 2: 测试执行验证（2A→2B→2C→2D→2E→2F，按 scope 裁剪）
+    ↓
+Gate 3: 测试质量验证（子代理，按 scope 决定是否触发）
+    ↓
+Gate 4: 文档持久化（自动，按 scope 选模板）
+    ↓
+Gate 5: 回归贡献检查（按 scope 区分贡献形式）
+    ↓
+通过 → 允许 /req next 推进到待部署池
+```
+
+## Gate 0: Scope 分级（自动）
+
+**从 `git diff` 自动推断变更范围，决定后续 Gate 的裁剪策略。**
+
+```bash
+# 自动推断逻辑
+git diff main...HEAD --name-only | classify_scope
+```
+
+| scope | 判断依据 | Gate 裁剪效果 |
+|-------|---------|--------------|
+| `backend` | 仅 `.go` 文件变更 | 2A(go) + 2B 必须；2C/2F 跳过 |
+| `frontend` | `.tsx/.ts` 变更（含业务逻辑） | 2A(tsc/build) 必须；2B 跳过 |
+| `style-only` | 仅 `.css/.less` 或 shared/ 变更 | 2A(build) + **2F(视觉验证)** 必须；2B/2C 跳过 |
+| `fullstack` | 前后端都有改动 | 2A + 2B + 2C 全部必须 |
+
+**frontend vs style-only 区分**：`.tsx/.ts` 文件中是否包含 API 调用（`import.*api`、`fetch`、`request`）。仅样式/布局改动归为 style-only。
+
+**scope 影响全部后续 Gate**，在测试报告中必须标注。
+
+---
+
+## Gate 1: 前置条件检查
+
+**自动检查，不可跳过。**
+
+| 检查项 | 检查方式 | 阻塞级别 |
+|--------|---------|----------|
+| CR 已通过 | `delivery_stage >= review` 或有 completed 的 code_review 任务 | 阻塞 |
+| 开发任务全部完成 | 所有 `linkRole=implementation` 的任务状态为 completed | 阻塞 |
+| CR 文档存在（code 类型） | `has_task_document` 对 code_review 任务 | 警告 |
+
+**未通过处理**：
+- 阻塞项 → 直接拒绝，提示「请先完成 {缺失项}」
+- 警告项 → AskUserQuestion 确认是否继续
+
+## Gate 2: 测试执行验证
+
+**按需求类型执行分层测试，从静态到动态逐步验证。**
+
+### 类型推断
+
+从 `get_requirement_tasks` 的 linkRole 集合推断：
+- **code**: 有 `implementation` 任务 → 代码需求
+- **skill**: 无 `implementation`，有 `prd`/`test` → Skill/文档需求
+- **ops**: 仅 `deploy` 任务 → 运维需求
+
+### code 类型：五阶段验证
+
+#### 2A: 静态验证（编译+类型检查）
+
+**按 scope 裁剪执行项：**
+
+| 序号 | 测试项 | 命令 | scope 触发条件 | 通过条件 |
+|------|--------|------|---------------|----------|
+| T1 | 后端编译 | `go build ./...` | backend / fullstack | exit 0 |
+| T2 | 后端单元测试 | `go test ./...` | backend / fullstack | 全部 PASS |
+| T4 | 前端类型检查 | `tsc --noEmit` | frontend / fullstack | exit 0 |
+| T4b | 前端构建 | `vite build` | **所有前端 scope** | 构建成功 |
+| T5 | 前端测试 | `npm test` 相关组件 | frontend / fullstack | PASS |
+| T7 | iOS 编译 | `xcodebuild build` | 有 iOS 改动时 | exit 0 |
+
+**style-only scope**：仅执行 T4b（构建验证），跳过 T1/T2/T4/T5。
+
+#### 2B: API 端点验证（后端独立）
+
+| 序号 | 测试项 | 命令 | 必须 | 通过条件 |
+|------|--------|------|------|----------|
+| T3 | API 端点验证 | `curl localhost:8080` 调用新/改 API | 必须 | 预期状态码和数据 |
+| T3.1 | DB 约束验证 | `curl` 测试 FK/唯一约束 | 推荐 | 错误码正确（400/404） |
+| T3.2 | 错误处理验证 | 无效输入/缺失参数 | 推荐 | 错误响应格式正确 |
+| T3.3 | **并发/原子性** | 2 个并发请求竞争边界量（如库存恰好=N，发 2 个各 N 件的请求）| 涉及库存/积分/财务时必须 | 恰好 1 个成功，另一个返回"不足"，DB 无超卖 |
+| T3.4 | **租户隔离** | 用 tenant B token 操作 tenant A 的资源 ID | 多租户系统必须 | 返回 403/无权，DB 未被篡改 |
+| T3.5 | **状态流转完整性** | 触发所有 change_type/状态流转后查流水表 | 有状态机实体时必须 | 所有预期流水类型都出现过 |
+
+> **触发判断（以下任一为真则 T3.3–T3.5 必须执行）：**
+> - 需求涉及库存/积分/余额/限购
+> - 需求有多租户资源隔离要求
+> - 需求引入了新的状态机（status 枚举 ≥ 3 个）
+
+#### 2C: 前后端联调（开发环境）
+
+**触发条件**：scope 为 `fullstack`，或前端 `.tsx/.ts` 文件包含 API 调用（`import.*api`、`fetch`、`request`）
+**不触发**：scope 为 `backend`、`style-only`，或前端改动不涉及 API 调用
+
+**环境要求**：本地开发环境，前端 :3000 + 后端 :8080 同时运行
+
+**前置步骤**：
+1. 确认本地数据库已执行相关 migration（菜单、表结构等）
+2. 启动后端 `cd backend && go run main.go`
+3. 启动前端 `cd frontend && npm start`
+4. 获取 JWT Token（`POST /api/v1/auth/login`）
+
+| 序号 | 测试项 | 方法 | 必须 | 通过条件 |
+|------|--------|------|------|----------|
+| IT1 | 前端代理连通 | `curl localhost:3000/api/v1/health` | 必须 | 200（前端代理到后端成功） |
+| IT2 | 菜单可见性 | `curl localhost:3000/api/v1/menus/user-menus` | 必须 | 新菜单出现在响应中 |
+| IT3 | API 代理验证 | `curl localhost:3000/api/v1/<新端点>` | 必须 | 通过前端代理调用后端 API 返回预期数据 |
+| IT4 | 路由配置 | 检查 App.tsx 有 `<Route path="..." />` | 必须 | 路由存在且 lazy import 正确 |
+| IT5 | 图标映射 | 检查 Layout.tsx iconMap 有对应图标 | 条件 | 有新菜单图标时必须验证 |
+| IT6 | 页面可访问 | 浏览器访问 `localhost:3000/<新路径>` | 推荐 | 页面加载无白屏、无 console 报错 |
+
+**无前端改动时**：标记 `⏭️ 跳过: 无前端改动`。
+
+**常见联调问题及排查**：
+
+| 问题 | 根因 | 解决方案 |
+|------|------|----------|
+| 菜单不显示 | 本地 DB 未执行 menu migration | 执行 migration SQL + 修复 sequence |
+| API 返回 404 | 前端代理路径不匹配 | 检查 `setupProxy.js` 或 `package.json` proxy 配置 |
+| 页面白屏 | React 组件 import 错误或 TS 类型不匹配 | 检查 console 错误，修复 import 路径 |
+| 登录失败 | 本地用户密码不匹配 | 重新生成 bcrypt cost 12 哈希并更新本地 DB |
+| Redis 缓存脏数据 | 菜单/权限缓存未清理 | `redis-cli KEYS "menu:user:*"` 后逐个 DEL |
+
+#### 2D: 冒烟测试（Staging 环境）
+
+**触发条件**：已部署到 staging
+
+| 序号 | 测试项 | 命令 | 必须 | 通过条件 |
+|------|--------|------|------|----------|
+| SM1 | API 健康检查 | `curl staging/api/v1/health` | 必须 | 200 |
+| SM2 | 核心流程验证 | `curl` 新功能关键 API | 必须 | 预期响应 |
+| SM3 | 数据一致性 | 创建→读取→验证 | 推荐 | 数据完整返回 |
+
+**未部署到 staging 时**：标记 `⏭️ 跳过: 未部署到 staging`。
+
+#### 2E: 原型符合性测试
+
+**触发条件**：有关联原型 HTML（`prototype-*.html`）
+
+| 序号 | 测试项 | 方法 | 必须 | 通过条件 |
+|------|--------|------|------|----------|
+| PC1 | 结构完整性 | 对比原型 Section 数 vs 实现区块 | 必须 | 所有 Section 有对应实现 |
+| PC2 | 数据模型对齐 | 对比原型字段 vs API 返回字段 | 必须 | 字段名/类型匹配 |
+| PC3 | 交互流程覆盖 | 对比原型操作 vs 实现事件绑定 | 推荐 | 所有交互有绑定 |
+| PC4 | 状态覆盖 | 对比原型状态标签 vs 实现枚举 | 推荐 | 状态集一致 |
+
+**无原型时**：标记 `⏭️ 跳过: 无关联原型`。
+
+**原型冻结规则**：原型在评审通过后冻结，设计变更需创建新需求。
+
+#### 2F: 视觉/响应式验证（v2.1 新增）
+
+**触发条件**：scope 为 `style-only` 或 `frontend`（有 CSS/LESS 变更时）
+**不触发**：scope 为 `backend`
+
+| 序号 | 测试项 | 方法 | 必须 | 通过条件 |
+|------|--------|------|------|----------|
+| VR1 | 断点一致性 | `grep -rn "max-width\|min-width" --include="*.css" --include="*.less"` 对比 breakpoints 定义 | 必须 | 所有新增 media query 使用标准断点值 |
+| VR2 | 构建无警告 | `vite build` 输出检查 | 必须 | 无 CSS 相关 warning |
+| VR3 | !important 审计 | `grep -c "!important"` 统计新增数量 | 推荐 | 新增 !important ≤ 3 个，或有合理理由 |
+| VR4 | 文件完整性 | 新增组件/样式文件全部存在 | 必须 | 所有 import 的文件可解析 |
+| VR5 | 移动端适配 | 检查关键页面在 ≤768px 下的 CSS 规则覆盖 | 推荐 | 有对应的移动端样式 |
+
+**无 CSS 变更时**：标记 `⏭️ 跳过: 无样式改动`。
+
+### skill 类型 Checklist
+
+| 序号 | 测试项 | 方法 | 必须 |
+|------|--------|------|------|
+| S1 | 关键词一致性 | `grep` 核心概念跨文件对齐 | 必须 |
+| S2 | 规则无歧义 | 审查每条规则触发条件和动作 | 必须 |
+| S3 | 边界情况 | 至少 1 个边界场景验证 | 必须 |
+| S4 | 交叉引用 | 文件间引用指向正确 | 推荐 |
+| S5 | Token 大小 | `wc -w` < 7500 词 | 推荐 |
+
+### ops 类型 Checklist
+
+| 序号 | 测试项 | 方法 | 必须 |
+|------|--------|------|------|
+| O1 | 命令可执行 | dry-run 或 staging 执行 | 必须 |
+| O2 | 健康检查 | `curl` 健康端点 | 必须 |
+| O3 | 回滚方案 | 文档审查 | 推荐 |
+
+### UAT 场景设计（复杂业务需求适用）
+
+当需求涉及以下任一情况时，在 2B 之后额外执行 UAT 场景矩阵：
+- 完整业务流程（下单→支付→发货→退款）
+- 并发控制（乐观锁/悲观锁/原子 SQL）
+- 多角色协作（消费者 + 管理员 + 供应商）
+
+**执行方式**：参照 [uat-patterns.md](uat-patterns.md) 的 5 类场景框架逐一设计用例，用 ai-proj 创建 stage="testing" 的子任务跟踪进度。
+
+### 执行记录格式
+
+```
+| T1 | 后端编译 | `go build ./...` | ✅ PASS | exit 0, 0 errors |
+| IT1 | 前端代理连通 | `curl localhost:3000/api/v1/health` | ✅ PASS | 200 |
+| IT2 | 菜单可见性 | user-menus API | ✅ PASS | 持续管理+2子菜单 |
+| SM1 | 健康检查 | `curl staging/health` | ✅ PASS | 200 |
+| PC1 | 结构完整性 | 原型 11 sections vs 实现 | ⏭️ 跳过 | 无关联原型 |
+```
+
+## Gate 3: 测试质量验证（子代理）
+
+派遣 test-validator 子代理审查。模板: `~/.claude/skills/req-test-gate/test-validator.md`
+
+**触发规则（按 scope 裁剪）**：
+- code + `backend` / `fullstack`：**总是触发**
+- code + `frontend`（含业务逻辑）：**触发**
+- code + `style-only`：**不触发**（CR 已覆盖样式审查）
+- skill 类型：**≥5 测试项时触发**
+- ops 类型：**不触发**
+
+```typescript
+Task({
+  subagent_type: "superpowers:code-reviewer",
+  prompt: `使用 test-validator 模板审查测试质量。
+    模板路径: ~/.claude/skills/req-test-gate/test-validator.md
+    填充参数:
+    - REQUIREMENT_TITLE: "{需求标题}"
+    - REQUIREMENT_TYPE: "{code|skill|ops}"
+    - TEST_RESULTS: "{Gate 2 的执行记录表格}"
+    - CODE_CHANGES_SUMMARY: "{改动文件列表和摘要}"
+    - CHECKLIST_USED: "{使用的 checklist 类型}"
+  `
+})
+```
+
+| 评估结果 | 处理 |
+|---------|------|
+| "测试充分" | Gate 3 通过 |
+| "需补充测试"(Important) | AskUserQuestion 确认 |
+| "测试不足"(Critical) | 阻塞，必须补充后重新验证 |
+
+## Gate 4: 文档持久化
+
+**不可跳过。** `create-and-attach` 写入测试任务文档。**按 scope 选择模板。**
+
+### 轻量模板（scope = style-only / frontend 无 API）
+
+```markdown
+## 测试报告 - {需求标题}
+
+| 字段 | 值 |
+|------|-----|
+| 需求 | REQ-XXXX |
+| scope | {style-only/frontend} |
+| 门禁版本 | test-gate v2.1 |
+
+### 构建验证
+| 项目 | 命令 | 结果 |
+|------|------|------|
+| TypeScript | tsc --noEmit | ✅/❌/⏭️ |
+| Vite Build | vite build | ✅/❌ |
+
+### 视觉验证 (2F)
+| 序号 | 测试项 | 结果 | 备注 |
+|------|--------|------|------|
+| VR1 | 断点一致性 | ✅/❌ | ... |
+| VR2 | 构建无警告 | ✅/❌ | ... |
+| VR4 | 文件完整性 | ✅/❌ | ... |
+
+### 总结
+通过: {N}/{M} | 结论: ✅ 通过 / ❌ 未通过
+```
+
+### 完整模板（scope = backend / fullstack）
+
+```markdown
+## 测试报告 - {需求标题}
+
+| 字段 | 值 |
+|------|-----|
+| 需求 | REQ-XXXX |
+| 类型 | {code/skill/ops} |
+| 时间 | {YYYY-MM-DD HH:MM} |
+| 门禁版本 | test-gate v2 |
+
+### 前置条件 (Gate 1)
+- CR 状态: ✅ 已通过
+- 开发任务: ✅ 全部完成 ({N}/{N})
+
+### 测试执行 (Gate 2)
+| 序号 | 阶段 | 测试项 | 命令/方法 | 结果 | 备注 |
+|------|------|--------|----------|------|------|
+| T1 | 2A | 后端编译 | ... | ✅/❌/⏭️ | ... |
+| IT1 | 2C | 前端代理连通 | ... | ✅/❌/⏭️ | ... |
+| SM1 | 2D | 健康检查 | ... | ✅/❌/⏭️ | ... |
+| PC1 | 2E | 结构完整性 | ... | ✅/❌/⏭️ | ... |
+
+### 跳过的测试
+⏭️ {测试项}: {原因}
+（无则写「无」）
+
+### 质量验证 (Gate 3)
+{子代理结果摘要，或「未触发（ops 类型）」}
+
+### 回归贡献 (Gate 5)
+{贡献的回归用例数，或「无需贡献」或「⏭️ 跳过: 过渡期」}
+
+### 总结
+通过: {N}/{M} | 跳过: {K} | 结论: ✅ 通过 / ❌ 未通过
+```
+
+### 文档质量门禁（被 `/req next` 检查）
+
+- 含测试项表格（`|` 分隔符 ≥ 3 行）
+- 含通过/失败结论（`✅ 通过` 或 `❌ 未通过`）
+- 总字符数 ≥ 200
+- 门禁版本标记（`test-gate v2` 或 `test-gate v2.1`）
+
+## Gate 5: 回归贡献检查
+
+**确保 code 类型需求为回归池贡献测试用例。按 scope 区分贡献形式。**
+
+**触发条件**：code 类型需求
+
+| 检查项 | 说明 | 阻塞级别 |
+|--------|------|----------|
+| 有 regression linkRole 任务 | `get_requirement_tasks(linkRole=regression)` | 警告 |
+| 任务有文档附件 | `has_task_document` | 警告 |
+| 文档包含可执行用例 | 含 `curl` 命令或测试脚本 | 建议 |
+
+**过渡期规则（v2.1）**：警告但不阻塞，AskUserQuestion 提醒补充。
+
+### Scope 贡献形式
+
+| scope | 贡献形式 | 示例 |
+|-------|---------|------|
+| `backend` | curl 脚本（API 回归） | `curl -X POST .../api` → 201 |
+| `frontend` | E2E 场景描述（Playwright） | 页面加载 + 核心交互验证 |
+| `style-only` | 视觉回归 checklist | 断点覆盖 + !important 审计 |
+| `fullstack` | curl 脚本 + E2E 场景 | 两者都需要 |
+
+### 回归用例模板（backend / fullstack）
+
+```markdown
+## 回归用例 - REQ-XXXX {需求标题}
+
+### 模块
+{okr / task / auth / ...}
+
+### 用例列表
+| ID | 场景 | 命令 | 预期结果 | 优先级 |
+|----|------|------|----------|--------|
+| RC1 | ... | `curl ...` | 200 + ... | 高 |
+```
+
+### 回归用例模板（frontend / style-only）
+
+```markdown
+## 回归用例 - REQ-XXXX {需求标题}
+
+### 模块
+{product / order / layout / ...}
+
+### 视觉/交互用例
+| ID | 场景 | 验证方法 | 预期结果 | 优先级 |
+|----|------|---------|----------|--------|
+| VRC1 | 移动端列表布局 | 浏览器 375px 宽度截图 | 卡片正常排列 | 高 |
+| VRC2 | 响应式断点切换 | 768px→769px 切换 | 布局无跳变 | 中 |
+```
+
+详见 [regression.md](regression.md) 了解完整回归系统设计。
+
+## 部署级门禁 (Deploy Gates)
+
+**触发时机**：`/req deploy` 执行
+
+详见 [deploy-gates.md](deploy-gates.md)
+
+概要流程：
+```
+DG1: 迁移检查（不可跳过） → 有未执行 migration?
+DG2: Staging 部署 → 构建+部署到 singapore
+DG3: 冒烟测试 → 核心 API 可用
+DG4: 影响域回归 → module-deps 决定范围
+DG5: 性能基线（推荐） → 关键 API 响应时间
+DG6: 生产部署（不可跳过） → 健康检查+文档
+```
+
+## 回归测试模块
+
+**系统级持续活动，独立于单需求生命周期。**
+
+详见 [regression.md](regression.md)
+
+核心概念：
+- **回归池**：所有需求贡献的测试用例汇集处
+- **回归判定**：上次 PASS + 本次 FAIL = 回归（高优先级，自动创建 bug 需求）
+- **闭环**：回归失败 → 创建 bug 需求 → 修复 → 回归池更新
+- **三种执行模式**：影响域（部署触发）、关键路径（每日）、全量（每周）
+
+## Force 跳过规则
+
+| 门禁 | 可否 Force | 说明 |
+|------|-----------|------|
+| Gate 1 前置条件 | **不可** | 必须满足 |
+| Gate 2 测试执行 | 单项可跳过 | 需记录原因 |
+| Gate 3 质量验证 | Critical 不可，Important 可 | AskUserQuestion 后跳过 |
+| Gate 4 文档持久化 | **不可** | 必须生成文档 |
+| Gate 5 回归贡献 | 可（过渡期） | 警告级别 |
+| Deploy Gates | DG1/DG6 不可，其余可 | 迁移和健康检查不可跳过 |
+
+## 与现有流程集成
+
+### `/req test` 增强
+
+```
+v1: Gate 1 → Gate 2 → Gate 3 → Gate 4
+v2:   Gate 1 → Gate 2(2A→2B→2C→2D→2E) → Gate 3 → Gate 4 → Gate 5
+v2.1: Gate 0(scope) → Gate 1 → Gate 2(2A→2B→2C→2D→2E→2F，按scope裁剪) → Gate 3 → Gate 4 → Gate 5
+```
+
+### `/req next` testing→staging 门禁
+
+验证测试文档：Gate 1-5 全部通过的完整报告 + 门禁版本 `test-gate v2`
+
+### `/req deploy` 部署门禁
+
+在 req-deploy 流程前增加 Deploy Gates (DG1-DG6) 检查。
--- a/skills-req/req-workflow-plugin/.claude-plugin/plugin.json
+++ b/skills-req/req-workflow-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "req-workflow-plugin",
+  "description": "需求完整工作流。用于从创建到归档的完整流程、Hook 自动同步、测试环境流程。当需要了解需求完整生命周期或同步策略时使用。",
+  "version": "1.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/req-workflow-plugin/skills/SKILL.md
+++ b/skills-req/req-workflow-plugin/skills/SKILL.md
@@ -0,0 +1,198 @@
+---
+name: req-workflow
+description: 需求完整工作流。用于从创建到归档的完整流程、Hook 自动同步、测试环境流程。当需要了解需求完整生命周期或同步策略时使用。
+---
+
+# 需求完整工作流
+
+从 PRD 到归档的完整流程。
+
+## 需求创建环境选择
+
+> **重要**：正式需求应直接在**生产环境** (`mcp__ai-proj-prod__*`) 创建。
+> 仅在功能测试、流程验证时使用开发环境 (`mcp__ai-proj-dev__*`)。
+> 如果在开发环境创建了需求后同步到生产，`due_date`、`reviewer_id`、`allow_self_approve` 等字段会丢失，需手动补充。
+
+## 完整流程概览（阶段化）
+
+```
+1. /req new         → 创建需求 (draft)
+2. req-prd 技能     → 编写 PRD（创建【评审】PRD 任务）
+3. /req review      → 提交评审 (pending)
+4. /req review pass → 评审通过 (approved, delivery_stage=analysis)
+5. /req next        → 推进到 design/dev 阶段
+6. /req dev         → 启动开发（创建【开发】任务, delivery_stage=dev）
+7. req-dev 技能     → 编写开发文档
+8. /req next        → 推进到 review 阶段
+9. /req cr          → 代码评审（创建【代码评审】任务, delivery_stage=review）
+10. /req next       → 推进到 testing 阶段
+11. /req test       → 测试验收（创建【测试】任务, delivery_stage=testing）
+12. /req next       → 推进到 staging 阶段
+13. /req deploy staging  → 部署 staging（创建【部署】任务, delivery_stage=staging）
+14. /req next       → 推进到 released 阶段
+15. /req deploy prod     → 部署生产（创建【部署】任务, delivery_stage=released）
+16. /req done       → 归档 (archived)
+```
+
+**每个阶段都有明确的任务、检查点和交付物，防止遗漏。**
+
+## 5 阶段文档
+
+| 阶段 | 文档名 | 技能 |
+|------|--------|------|
+| PRD | 01-PRD.md | `req-prd` |
+| 开发 | 02-开发设计.md | `req-dev` |
+| 测试 | 03-测试报告.md | 自动生成 |
+| 发布 | 04-发布记录.md | 自动生成 |
+| 归档 | 05-生命周期总结.md | 自动生成 |
+
+## Hook 自动同步
+
+需求操作自动触发同步，无需手动执行：
+
+| 事件 | 触发操作 |
+|------|----------|
+| `requirement.created` | 同步到远程 |
+| `requirement.approved` | 同步需求和任务 |
+| `task.completed` | 同步任务状态 |
+| `requirement.archived` | 最终同步 + 思源笔记 |
+
+**手动同步**（如需）：
+```typescript
+mcp__ai-proj__sync_requirement_to_remote(requirementId)
+mcp__ai-proj__batch_sync_tasks_to_remote(taskIds)
+```
+
+**同步已知限制**：
+| 字段 | 同步支持 | 说明 |
+|------|----------|------|
+| title, description, status, priority | ✅ | 正常同步 |
+| project_id | ✅ | 正常同步 |
+| **due_date** | ❌ | **不会同步**，需手动通过 REST API 在目标环境补充 |
+| reviewer_id | ❌ | 不会同步 |
+| allow_self_approve | ❌ | 不会同步 |
+
+> **经验教训**（2026-02-20）：`sync_requirement_to_remote` 不同步 `due_date` 字段。同步后务必在目标环境验证并手动补充缺失字段。
+
+## 测试环境流程
+
+**必须按顺序执行，任何阶段失败后从本机重新开始**：
+
+```
+[本机] → 通过 → [预发布] → 通过 → [生产]
+   ↑                 │              │
+   └─────────────────┴──── 失败 ────┘
+```
+
+| 环境 | 用途 | 验证方式 |
+|------|------|----------|
+| 本机 | 开发调试 | `go test ./...` |
+| 预发布 | 集成测试 | API 验证 |
+| 生产 | 最终验收 | API + 功能验证 |
+
+## 任务关联规范
+
+创建任务时设置 `link_role` 并加阶段前缀：
+
+| link_role | 阶段前缀 | 所属阶段 | 权重 |
+|-----------|----------|----------|------|
+| prd | 【评审】 | analysis | 10% |
+| design | 【评审】 | design | 5% |
+| implementation | 【开发】 | dev | 50% |
+| code_review | 【代码评审】 | review | 5% |
+| test | 【测试】 | testing | 15% |
+| deploy | 【部署】 | staging/released | 10% |
+| documentation | 【文档】 | any | 5% |
+
+**进度计算**：按 link_role 权重统计已完成任务。
+
+## 标准任务结构（阶段化）
+
+```
+需求 REQ-xxx
+├── 📝 analysis 阶段
+│   └── 【评审】PRD: {需求标题}                    (linkRole: prd)
+├── 📐 design 阶段
+│   └── 【评审】技术设计: {需求标题}                (linkRole: design)
+├── 💻 dev 阶段
+│   ├── 【开发-后端】{描述}                        (linkRole: implementation)
+│   └── 【开发-前端】{描述}                        (linkRole: implementation)
+├── 🔍 review 阶段
+│   └── 【代码评审】CR: {需求标题}                  (linkRole: code_review)
+├── 🧪 testing 阶段
+│   └── 【测试】集成测试: {需求标题}                (linkRole: test)
+├── 🚀 staging 阶段
+│   └── 【部署】部署到 staging (singapore)          (linkRole: deploy)
+└── 🏁 released 阶段
+    ├── 【部署】部署到 prod (tools_ai_proj)         (linkRole: deploy)
+    └── 【验收】功能验收确认                        (linkRole: documentation)
+```
+
+**命名规则**：所有任务标题必须以阶段前缀开头（如【评审】、【开发】、【部署】）。
+
+## 环境配置
+
+**双环境 MCP 配置**：区分开发测试和生产环境
+
+```json
+// ~/.claude/.mcp.json
+{
+  "mcpServers": {
+    "ai-proj-dev": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["/path/to/mcp-task-bridge/dist/index.js"],
+      "env": {
+        "TASK_API_BASE": "http://localhost:8080/api/v1",
+        "TASK_API_TOKEN": "aiproj_pk_xxx...",
+        "NODE_ENV": "development"
+      }
+    },
+    "ai-proj-prod": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["/path/to/mcp-task-bridge/dist/index.js"],
+      "env": {
+        "TASK_API_BASE": "https://ai.pipexerp.com/api/v1",
+        "TASK_API_TOKEN": "aiproj_pk_xxx...",
+        "NODE_ENV": "production"
+      }
+    }
+  }
+}
+```
+
+**环境使用指南**：
+
+| 环境 | 使用场景 | 工具前缀 |
+|------|----------|----------|
+| `ai-proj-dev` | 功能测试、流程验证、本地调试 | `mcp__ai-proj-dev__*` |
+| `ai-proj-prod` | 正式需求管理、生产数据操作 | `mcp__ai-proj-prod__*` |
+
+**跨机器支持**：
+- `ai-proj-dev` 支持 melbourne 和 adelaide 机器的本地环境（都是 localhost:8080）
+- 无论在哪台开发机器上，都使用 `ai-proj-dev` 连接本地 API
+
+**项目配置**：
+```json
+// .claude/settings.local.json
+{
+  "env": {
+    "REQUIREMENT_PROJECT": "coolbuy-paas"
+  }
+}
+```
+
+## 思源笔记集成
+
+归档时自动同步 5 阶段文档到思源笔记：
+- 路径：`需求管理/REQ-XXXX/`
+- 文档：01-PRD.md ~ 05-生命周期总结.md
+
+手动同步：`/req sync-siyuan [REQ-ID]`
+
+## 邮件通知
+
+发送邮件：`/req notify [REQ-ID] --type <prd|dev|test|deploy|archive>`
+
+默认收件人：项目邮件组（见项目配置）
--- a/skills-req/requirement-plugin/.claude-plugin/plugin.json
+++ b/skills-req/requirement-plugin/.claude-plugin/plugin.json
@@ -0,0 +1,8 @@
+{
+  "name": "requirement-plugin",
+  "description": "[已废弃] 需求撰写功能已合并到 req-plugin。请使用 /req 命令。",
+  "version": "2.0.0",
+  "author": {
+    "name": "qiudl"
+  }
+}
--- a/skills-req/requirement-plugin/skills/SKILL.md
+++ b/skills-req/requirement-plugin/skills/SKILL.md
@@ -0,0 +1,30 @@
+---
+name: requirement
+description: "[已废弃] 请使用 /req 命令。需求撰写功能已合并到 req 技能中。"
+arguments: <subcommand> [args]
+---
+
+# Requirement 技能 - 已合并到 req
+
+> **此技能已废弃。** 所有需求撰写命令已合并到 `req` 技能中。
+
+## 命令迁移对照
+
+| 原命令 | 新命令 | 说明 |
+|--------|--------|------|
+| `/requirement new` | `/req new` | 对话式创建需求（仅创建草稿） |
+| `/requirement draft <描述>` | `/req draft <描述>` | 快速生成需求草稿 |
+| `/requirement edit <ID>` | `/req edit <ID>` | 编辑需求内容 |
+| `/requirement review <ID>` | `/req check <ID>` | 需求完整性检查 |
+| `/requirement split <ID>` | `/req split <ID>` | 拆分为开发任务 |
+| `/requirement history <ID>` | `/req history <ID>` | 查看变更历史 |
+| `/requirement compare <ID>` | `/req compare <ID>` | 版本对比 |
+| `/requirement list` | `/req` 或 `/req list` | 列出需求 |
+
+## 重要变更
+
+- 需求创建后**只能是 draft 状态**，禁止自动提交
+- 从 draft 到提交评审需通过 **4 道门禁**（讨论 → 确认 → PRD → 完整性检查）
+- 提交评审使用 `/req submit`（原 `/req review`）
+
+请使用 `/req` 命令，详细参考见 `req` 和 `req-commands` 技能。