用途：把一份 PRD 及其 issue 拆分结果转换为 OpenSpec 变更文件夹，产出的结构符合 spec-driven schema。
使用方式：先向用户索取 PRD 文件路径（如 docs/prds/<slug>.md）和 issues 目录路径（如 docs/issues/<prd-slug>/），并读取全部内容。生成产物前先探索代码库，了解既有领域边界、架构及本次变更涉及范围；可借助 mcp__context7 的 resolve-library-id 和 query-docs 查阅 PRD 或 issue 中提到的库、框架、服务的当前文档，也可通过 WebSearch 查找更新的技术与方案，把发现写入 design.md 和 specs/。
产物：在 openspec/changes/<change-name>/ 创建变更文件夹，<change-name> 由 PRD slug 转为 kebab-case；若 openspec/ 不存在则先创建。生成 .openspec.yaml（schema: spec-driven，created 为当天日期 YYYY-MM-DD）、proposal.md（含 Why、What Changes、Capabilities 的新增/修改能力、Impact）、specs/<domain>/spec.md（按领域分组，Requirement 用 ###，Scenario 用 ####，采用 WHEN/THEN，需求用 RFC 2119 关键词 MUST/SHOULD/MAY，每条需求至少一个场景）、design.md（Context、Goals/Non-Goals、Decisions、Risks/Trade-offs）、tasks.md（每个 issue 一个任务组，验收标准转为 - [ ] 复选框，按 NN- 前缀依赖顺序排列，层级编号 1.1、1.2 等）。
最后向用户列出创建的文件与变更文件夹路径，汇总识别的 spec 领域数、需求与场景数、任务组与任务数、影响产物的研究结论，以及未能清晰映射、需人工复核的 PRD 内容。
限制：不得修改原始 PRD 或 issue 文件；任务必须使用复选框格式，否则无法被追踪。未提供具体安装方式与运行环境信息。