refactor(commands): 优化命令职责划分并统一命名规范

主要变更：

1. 优化 analyze-security 和 plan-task 命令职责：
   - analyze-security：专注信息收集和风险评估，移除方案制定职责
   - plan-task：统一处理所有问题类型，从内容驱动而非类型驱动

2. 统一命令命名规范：
   - 重命名：block/complete/implement/plan/refine/review → block-task/complete-task/implement-task/plan-task/refinement-task/review-task
   - 与 .claude 和 .codex 目录保持一致

3. 完善文档和示例：
   - plan-task 补充 analyze-security 为前序命令
   - review-task 增加安全修复流程示例
   - 更新 .opencode/README.md 的命令列表和工作流示例

Author: CodeCasterX

.claude/commands/analyze-security.md

@@ -1,6 +1,6 @@
 ---
 name: "analyze-security"
-description: "分析 Dependabot 安全告警并创建修复任务"
+description: "分析 Dependabot 安全告警并创建安全分析文档"
 usage: "/analyze-security <alert-number>"
 ---
 
@@ -59,27 +59,18 @@ ghsa_id: <GHSA-ID>
 - [ ] 搜索项目中使用该依赖的所有位置（使用 Grep 工具）
 - [ ] 检查依赖文件（pom.xml, requirements.txt, package.json 等）
 - [ ] 分析是否直接使用了漏洞代码路径
-- [ ] 评估漏洞的实际影响（是否可被利用）
 - [ ] 识别依赖关系（直接依赖 vs 传递依赖）
+- [ ] 定位受影响的代码模块和文件
 
-### 4. 制定修复方案
-
-根据漏洞严重程度和修复难度制定方案：
-
-**优先方案**：
-1. **升级到安全版本**
-   - 检查是否有修复版本
-   - 评估升级的兼容性风险
-   - 检查是否有破坏性变更
-
-2. **替换依赖**（如果无法升级）
-   - 寻找替代库
-   - 评估迁移成本
+### 4. 评估安全风险
 
-3. **缓解措施**（临时方案）
-   - 配置调整
-   - 代码层面的防护
-   - 网络隔离等
+**必须完成的风险评估**：
+- [ ] 评估漏洞的实际影响（是否可被利用）
+- [ ] 分析漏洞触发条件和场景
+- [ ] 评估对系统安全性的影响程度
+- [ ] 识别潜在的安全威胁
+- [ ] 确定修复的紧急程度
+- [ ] 查找是否有已知的攻击案例
 
 ### 5. 输出分析文档
 
@@ -95,64 +86,53 @@ ghsa_id: <GHSA-ID>
 - **GHSA ID**: {ghsa-id}
 - **CVE ID**: {cve-id}
 - **告警状态**: {open/dismissed/fixed}
+- **漏洞描述**: {描述}
 
 ## 漏洞详情
 
-### 漏洞描述
-{详细描述漏洞的性质和攻击方式}
-
 ### 受影响的依赖
 - **包名**: {package-name}
 - **生态系统**: {maven/pip/npm/...}
 - **当前版本**: {current-version}
 - **受影响版本范围**: {vulnerable-range}
 - **首个修复版本**: {patched-version}
 
-### 依赖文件位置
-- `{manifest-path}` - {说明}
+### 依赖使用情况
+- **依赖文件位置**: `{manifest-path}` - {说明}
+- **依赖类型**: {直接依赖/传递依赖}
+- **使用模块列表**: 
+  - `{module-1}` - {说明}
+  - `{module-2}` - {说明}
 
 ## 影响范围评估
 
-### 直接影响
-- {项目中使用该依赖的模块和文件}
+### 直接影响的代码
+- `{file-path}:{line-number}` - {说明}
+
+### 间接影响的功能
+- {受影响的功能模块}
+
+## 安全风险评估
 
-### 漏洞可利用性分析
+### 漏洞可利用性
 - [ ] 是否直接使用了漏洞代码路径？
 - [ ] 是否有外部输入触发漏洞？
 - [ ] 当前配置是否暴露了漏洞？
 
 **结论**: {高/中/低风险 - 说明理由}
 
-## 修复方案
+### 触发条件
+{详细说明漏洞触发的条件和场景}
 
-### 推荐方案: {方案名称}
+### 影响程度
+{评估对系统安全性、数据完整性、可用性的影响}
 
-**具体步骤**:
-1. {步骤1}
-2. {步骤2}
-...
+### 紧急程度
+{根据严重程度和可利用性确定修复的紧急程度}
 
