一键导入
openspec-verify-change
OpenSpec验证变更专家,验证代码实现是否与变更工件(规格、任务、设计)一致。当用户需要验证实现完整性、确认代码正确性或在归档前检查时调用此Skill。支持中文触发:验证变更、verify change、实现验证、归档前检查、一致性验证。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
OpenSpec验证变更专家,验证代码实现是否与变更工件(规格、任务、设计)一致。当用户需要验证实现完整性、确认代码正确性或在归档前检查时调用此Skill。支持中文触发:验证变更、verify change、实现验证、归档前检查、一致性验证。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
"PDD框架下的业务分析Skill,运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令,或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发:业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。"
"PDD熵减智能体,持续监控和偿还技术债务,防止系统腐化。当用户需要代码清理、文档更新、技术债务管理、架构对齐、熵减、垃圾回收、清理技术债务时自动触发。即使用户只说'熵减'、'清理技术债务'或'垃圾回收',也应触发此Skill。支持中文触发:熵减、技术债务、代码清理、文档更新、架构对齐、垃圾回收。"
根据开发规格实现功能点代码的核心Skill。当用户想要开始编码实现、根据规格文档生成代码、实现功能点时调用此Skill。此Skill会自动调用pdd-template-engine生成基础代码框架,然后由software-engineer补充业务逻辑。即使只有规格文档没有明确说'实现',只要涉及代码生成、功能开发,都应触发此Skill。支持中文触发:实现功能点、编码实现、开始编码、功能开发、代码实现、PDD实现。
PRD驱动开发的主入口Skill,协调整个开发流程。当用户想要基于PRD文档进行功能开发、从需求文档生成代码、执行PDD方法论流程、开发业务模块、实现完整功能、'搞个功能'、'资产转让'、'国有产权转让'、'帮我搞个资产转让的功能'时必须调用此Skill。即使用户没有明确说'使用PDD',只要涉及PRD文档、需求文档、功能点开发、规格文档、模块开发、根据文档开发、业务功能实现、'开发ZCCZ'、'我想开发'、'搞个功能'等场景,都应触发此Skill。此Skill会自动协调pdd-ba、pdd-extract-features、pdd-generate-spec、pdd-implement-feature等子Skill完成从需求分析到代码交付的完整流程。注意:单一接口设计、调试问题、文档查询等场景不应触发此Skill。支持中文触发:PRD驱动开发、PDD开发、功能开发、启动PDD。
"交通事故责任评估与判定专业技能。当用户需要交通事故责任分析、事故现场照片评估、交通法规咨询、事故责任划分、法律依据查询时触发此技能。适用于车辆碰撞事故、行人事故、非机动车事故等各类道路交通事故的责任认定场景。无论用户使用'交通事故'、'车祸'、'责任判定'、'交通法规'、'事故定责'等何种表述,只要涉及交通事故评估或责任认定,均应调用此技能。支持中文触发:交通事故、车祸、责任判定、交通法规、事故定责、责任划分、事故评估、追尾、碰撞、违章、赔偿。"
自动化重构专家技能,将收集到的质量改进任务转化为具体的代码操作。当用户需要代码重构、消除重复、简化复杂度时自动触发。即使用户只说'重构代码'、'消除重复'或'简化代码',也应触发此Skill。支持中文触发:重构代码、消除重复、简化复杂度、自动重构、代码重构、PDD重构。
| name | openspec-verify-change |
| description | OpenSpec验证变更专家,验证代码实现是否与变更工件(规格、任务、设计)一致。当用户需要验证实现完整性、确认代码正确性或在归档前检查时调用此Skill。支持中文触发:验证变更、verify change、实现验证、归档前检查、一致性验证。 |
| 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
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.
Check status to understand the schema
openspec status --change "<name>" --json
Parse the JSON to understand:
schemaName: The workflow being used (e.g., "spec-driven")Get the change directory and load artifacts
openspec instructions apply --change "<name>" --json
This returns the change directory and context files. Read all available artifacts from contextFiles.
Initialize verification report structure
Create a report structure with three dimensions:
Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
Verify Completeness
Task Completion:
- [ ] (incomplete) vs - [x] (complete)Spec Coverage:
openspec/changes/<name>/specs/:
Verify Correctness
Requirement Implementation Mapping:
Scenario Coverage:
Verify Coherence
Design Adherence:
Code Pattern Consistency:
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:
CRITICAL (Must fix before archive):
WARNING (Should fix):
SUGGESTION (Nice to fix):
Final Assessment:
Verification Heuristics
Graceful Degradation
Output Format
Use clear markdown with:
file.ts:123