一键导入
requirement-discovery
通过多轮对话澄清模糊需求、判断点子价值,并推动用户、业务、产品、设计、交付等多方完成需求识别与收敛。适用于需求尚不明确、干系人存在分歧、一个想法是否值得做仍不确定,或需要把零散讨论整理成清晰目标、范围和下一步计划的场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
通过多轮对话澄清模糊需求、判断点子价值,并推动用户、业务、产品、设计、交付等多方完成需求识别与收敛。适用于需求尚不明确、干系人存在分歧、一个想法是否值得做仍不确定,或需要把零散讨论整理成清晰目标、范围和下一步计划的场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
长时任务的 Harness 思维框架——当任务复杂、质量要求高、需要多轮迭代时,自动应用生成器-评估器分离、上下文重置、契约驱动、并行探索等模式。触发词:复杂任务、高质量输出、反复优化、迭代提升、多 agent 协作、长时任务、超越默认结果。
Import and adapt skills from Claude Code style repositories into Codex. Use when Codex needs to inspect a third-party skills repo, identify folders that contain reusable SKILL.md-based workflows, copy compatible skills into `~/.codex/skills`, or warn about Claude-specific files and assumptions before porting.
Clarify vague requests, test raw ideas, and drive multi-round requirement discovery across users, business owners, product, design, and delivery teams. Use when a request is not yet clear, stakeholders disagree, an idea may or may not be valuable, or Codex needs to turn scattered discussion into a concrete goal, scope, and next-step plan.
Design, refine, and package Codex skills from a user goal, an existing workflow, or a source repository. Use when Codex needs to create a new skill, improve an existing skill, turn repeated work into a reusable process, or adapt an external skill idea into a Codex-native format.
将 Claude Code 风格的技能仓库检查、筛选并改造成 Codex 技能。适用于需要查看第三方技能仓库、识别其中可复用的 SKILL.md 工作流、把兼容技能复制到 `~/.codex/skills`,或在迁移前识别 Claude 专属假设与限制的场景。
根据用户目标、现有工作流或外部来源,设计、改造并打包 Codex 技能。适用于需要创建新技能、优化现有技能、把重复工作沉淀成可复用流程,或把外部技能思路改造成 Codex 原生技能的场景。
| name | requirement-discovery |
| description | 通过多轮对话澄清模糊需求、判断点子价值,并推动用户、业务、产品、设计、交付等多方完成需求识别与收敛。适用于需求尚不明确、干系人存在分歧、一个想法是否值得做仍不确定,或需要把零散讨论整理成清晰目标、范围和下一步计划的场景。 |
通过结构化对话,把一个模糊想法或不清楚的请求,逐步收敛成可用的需求结论。
适合的场景包括:
不要一开始就跳进方案设计。
先回答四个问题:
把这件事当成“分阶段的需求识别”,不是一次性问答。
每一轮都先判断它处于哪个阶段:
信号收集:只有零碎想法、症状或口头要求问题澄清:正在定义真实痛点价值判断:判断这件事值不值得做范围收敛:明确对象、边界与取舍执行交接:整理成足够交给产品、设计或研发继续推进的结果不要一次把问题全问完。每次只问当下最有价值的下一个问题。
先提炼出第一版可用信息:
如果输入只有模糊想法,先用一句话复述再继续。
把需求先归为以下类型之一:
不同类型,决定后续追问方式。
按这个顺序缩小模糊空间:
如果回答太抽象,就逼近到实例:
在讨论界面、流程、实现之前,先判断要不要继续推进:
如果价值偏弱,要明确给出建议:
当价值基本成立后,再明确:
始终区分:
当信息足够时,用业务语言总结,而不是工程语言。
建议输出框架:
如果成熟度还不够,就输出“探索总结”,不要假装已经定稿。
根据成熟度,选择以下一种:
探索总结:还在摸索,不适合直接执行需求简报:已经足够清楚,可交给产品或设计价值判断:给出推进 / 试点 / 搁置 / 放弃建议干系人对齐记录:清楚记录分歧、共识和待决策项使用朴素业务语言。
把技术取舍翻译成这些影响:
可复用的提问清单、阶段说明和输出模板,参见 requirement-discovery-method.md 与 zh-cn.md。