Brief Builder

通过逐问引导,将模糊需求转化为可执行的结构化任务简报。

已扫描
适合谁
产品经理、内容策划人员
不适合谁
已有完整需求文档的用户、希望快速自动生成内容而无需交互的用户
国内可用性
需网络配置。可能需要网络配置或第三方服务可访问。
安装难度
新手友好(★☆☆)。基于终端操作、依赖、API Key 和本地环境要求的初步判断。

安装与下载

openclaw skills install @mohitagw15856/brief-builder

Skill 说明

命令、参数、文件名以原文为准

Brief Builder 技能

大多数弱质 AI 输出源于薄弱的简报——模型在猜测上下文,而非获取真实信息。本技能反其道而行之:它通过聚焦提问的方式与用户互动,一次只问一两个问题,并在答案模糊时深入追问,直到收集到足够信息以产出优质成果。随后,它将生成简报并移交下一步工作。整个价值在于以正确顺序提出正确的关键问题——而不是在第一个模糊句子上就开始产出。

必需输入

  • 原始需求 —— 请求人实际说出的内容,无论多么模糊(如“我们需要一个仪表盘”、“市场部想要一份一页纸”)。原话优于转述;他们话语中的空白处正是需要追问的线索。
  • 谁在提出需求,以及输出将由谁消费(如果已知)—— 同一个需求从 CEO 和实习生口中说出,所需简报应完全不同。
  • 可选:与该需求相关的任何先前资料(被替换的文档、引发此需求的对话记录等)。

如何运行此技能(交互式追问流程)

  1. 仔细阅读用户提供的内容,识别出任务类型(是发布?文档?决策?文案?)。
  2. 优先提出最少数量但高杠杆的问题,每次只问 1–2 个问题——绝不一次性抛出 20 个问题的大清单。从最能影响输出结果的问题开始。
  3. 对模糊回答进行追问(如“所有人” → “具体指哪些人?”;“很快” → “具体是什么日期?”),持续挖掘直至答案具体明确。
  4. 提供合理默认值:当用户不确定时,提出一个合理的默认选项,并请其确认(例如:“我假设是面向 B2B SaaS 创业者,除非你另有说明”)。
  5. 在信息足够时停止追问——不要过度追问。然后总结简报内容,并在产出前进行确认。

核心提问框架(根据任务类型灵活调整)

  • 目标 —— 成功的样子是什么?希望推动怎样的决策或行动?
  • 受众 —— 具体是为谁准备的?他们已知或相信什么?
  • 背景信息 —— 已存在哪些内容?背后的故事、限制条件、截止时间是什么?
  • 范围与格式 —— 多长?什么格式?将在何处呈现?
  • 语气与边界 —— 语调、必须包含的内容、禁止出现的内容,以及可参考的示例。
  • 成功标准 —— 他们将如何判断输出是否合格?

输出格式

1. 提问环节(交互式)

以对话形式逐批提出问题,每次 1–2 个,从最简单路径入手。(切勿一次性列出全部问题。)

2. 简报(信息收集完毕后生成)

简报:[任务名称]

  • 目标:
  • 受众:
  • 背景/输入:
  • 范围与格式:
  • 语气与边界:
  • 成功标准:
  • 开放假设: 仍保留默认的部分,需特别标注以便确认。

3. 交接环节

明确指出该简报应交付给哪个技能(或多个技能)继续处理(例如:“→ 运行 prd-template” 或 “→ landing-page-copy”),并询问是否继续推进。

质量检查清单

  • [ ] 问题分批提出,每次仅 1–2 个,且优先提出最具影响力的
  • [ ] 对模糊回答持续追问,直至获得具体信息(如具体人群、真实日期、明确细节)
  • [ ] 当用户不确定时,提供合理默认值,并明确标注为假设
  • [ ] 一旦信息足够即停止追问,不进行过度追问
  • [ ] 最终简报完整清晰,足以让其他技能独立产出高质量成果
  • [ ] 结尾主动移交至合适的后续技能

反模式警示

  • [ ] 不要基于模糊提示自行生成交付物——核心任务是先构建简报
  • [ ] 不要一次性抛出 15 个问题——应分步推进,优先关注最关键问题
  • [ ] 不接受模糊回答——“更多销量”、“所有人”、“很快”等均需追问具体含义
  • [ ] 不要无休止地追问——一旦能写出高质量简报,就应停止并总结
  • [ ] 不要沉默地做假设——默认时必须说明,并允许用户纠正

设计依据

源自创意/广告公司标准简报流程,以及结构化信息采集方法(如决策树式提问、渐进披露、确认后再产出)。

M
@mohitagw15856

已收录 6 个 Skill

相关推荐