用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/diegosouzapw/awesome-omni-skill --skill spec-interview命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Token-efficient tracking for AI orchestration. CLI-first for status updates (~50 tokens), agent fallback for complex ops (~1KB). Use when: updating task status, querying blockers, creating progress files, validating phases.
AshAi extension guidelines for integrating AI capabilities with Ash Framework. Use when implementing vectorization/embeddings, exposing Ash actions as LLM tools, creating prompt-backed actions, or setting up MCP servers. Covers semantic search, LangChain integration, and structured outputs.
This skill should be used when solving hard questions, complex architectural problems, or debugging issues that benefit from GPT-5 Pro or GPT-5.1 thinking models with large file context. Use when standard Claude analysis needs deeper reasoning or extended context windows.
基于 SOC 职业分类
正在显示 SKILL.md
| name | spec-interview |
| description | 通过系统性访谈完善技术规格文档，访谈完成后自动创建 OpenSpec proposal。适用于需求细化、技术方案设计、规范驱动开发等场景。 |
| license | MIT |
| category | documentation |
| tags | ["spec","interview","openspec","requirements","design"] |
通过深入的苏格拉底式访谈，将草稿规格说明转化为完整、可执行的技术文档。访谈完成后自动创建 OpenSpec proposal，实现规范驱动开发（Spec-Driven Development）。
读取 plan.md 或用户指定的文档，分析：
使用 AskUserQuestionTool 进行多维度深度访谈：
简单性检查（KISS & YAGNI）
重复性识别（DRY）
架构健壮性（SOLID）
如规格涉及以下操作，将主动提醒：
⚠️ 高风险操作检测
操作类型：[文件删除 / Git 强制推送 / 环境变量修改 / 数据库结构变更 / 批量依赖更新]
影响范围：[具体描述]
建议措施：
- 回滚方案：[具体步骤]
- 备份策略：[备份内容与频率]
- 测试要求：[测试环境与验证标准]
请确认是否继续执行。
访谈完成后，系统将自动调用 OpenSpec 工作流创建 proposal：
根据用户使用的 AI 工具，使用相应的命令：
Claude Code / Codex / Qoder / RooCode:
/openspec:proposal
Cursor / Continue / GitHub Copilot / Windsurf:
/openspec-proposal
其他工具（AGENTS.md 兼容）:
请创建一个 OpenSpec proposal
openspec/
├── changes/
│ └── <change-name>/
│ ├── proposal.md # 变更提案
│ ├── tasks.md # 任务清单
│ └── specs/ # 规格差异（delta）
│ └── <spec-name>/
│ └── spec.md # 规格变更
└── specs/ # 当前规格（归档后更新）
└── <spec-name>/
└── spec.md
1. Proposal (openspec/changes/<change-name>/proposal.md)
2. Tasks (openspec/changes/<change-name>/tasks.md)
3. Spec Deltas (openspec/changes/<change-name>/specs/*/spec.md)
使用 delta 格式标记变更：
## 新增功能
+++ 新增的内容描述
+++ 包括接口定义、数据模型等
## 修改功能
--- 删除的旧内容
+++ 新增的替代内容
## 删除功能
--- 删除的内容描述
创建 proposal 后，用户可以：
审查与细化
实施变更
/openspec:apply 或 /openspec-apply 命令归档变更
/openspec:archive 或 /openspec-archiveopenspec/specs/ 中/rg 而非 grep步骤 1: 启动访谈
用户: 帮我完善这个 plan
系统: 已读取
plan.md。该项目计划构建一个用户管理 API。在开始访谈前，请确认：这是一个面向公网的 API 还是内部服务？
步骤 2: 深度提问
用户: 内部服务
系统: 明白。关于认证机制，内部服务通常有几种选择：
- 服务间共享密钥（简单但安全性较低）
- mTLS（高安全性但配置复杂）
- 内部 OAuth 2.0（灵活但需要额外基础设施）
考虑到您的团队规模和运维能力，倾向于哪种方案？或者是否已有统一的内部认证标准？
步骤 3: 工程原则审查
系统: 关于用户角色管理，计划支持多少种角色？这是 MVP 必需的功能吗？
根据 YAGNI 原则，如果初期只需要管理员和普通用户两种角色，建议先实现简单的二元权限模型，后续再扩展为 RBAC。这样可以减少 30-40% 的开发时间。您的看法如何？
步骤 4: 创建 OpenSpec Proposal
系统: 访谈完成！现在为您创建 OpenSpec proposal...
[调用 /openspec:proposal 或等效命令]
✅ 已创建 proposal:
openspec/changes/user-management-api/后续步骤：
- 审查
proposal.md和tasks.md- 使用
/openspec:apply开始实施- 完成后使用
/openspec:archive归档