-**兼容性评估**:
-- {是否有破坏性变更}
-- {需要的代码调整}
+## 技术依赖和约束
 
-**工作量预估**:
-- 复杂度: {高/中/低}
-- 预估时间: {时间}
-- 风险等级: {高/中/低}
-
-### 备选方案（如果有）
-{其他可能的修复方案}
-
-### 临时缓解措施（如果无法立即修复）
-{临时性的防护措施}
-
-## 测试策略
-
-- [ ] {测试项1}
-- [ ] {测试项2}
-- [ ] 验证漏洞已修复
-- [ ] 回归测试
+{列出修复时需要考虑的技术依赖和约束条件}
 
 ## 参考链接
 
@@ -189,8 +169,6 @@ ghsa_id: <GHSA-ID>
 - 任务文件: .ai-workspace/active/{task-id}/task.md
 - 分析文档: {task_dir}/analysis.md
 
-**修复建议**: {简短的修复建议摘要}
-
 **下一步**:
 审查安全分析后，使用以下命令设计修复方案：
 /plan-task {task-id}
@@ -221,19 +199,22 @@ ghsa_id: <GHSA-ID>
    - Medium: 计划处理
    - Low: 可延后处理
 
-3. **依赖类型区分**：
+3. **职责范围**：
+   - 专注于信息收集和风险评估
+   - 不制定具体修复方案（修复方案在 `/plan-task` 阶段设计）
+   - 分析完成后建议人工审查
+
+4. **依赖类型区分**：
    - **直接依赖**: 在依赖文件中明确声明
    - **传递依赖**: 由其他依赖引入，修复可能需要升级父依赖
 
-4. **误报识别**：
+5. **误报识别**：
    - 检查漏洞代码路径是否被使用
    - 评估实际可利用性
    - 如确认是误报，建议使用 `/close-security` 关闭
 
-5. **兼容性风险**：
-   - 特别注意跨大版本升级
-   - 查看 CHANGELOG 和 Migration Guide
-   - 评估对现有代码的影响
+6. **紧急程度标注**：
+   - Critical/High 级别的漏洞需要明确标注紧急程度
 
 ## 相关命令
 

.claude/commands/plan-task.md

@@ -32,19 +32,26 @@ usage: "/plan-task <task-id>"
 - 如果不存在，提示用户需要先执行需求分析
 - 如果存在，读取并理解需求
 
-### 3. 设计技术方案
+### 3. 理解问题本质和约束条件
 
-按照 `.ai-agents/workflows/feature-development.yaml` 中的 `technical-design` 步骤：
+- [ ] 阅读 analysis.md，理解问题的根本原因和影响范围
+- [ ] 识别技术约束（从 analysis.md 的"技术依赖和约束"章节获取）
+- [ ] 识别特殊要求（例如：安全修复需要考虑漏洞修复版本、Bug修复需要防止回归、功能开发需要考虑扩展性）
 
-**必须完成的任务**：
-- [ ] 设计技术实现方案
-- [ ] 选择合适的技术栈和设计模式
+### 4. 设计解决方案
+
+按照对应的工作流（如 `.ai-agents/workflows/feature-development.yaml`）中的 `technical-design` 步骤：
+
+- [ ] 基于 analysis.md 中的信息，提出多个可行方案
+- [ ] 对比各方案的优劣（效果、成本、风险、可维护性）
+- [ ] 选择最合适的方案并说明理由
 - [ ] 制定详细的实施步骤
 - [ ] 列出需要创建/修改的文件清单
-- [ ] 设计测试策略
-- [ ] 评估性能和安全影响
+- [ ] 设计验证策略（测试、验证、回归检查）
+- [ ] 评估影响（性能、安全、兼容性）
+- [ ] 制定风险控制和回滚方案
 
-### 4. 输出方案文档
+### 5. 输出方案文档
 
 创建 `{task_dir}/plan.md`，必须包含以下章节：
 
@@ -53,22 +60,33 @@ usage: "/plan-task <task-id>"
 
 ## 方案决策
 
-### 方案对比分析
-{如果有多个方案，对比分析各方案的优劣}
+### 问题理解
+{基于 analysis.md 的问题理解和根本原因}
+
+### 约束条件
+- 技术约束: {技术依赖和限制}
+- 业务约束: {业务要求和限制}
+- 时间约束: {交付时间要求}
+
+### 备选方案对比分析
+{如果有多个方案，详细对比分析各方案的优劣}
 
 ### 最终选择
 - **方案**：{选择的方案}
 - **理由**：{选择理由}
 
 ## 技术方案
 
