brainstorm-to-issue

构思 → 意图 Issue

与 Superpowers 的关系

如果已安装 Superpowers，通常这项技能捕获的是 brainstorming 技能中的对话。对于尚无意图 Issue 的工作，brainstorming 可以有两种结尾：立即构建（通常会进行设计、规划和编码），或先记录。本技能提供的是先记录这一结尾——问题得到理解后、brainstorming 提出方案前，superpowers-issue-bridge 会提供这一选项。

Issue 记录的是意图，而不是规格说明：问题、预期结果，以及用户已经做出的决定。不要写入仅仅考虑过的方案、边缘情况分析，以及无人决定的设计细节。之后接手构建 Issue 的人会在那时进行设计，superpowers-issue-bridge 会以此 Issue 为起点开展 brainstorming。

适用场景

用户已经讨论过某个问题、需求或想法——无论是在 Superpowers 的 brainstorming 中，还是与任意 AI Agent 进行对话（这并不限于编码会话）——现在希望先记录下来，而不是立即构建。用户表示要这样做（例如“把这个提报上去”“我们把它转成 Issue”，或选择先记录）后，再运行此技能；问题仍在探索阶段时不要运行。

前置条件

1. 检查 docs/agents/issue-tracker.md 是否存在。如果不存在，告诉用户先运行 setup-issue-tracker 技能，然后停止——不要猜测使用哪个跟踪工具或仓库。
2. 从该文件中读取跟踪工具配置：
   • **GitHub 后端：**使用配置中记录的 owner/repo。确认 gh 已通过身份验证（gh auth status）；如果没有，告诉用户运行 gh auth login，然后停止。
   • **本地 Markdown 后端：**写入 .scratch/<feature>/，而不是创建 GitHub Issue——跳过以下所有 gh 步骤，并使用转换为 slug 的标题作为文件名。
   • **其他／自由格式后端：**遵循记录的说明；如果说明未涵盖此情形，请询问用户。
   • 如果用户明确指定本次运行使用不同的仓库或跟踪工具，则使用该指定，而不是配置中的内容——一次性覆盖无需重新运行设置。

步骤

1. 重新阅读头脑风暴对话，并尽可能使用用户自己的措辞提取以下内容：

   • 标题 — 对问题或功能的简短命名（这会成为 issue 标题，而不是正文中的 # 标题）。
   • 问题 — 目前有什么问题、影响哪些人，以及为什么重要。
   • 预期成果 — 说明怎样才算“更好”，描述成果而非实现方式。
   • 受影响的用户和系统 — 会影响哪些人和事物。
   • 约束 — 已提及的硬性限制（合规、安全、范围边界、截止日期），以及用户明确作出的每项决定，并将其表述为要求（“复用现有任务队列”）。负责实现 issue 的人会将本节视为约束性要求——包括无法提问的 Agent——因此请记录用户作出的决定，绝不能把对话中仅讨论过的选项写进去。
   • 待解决的问题 — 所有真正尚未解决的问题。保留真实的不确定性，不要编造确定的答案。

2. 如果某个部分没有来自对话的真实内容，请写“未发现”，不要编造细节，也不要为了让各部分看起来完整而凑内容。

3. 阅读 assets/intent-issue.md，并严格按其内容填写——标题和顺序都保持一致。标题要使用两次：一次作为跟踪系统中 issue 自身的标题，一次作为正文顶部的 H1 标题，这样导出、打印或在跟踪系统之外查看时，内容仍然通顺。

4. 向用户展示拟定的标题和正文，并请求确认或修改，然后再创建任何内容。不要悄无声息地创建 issue。

5. 确认后，在配置的后端中创建 issue。在 GitHub 上：

   gh issue create \
     --repo <owner>/<repo> \
     --title "<title>" \
     --body-file <tmp-file> \
     --label <label from docs/agents/issue-tracker.md, default: intent>
   

   （如果标签不存在，请先使用 gh label create <label> 创建标签——标签缺失时不要悄无声息地失败。）

6. 将 issue 的 URL（或文件路径）报告给用户。此意图 issue 是后续工作的入口：无论之后由用户还是 Agent 实现，都从这里开始；superpowers-issue-bridge 会以此为种子启动头脑风暴，并将完成的工作链接回此 issue。

7. 如果这是 Superpowers 头脑风暴中“先跟踪”流程的结尾，会话到此结束。只有用户现在要求实现时，才继续编写规范、计划或代码。

不要做的事

• 不要在头脑风暴过程中执行此流程——等到用户明确确认讨论已结束。
• 不要为没有内容的部分编造内容。
• 不要把对话中仅讨论过的选项记录为约束——只记录用户已作出的决定。
• 不要在展示草稿之前创建 issue。
• 如果无法推断目标仓库，不要猜测。
• 创建 issue 后，不要继续编写规范、writing-plans 或代码。

---

非 Claude Code 版本（纯提示词）

对于没有技能/自动发现机制的工具，可在头脑风暴结束后，将以下内容作为一次性提示词粘贴进去：

根据上面的对话，严格按照以下模板起草一个 issue——先写一个带标题的 H1，然后依次写 Problem、Proposed outcome、Affected users and systems、Constraints、Open questions，每个部分用几句话说明；对于我们实际上没有讨论过的内容，写“None identified”。在 Constraints 中，写入硬性限制和我们明确作出的每项决定，并将其表述为要求；不要写入我们仅讨论过的选项。以纯文本形式给我标题和正文；暂时不要创建任何内容，只展示草稿。

然后自行创建——在 GitHub 上，使用：

gh issue create --repo <owner>/<repo> --title "<title>" --body-file draft.md --label intent