用途：将草稿规格或 plan.md 通过苏格拉底式访谈转化为完整技术文档，并在访谈完成后自动创建 OpenSpec proposal，服务于需求细化、技术方案设计与规范驱动开发。
主要能力：系统性需求访谈；工程原则审查（KISS、YAGNI、DRY、SOLID）；技术方案与权衡分析；风险识别与缓解；自动生成 OpenSpec proposal。访谈维度包括工程原则、技术实现细节、API 设计、UI/UX、风险与权衡、边缘情况与异常处理、项目约定与规范。涉及文件删除、Git 强制推送、环境变量修改、数据库结构变更、批量依赖更新等高风险操作时会主动提醒，并给出回滚方案、备份策略与测试要求。
使用方式：读取 plan.md 或指定文档后，使用 AskUserQuestionTool 进行多轮深度访谈，再调用 OpenSpec 工作流创建 proposal。命令：Claude Code / Codex / Qoder / RooCode 使用 /openspec:proposal；Cursor / Continue / GitHub Copilot / Windsurf 使用 /openspec-proposal；其他兼容 AGENTS.md 的工具请求“创建一个 OpenSpec proposal”。后续实施与归档：/openspec:apply 或 /openspec-apply，/openspec:archive 或 /openspec-archive。输出结构为 openspec/changes/<change-name>/ 下的 proposal.md、tasks.md 与 specs/*/spec.md，delta 用 +++ 新增、--- 删除标记。
适用场景：需求细化、技术方案评审、规范驱动开发。触发说法如“帮我完善这个 plan”“对这个技术方案进行深度访谈”“创建规格提案”“spec-driven development”。
限制：技术约束要求路径使用双引号与正斜杠 /，优先使用 rg 而非 grep，除非明确要求否则不执行 commit 或分支操作，遵循先读后写。平台兼容性、许可证与维护风险、成本价格、具体效果等资料未提供具体数值，暂未提供。