用途：通过分阶段苏格拉底式访谈，增量产出 OpenSpec 工件，每个阶段对应一个工件，用户可在任意阶段后退出。
主要能力与流程：若 $ARGUMENTS 为空，用 AskUserQuestion 询问要构建什么，并推导 kebab-case 名称；运行 openspec new change "<name>" 与 openspec status --change "<name>" --json；读取 resources/INTERVIEW_PRINCIPLES.md、resources/OPENSPEC_INTERVIEW_DIMENSIONS.md、resources/BRAINSTORMING_INTEGRATION.md。若用户说“skip brainstorming”，跳过步骤 2.5、3.5 与 Phase 1.5。步骤 2.5 范围分解检查：检测到 3 个以上独立子系统时，按头脑风暴协议建议拆分为多个变更。步骤 3.5 可视化伴侣：涉及 UI/前端工作时，按协议提供浏览器可视化伴侣。随后执行 4 个访谈阶段，每阶段用 AskUserQuestion 给出 2-4 个收敛选项，再写工件；用户说“skip”则用已收集信息推进。Phase 1 生成 proposal.md（业务目标、MVP 范围、风险预览、能力识别）；Phase 1.5 提出 2-3 种实现方案及权衡，选中方案写入 proposal.md 的 What Changes；Phase 2 生成 specs/<cap>/spec.md（按能力以 WHEN/THEN 场景描述 ADDED/MODIFIED/REMOVED）；Phase 3 生成 design.md（技术决策与架构权衡，含 Alternatives Considered）；Phase 4 生成 tasks.md（层级复选框实现拆解）。写每个工件前用 openspec instructions <artifact> --change "<name>" --json，回退用 resources/ARTIFACT_TEMPLATES.md。检测到高风险操作时读取 resources/RISK_PROTECTION.md 并获取明确授权。完成后运行 openspec status --change "<name>"，引导用户使用 /opsx:apply 或 /opsx:verify。
限制：路径加双引号、用 / 分隔符，优先 rg 而非 grep；绝不自动执行 Git 写操作（commit、push）；所有问题通过 AskUserQuestion 以可点击选项提出，不用纯文本 A/B/C。