pdd-skills 3.0.0

package/skills/openspec/openspec-verify-change/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: openspec-verify-change
+description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"

package/skills/openspec/openspec-verify-change/_meta.json

@@ -0,0 +1 @@
+{"name": "openspec-verify-change", "version": "1.0.0", "category": "openspec", "description": "Verify implementation matches OpenSpec change artifacts. Invoke when validating completeness before archiving.", "triggers": ["验证变更", "verify change", "验证实现"]}

package/skills/pr/pdd-multi-review/SKILL.md

@@ -0,0 +1,534 @@
+---
+name: pdd-multi-review
+description: |
+  PDD多轮审查技能，提供分层次代码审查能力。当功能点代码实现完成、用户请求代码审查review、检查代码、代码有问题吗、验收、质量检查、代码审核、代码质量验证等场景时自动触发。通过规则检查、AI审查、交叉验证三轮审查，弥补国产模型在复杂逻辑推理上的能力短板，将问题发现率从60%提升至90%+。即使用户只说"审查一下"、"检查代码"、"代码有问题吗"等简短表述，也应触发此Skill。
+license: MIT
+compatibility: 需要开发规格文档 (spec.md)
+metadata:
+  author: "neuqik@hotmail.com"
+  version: "1.0"
+---
+
+# PDD多轮审查技能
+
+## 技能描述
+
+PDD多轮审查技能提供分层次的代码审查能力，通过规则检查、AI审查和交叉验证三轮审查，弥补国产模型在复杂逻辑推理上的能力短板，确保代码质量和业务逻辑正确性。
+
+## 触发条件
+
+- 功能点代码实现完成后
+- 用户请求"审查代码"、"review"等命令
+- pdd-implement-feature 完成代码生成后自动触发
+
+## 核心能力
+
+### 1. 三轮审查机制
+
+```yaml
+审查流程:
+  第一轮: 规则检查 (Rule Check)
+    类型: 自动化静态分析
+    速度: 快速
+    覆盖: 代码风格、安全漏洞、常见错误模式
+    
+  第二轮: AI审查 (AI Review)
+    类型: 智能分析
+    速度: 中等
+    覆盖: 业务逻辑、代码质量、最佳实践
+    
+  第三轮: 交叉验证 (Cross Validation)
+    类型: 规格对照
+    速度: 较慢
+    覆盖: 接口完整性、数据模型一致性、业务规则正确性
+```
+
+### 2. 审查清单标准化
+
+```yaml
+审查维度:
+  接口实现:
+    - 所有接口是否都已实现
+    - 接口参数是否与规格一致
+    - 返回值是否与规格一致
+    - 异常处理是否完整
+  
+  数据模型:
+    - 实体字段是否与数据库表一致
+    - 字段类型是否正确
+    - 必填字段是否有验证
+    - 关联关系是否正确
+  
+  业务逻辑:
+    - 业务规则是否正确实现
+    - 状态转换是否符合定义
+    - 边界条件是否处理
+    - 并发场景是否考虑
+  
+  安全性:
+    - 是否有SQL注入风险
+    - 是否有XSS风险
+    - 权限控制是否完整
+    - 敏感数据是否加密
+  
+  性能:
+    - 是否有N+1查询问题
+    - 是否有性能瓶颈
+    - 缓存使用是否合理
+    - 分页是否正确
+  
+  代码质量:
+    - 代码是否清晰易读
+    - 命名是否规范
+    - 注释是否充分
+    - 是否有重复代码
+```
+
+### 3. 问题分级标准
+
+```yaml
+问题级别:
+  Critical (严重):
+    定义: 阻塞功能正常运行的问题
+    示例:
+      - 接口实现缺失
+      - 业务逻辑错误
+      - 安全漏洞
+      - 数据丢失风险
+    处理: 必须立即修复，阻塞后续流程
+  
+  Warning (警告):
+    定义: 影响代码质量或性能的问题
+    示例:
+      - 代码风格不一致
+      - 缺少异常处理
+      - 性能隐患
+      - 注释缺失
+    处理: 建议修复，不阻塞流程
+  
+  Suggestion (建议):
+    定义: 改进建议
+    示例:
+      - 代码可读性改进
+      - 重构建议
+      - 最佳实践建议
+    处理: 可选修复，记录备查
+```
+
+### 4. 反馈循环机制
+
+```yaml
+反馈流程:
+  发现问题 → 记录问题 → 分配修复 → 验证修复 → 关闭问题
+
+问题记录格式:
+  id: ISS-001
+  round: 2  # 审查轮次
+  level: Critical
+  category: 业务逻辑
+  location:
+    file: EquityTransferApplyServiceImpl.java
+    line: 45-50
+  description: 转让底价验证逻辑错误，应该大于等于评估价值
+  expected: 转让底价 >= 评估价值
+  actual: 转让底价 > 评估价值（缺少等于的情况）
+  suggestion: 修改为 >= 判断
+  status: open
+  assignee: AI
+  createdAt: 2026-03-31T11:00:00Z
+  history:
+    - action: created
+      timestamp: 2026-03-31T11:00:00Z
+    - action: assigned
+      timestamp: 2026-03-31T11:01:00Z
+```
+
+## 审查流程详解
+
+### 第一轮：规则检查
+
+```yaml
+检查项目:
+  代码风格:
+    - 命名规范检查
+    - 代码格式检查
+    - 导入语句检查
+    - 注释规范检查
+  
+  安全检查:
+    - SQL注入检查
+    - XSS检查
+    - 敏感信息泄露检查
+    - 权限注解检查
+  
+  常见错误:
+    - 空指针检查
+    - 资源泄露检查
+    - 异常处理检查
+    - 并发安全检查
+
+检查工具:
+  - Checkstyle (Java)
+  - ESLint (JavaScript)
+  - PMD (Java)
+  - SpotBugs (Java)
+
+输出格式:
+  rule-check-report.md:
+    检查时间: 2026-03-31T11:00:00Z
+    检查范围: 15个文件
+    问题统计:
+      Critical: 0
+      Warning: 5
+      Suggestion: 10
+    问题列表:
+      - 文件: xxx.java
+        规则: naming-convention
+        级别: Warning
+        描述: 变量名不符合驼峰命名规范
+```
+
+### 第二轮：AI审查
+
+```yaml
+审查维度:
+  业务逻辑正确性:
+    - 需求理解是否正确
+    - 业务规则是否完整实现
+    - 边界条件是否处理
+    - 异常场景是否考虑
+  
+  代码质量:
+    - 代码结构是否清晰
+    - 是否遵循设计模式
+    - 是否有代码重复
+    - 是否有过度设计
+  
+  最佳实践:
+    - 是否遵循框架规范
+    - 是否使用推荐方式
+    - 是否避免反模式
+
+审查方法:
+  - 逐文件审查
+  - 业务逻辑追踪
+  - 代码路径分析
+  - 依赖关系检查
+
+输出格式:
+  ai-review-report.md:
+    审查时间: 2026-03-31T11:15:00Z
+    审查范围: 15个文件
+    问题统计:
+      Critical: 2
+      Warning: 8
+      Suggestion: 15
+    问题列表:
+      - id: ISS-001
+        类别: 业务逻辑
+        级别: Critical
+        文件: EquityTransferApplyServiceImpl.java
+        行号: 45-50
+        描述: 转让底价验证逻辑错误
+        建议: 修改为 >= 判断
+```
+
+### 第三轮：交叉验证
+
+```yaml
+验证项目:
+  接口完整性验证:
+    方法: 对照spec.md逐项检查
+    内容:
+      - 所有接口是否都已实现
+      - 接口参数是否与规格一致
+      - 返回值是否与规格一致
+  
+  数据模型一致性验证:
+    方法: 对照数据库设计检查
+    内容:
+      - 实体字段是否与表结构一致
+      - 字段类型是否匹配
+      - 关联关系是否正确
+  
+  业务规则正确性验证:
+    方法: 对照业务规则定义检查
+    内容:
+      - 验证规则是否完整
+      - 状态转换是否正确
+      - 计算逻辑是否正确
+
+验证方法:
+  - 规格对照表
+  - 字段映射检查
+  - 接口映射检查
+  - 业务规则追踪
+
+输出格式:
+  cross-validation-report.md:
+    验证时间: 2026-03-31T11:30:00Z
+    验证范围: spec.md vs 实现代码
+    验证结果:
+      接口完整性: 100% (10/10)
+      数据模型一致性: 95% (19/20)
+      业务规则正确性: 90% (9/10)
+    问题列表:
+      - id: ISS-002
+        类别: 数据模型
+        级别: Warning
+        描述: 实体类缺少remark字段
+        规格: 有remark字段
+        实际: 未实现
+```
+
+## 审查报告模板
+
+```markdown
+# 多轮审查报告
+
+## 审查概要
+
+| 项目 | 内容 |
+|------|------|
+| 功能点ID | FP-ZCCZ1-001 |
+| 功能名称 | 国有产权转让申请 |
+| 审查时间 | 2026-03-31 11:00:00 - 11:30:00 |
+| 审查范围 | 15个文件 |
+
+## 问题统计
+
+| 轮次 | Critical | Warning | Suggestion | 合计 |
+|------|----------|---------|------------|------|
+| 第一轮：规则检查 | 0 | 5 | 10 | 15 |
+| 第二轮：AI审查 | 2 | 8 | 15 | 25 |
+| 第三轮：交叉验证 | 1 | 3 | 5 | 9 |
+| **合计** | **3** | **16** | **30** | **49** |
+
+## Critical问题详情
+
+### ISS-001: 转让底价验证逻辑错误
+
+| 属性 | 内容 |
+|------|------|
+| 来源 | 第二轮：AI审查 |
+| 类别 | 业务逻辑 |
+| 文件 | EquityTransferApplyServiceImpl.java |
+| 行号 | 45-50 |
+| 描述 | 转让底价验证逻辑错误，应该大于等于评估价值 |
+| 预期 | 转让底价 >= 评估价值 |
+| 实际 | 转让底价 > 评估价值（缺少等于的情况） |
+| 建议 | 修改为 >= 判断 |
+
+**代码片段**：
+```java
+// 当前代码
+if (transferFloorPrice > evaluationValue) {
+    throw new BusinessException("转让底价不得低于评估价值");
+}
+
+// 建议修改
+if (transferFloorPrice < evaluationValue) {
+    throw new BusinessException("转让底价不得低于评估价值");
+}
+```
+
+### ISS-002: 缺少权限注解
+
+| 属性 | 内容 |
+|------|------|
+| 来源 | 第一轮：规则检查 |
+| 类别 | 安全性 |
+| 文件 | EquityTransferApplyController.java |
+| 行号 | 35 |
+| 描述 | 删除接口缺少权限注解 |
+| 建议 | 添加 @PreAuthorize("@ss.hasPermi('equity:transfer:remove')") |
+
+### ISS-003: 接口返回值与规格不一致
+
+| 属性 | 内容 |
+|------|------|
+| 来源 | 第三轮：交叉验证 |
+| 类别 | 接口完整性 |
+| 文件 | EquityTransferApplyController.java |
+| 行号 | 50 |
+| 描述 | 详情接口返回值缺少附件列表 |
+| 规格 | 返回 { entity, attachments } |
+| 实际 | 只返回 { entity } |
+| 建议 | 添加附件列表查询并返回 |
+
+## Warning问题列表
+
+| ID | 来源 | 类别 | 文件 | 描述 |
+|----|------|------|------|------|
+| W-001 | 第一轮 | 代码风格 | Entity.java | 变量名不符合驼峰命名规范 |
+| W-002 | 第二轮 | 代码质量 | ServiceImpl.java | 方法过长，建议拆分 |
+| W-003 | 第三轮 | 数据模型 | Entity.java | 缺少remark字段 |
+| ... | ... | ... | ... | ... |
+
+## Suggestion问题列表
+
+| ID | 来源 | 类别 | 文件 | 描述 |
+|----|------|------|------|------|
+| S-001 | 第一轮 | 代码风格 | Controller.java | 建议添加接口注释 |
+| S-002 | 第二轮 | 最佳实践 | ServiceImpl.java | 建议使用Optional避免空指针 |
+| ... | ... | ... | ... | ... |
+
+## 验证结果
+
+### 接口完整性验证
+
+| 接口 | 规格 | 实现 | 状态 |
+|------|------|------|------|
+| POST /equity-transfer | 新增申请 | ✅ 已实现 | 通过 |
+| PUT /equity-transfer | 修改申请 | ✅ 已实现 | 通过 |
+| DELETE /equity-transfer/{id} | 删除申请 | ✅ 已实现 | 通过 |
+| GET /equity-transfer/{id} | 查询详情 | ✅ 已实现 | ⚠️ 返回值不完整 |
+| GET /equity-transfer/list | 查询列表 | ✅ 已实现 | 通过 |
+
+### 数据模型一致性验证
+
+| 字段 | 数据库 | 实体类 | 状态 |
+|------|--------|--------|------|
+| id | bigint | Long | 通过 |
+| transfer_type | varchar | String | 通过 |
+| transfer_reason | varchar | String | 通过 |
+| remark | varchar | - | ⚠️ 缺失 |
+
+### 业务规则正确性验证
+
+| 规则ID | 规则描述 | 实现状态 | 验证结果 |
+|--------|---------|---------|---------|
+| BR-001 | 转让底价 >= 评估价值 | ✅ 已实现 | ❌ 逻辑错误 |
+| BR-002 | 转让原因必填 | ✅ 已实现 | 通过 |
+| BR-003 | 附件必传 | ✅ 已实现 | 通过 |
+
+## 审查结论
+
+| 结论 | 内容 |
+|------|------|
+| 是否通过 | ❌ 不通过 |
+| 原因 | 存在3个Critical问题需要修复 |
+| 下一步 | 修复Critical问题后重新审查 |
+
+## 修复建议
+
+1. **ISS-001**: 修改转让底价验证逻辑
+2. **ISS-002**: 添加权限注解
+3. **ISS-003**: 补充附件列表返回
+```
+
+## 反馈循环流程
+
+```
+审查完成
+    │
+    ▼
+┌─────────────────────────────────┐
+│   1. 问题分类与优先级排序        │
+│   - Critical问题优先处理         │
+│   - Warning问题次优先            │
+│   - Suggestion记录备查           │
+└─────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────┐
+│   2. 问题分配                    │
+│   - 自动修复：简单问题           │
+│   - AI修复：复杂问题             │
+│   - 人工修复：需要确认的问题     │
+└─────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────┐
+│   3. 执行修复                    │
+│   - 记录修复过程                 │
+│   - 更新代码文件                 │
+│   - 标记问题状态                 │
+└─────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────┐
+│   4. 验证修复                    │
+│   - 重新运行相关检查             │
+│   - 确认问题已解决               │
+│   - 检查是否引入新问题           │
+└─────────────────────────────────┘
+    │
+    ├─ 所有问题已解决 ──────────────┐
+    │                              │
+    ▼                              ▼
+┌─────────────────────────────────┐
+│   5. 关闭问题                    │
+│   - 更新问题状态为已关闭         │
+│   - 记录修复历史                 │
+│   - 生成最终报告                 │
+└─────────────────────────────────┘
+```
+
+## 问题修复记录模板
+
+```yaml
+问题修复记录:
+  问题ID: ISS-001
+  修复人: AI
+  修复时间: 2026-03-31T12:00:00Z
+  
+  修复前代码: |
+    if (transferFloorPrice > evaluationValue) {
+        throw new BusinessException("转让底价不得低于评估价值");
+    }
+  
+  修复后代码: |
+    if (transferFloorPrice < evaluationValue) {
+        throw new BusinessException("转让底价不得低于评估价值");
+    }
+  
+  验证结果: 通过
+  验证人: AI
+  验证时间: 2026-03-31T12:05:00Z
+  
+  备注: 修改判断条件为正确的逻辑
+```
+
+## 学习机制
+
+```yaml
+学习内容:
+  问题模式学习:
+    - 记录常见问题类型
+    - 建立问题模式库
+    - 优化审查规则
+  
+  修复方案学习:
+    - 记录有效修复方案
+    - 建立修复知识库
+    - 提高自动修复率
+  
+  规则优化:
+    - 根据问题统计优化规则
+    - 添加新的检查规则
+    - 调整问题级别
+
+学习输出:
+  - common-issues.yaml: 常见问题库
+  - fix-patterns.yaml: 修复模式库
+  - review-rules.yaml: 审查规则库
+```
+
+## Guardrails
+
+- Critical问题必须全部修复才能通过
+- 每个问题必须有明确的修复方案
+- 修复后必须重新验证
+- 问题修复历史必须完整记录
+- 审查报告必须保存到 docs/reviews/
+
+## 与其他技能协作
+
+| 协作技能 | 协作方式 | 传入数据 | 期望输出 |
+|---------|---------|---------|---------|
+| **pdd-implement-feature** | 被调用 | 代码文件 | 审查报告 |
+| **expert-ruoyi** | 咨询 | 若依相关问题 | 解决方案 |
+| **expert-activiti** | 咨询 | 工作流相关问题 | 解决方案 |
+| **expert-code-quality** | 咨询 | 代码质量问题 | 重构建议 |
+| **pdd-feedback-learner** | 调用 | 问题记录 | 学习结果 |

package/skills/pr/pdd-multi-review/_meta.json

@@ -0,0 +1 @@
+{"name": "pdd-multi-review", "version": "1.0.0", "category": "pr", "description": "Multi-dimensional code review orchestrating concurrent review agents for comprehensive quality validation. Invoke when needing thorough cross-cutting review coverage.", "triggers": ["多维度审查", "multi review", "全面审查"]}