-### 核心实现策略
-{详细的实现策略}
+### 核心解决策略
+{详细的解决策略}
 
 ### 关键技术点
 - {技术点1}
 - {技术点2}
 
+### 具体实现细节
+{根据问题类型的具体实现，例如：代码实现、依赖升级、配置调整等}
+
 ## 实施步骤
 
 ### 步骤 1: {步骤名称}
@@ -88,34 +106,45 @@ usage: "/plan-task <task-id>"
 |------|----------|----------|----------|
 | 1 | {path} | {内容} | {行数} |
 
-## 测试策略
+## 验证策略
+
+### 功能验证
+- 单元测试: {测试范围和验收标准}
+- 集成测试: {测试范围和验收标准}
 
-### 单元测试
-- {测试范围和验收标准}
+### 问题验证
+{确认问题已解决，如：功能正常、Bug不再复现、漏洞已修复}
 
-### 集成测试
-- {测试范围和验收标准}
+### 回归验证
+{确保没有引入新问题}
 
-## 性能考虑
+## 影响评估
+
+### 性能影响
 {性能影响分析和优化建议}
 
-## 安全考虑
+### 安全影响
 {安全风险评估和防护措施}
 
-## 回滚方案
-{如果实施失败，如何回滚}
+### 兼容性影响
+{兼容性分析和注意事项}
 
 ## 风险控制
+
+### 潜在风险
 | 风险 | 等级 | 应对措施 |
 |------|------|----------|
 | {风险} | {等级} | {措施} |
 
+### 回滚方案
+{如果实施失败，如何回滚}
+
 ## 预期产出
 - {产出1}
 - {产出2}
 ```
 
-### 5. 更新任务状态
+### 6. 更新任务状态
 
 更新 `.ai-workspace/active/{task-id}/task.md`：
 - `current_step`: technical-design
@@ -124,7 +153,7 @@ usage: "/plan-task <task-id>"
 - 标记 plan.md 为已完成
 - 在工作流进度中标记技术方案设计为完成
 
-### 6. 告知用户
+### 7. 告知用户
 
 输出格式：
 ```
@@ -173,7 +202,7 @@ usage: "/plan-task <task-id>"
 
 1. **前置条件**：
    - 必须先完成需求分析（analysis.md 存在）
-   - 如果没有，提示用户先执行 `/analyze-issue`
+   - 如果没有，提示用户先执行 `/analyze-issue` 或 `/analyze-security`
 
 2. **人工检查点**：
    - 这是一个**必须**的人工检查点
@@ -192,12 +221,16 @@ usage: "/plan-task <task-id>"
 
 ## 相关命令
 
-- `/analyze-issue <number>` - 分析 Issue（前置步骤）
-- `/implement-task <task-id>` - 实施任务（后续步骤）
+**前置步骤**：
+- `/analyze-issue <number>` - 分析 GitHub Issue
+- `/analyze-security <alert-number>` - 分析 Dependabot 安全告警
+
+**后续步骤**：
+- `/implement-task <task-id>` - 实施任务
 - `/task-status <task-id>` - 查看任务状态
 
 ## 错误处理
 
 - 任务不存在：提示 "任务 {task-id} 不存在，请检查任务ID"
-- 缺少需求分析：提示 "需求分析文档不存在，请先执行 /analyze-issue"
+- 缺少需求分析：提示 "需求分析文档不存在，请先执行 /analyze-issue 或 /analyze-security"
 - plan.md 已存在：询问是否覆盖或创建新版本

.claude/commands/review-task.md

@@ -259,6 +259,7 @@ usage: "/review-task <task-id> [--pr-number]"
 
 ### 示例3：完整工作流
 
+**功能开发流程**：
 ```bash
 # 1. 分析 Issue
 /analyze-issue 207
@@ -279,6 +280,27 @@ usage: "/review-task <task-id> [--pr-number]"
 /create-pr
 ```
 
+**安全修复流程**：
+```bash
+# 1. 分析安全告警
+/analyze-security 23
+
+# 2. 设计修复方案
+/plan-task TASK-20251227-110000
+
+# 3. 实施修复
+/implement-task TASK-20251227-110000
+
+# 4. 代码审查 ← 当前步骤
+/review-task TASK-20251227-110000
+
+# 5. 如果审查通过，提交代码
+/commit
+
+# 6. 创建 Pull Request
+/create-pr
+```
+
 ## 注意事项
 
 1. **前置条件**：