技能介绍

问题从哪来

团队手里往往已经有 Pulse 的漏斗、Voice 的反馈主题、Lens 里的可复用逻辑，但 backlog 里仍堆着「加个按钮」「做个报表」这类按解法命名的条目。真正缺的是：把信号收敛成面向具体角色、可验证假设的一条功能提案，并且能交给 Scribe / Builder 继续写正式规格——而不是再开一轮无边界 brainstorm 或直接写代码。

Spark 怎么做

火花（Spark）的定位是功能发现与提案撰写：每次会话默认只产出 ONE 条高价值功能，文档形态通常是 docs/proposals/RFC-[name].md。

核心约束包括：

用用户问题命名提案（痛点），而不是功能形状；JTBD 写「寻求的进展」，避免把客户工作当成活动清单。
提案锚在机会解决方案树（结果→机会→解决方案→实验），并给出 RICE、影响-努力象限、可检验假设与失败条件（而不只有成功标准）。
偏好重用现有数据、工作流与交付渠道；在竞争框架里显式考虑非消费与变通办法（表格、邮件线程等补偿行为）。
工作流：IGNITE → SYNTHESIZE → SPECIFY → VERIFY → PRESENT；子命令如 propose（默认 RFC）、plan（优先级评分）、brainstorm、refine、opportunity、kill、retro、multi（多引擎并行构思）按首 token 路由。

上游可接 Pulse、Voice、Compete、Bond、Cast、Lens、Flux、Void、Magi；下游常见移交 Scribe（正式规格）、Builder（实现规格）、Forge（原型前）、Magi（高风险 Go/No-Go）。

边界与注意点

不做：写实现代码；无角色/无商业理由的功能；仅验证已拍板想法（需在收敛前探索 ≥2 个替代问题框架）。
先路由别处：纯技术可行性摸底 → Scout；研究设计与综合 → Field；反馈聚合 → Voice；指标诊断 → Pulse；竞争分析本身 → Compete；写码/原型 → Forge / Builder。
涉及新外部依赖、核心数据模型/隐私/安全边界变更，或超出产品范围时，应先澄清再提案；超大未评分 backlog（50+）建议先 plan 修剪再 propose。