brainstorming-to-issue

将头脑风暴内容整理成 GitHub Issue

核心原则

必需的子技能： 按照原文运行 superpowers:brainstorming（v7）。这项技能体现了 v7 所允许的“人类伙伴偏好”：书面设计保存在 GitHub issue 中，而不是 docs/ 中。它只补充 v7 尚未涵盖的内容：持久保存到 issue、仅凭 issue 恢复（适用于任何会话、任何运行环境）、[DRAFT] 标题前缀（表示“仍在头脑风暴中”），以及拆分。不要重述或重新解释 v7 的对话、复述、工作量估算、探索性验证、视觉配套、设计形态或构建者检查——遵循 v7 即可。

准确的 gh 命令、正文格式和 ## Brainstorm state 部分：issue-lifecycle.md。

开始

未提供编号：

1. 按关键词搜索未关闭的 issue。
2. 搜索标题中包含 [DRAFT] 的 issue。
3. 若找到可能匹配的 issue → 展示它并询问：采用 #N，还是从头开始？绝不默默复用或重复创建。
4. 若无匹配项（或用户选择“从头开始”）→ 创建 [DRAFT] issue，在正文末尾添加状态部分，并在提出第一个问题前完成；其 Next: 填写开场问题。
5. 发送 v7 的开场消息——除非 v7 的首次检查发现这是一个简单明确的任务：此时将请求写入 issue，将工作量标为 quick task，然后交接（不问开场问题；只有在用户要求时才开始构建）。

已提供编号： 使用 gh issue view N --json title,body,comments 加载 issue，然后按以下方式处理：

Issue 状态	处理方式
[DRAFT] + ## Brainstorm state	恢复
[DRAFT] + 旧版 ## Brainstorm log 或 <details> 日志	转换（见 issue-lifecycle.md），然后恢复
[DRAFT] + 两者都没有（此前退回，尚未进行头脑风暴）	添加状态部分，保留正文原样，然后恢复；如果没有冲突评论（见下文），则从“开始”第 5 步继续
没有 [DRAFT] + 状态部分或旧版 <details> 日志	修订（Next: 行表示修订正在进行：恢复）
没有 [DRAFT] + 两者都没有	占位内容：采用时，添加 [DRAFT]，将正文内容整合到设计中，添加状态部分，然后从“开始”第 5 步继续

恢复任何 [DRAFT] issue 时，都要读取最新评论（按 createdAt 排序）。如果有尚未反映在 Next: 或设计中的 plan-to-implementation 冲突评论，则将 Next: 设为“与用户解决这些冲突”；然后执行下方的全部 5 个修订步骤（交接时才移除 [DRAFT]）。

持久化

每次收到用户回复后，立即在做其他任何事之前执行以下操作（这样无论何时强制停止，都不会留下未完成事项）：

1. 获取当前正文。
2. 根据该正文重写，绝不依赖对话记忆：将结果写入相应的设计部分。
3. 将 Next: 设为你的下一条消息确切等待的内容（并添加此时已成立的任何 remember 行）；如果发送消息前等待的内容发生变化，则再次推送。
4. 推送正文。

当你用通俗语言告知用户工作量时（v7 的“评估工作量”），在同一次重写中将其记录为 Size:。设计部分应保留 v7 的标记：猜测要标明是我的猜测，我做出的选择要标明是我的决定，只有用户说过的内容才不加标记。不要保存复述文本、问答日志、决策历史或用户的原话。能轻易重做的工作不要中途保存：侦察、未完成的构建者检查、配套服务器。

恢复

绝不重新询问已解决的问题；标记为我的猜测的内容在用户确认前始终只是猜测。根据 Next: 采取行动：

• 问题 → 原样重新提问
• 复述 → 根据设计部分重新整理后再次呈现
• 构建者检查问题 → 在一条消息中原样重新提问；绝不重新执行检查；用户回答后，更新设计并交接
• 交接步骤 → 重新执行
• re-brainstorm — grew from <size>: <what was added> → 执行全部 5 个修订步骤，范围仅限新增内容

遵循 remember 行（Opted out of questions.、Visual companion declined.、Split:）。每次收到回复后都要继续持久化。

运行环境缺失项

没有子 Agent 工具：自行阅读 issue，充当构建者。没有浏览器：用文字描述选项。将视觉配套选择和探索性验证经验用文字写入设计。

Builder check（仅限项目）

将 builder-check-prompt.md 的文档指向 issue：“使用 gh issue view N --json title,body 阅读 issue #N。”在状态部分记录结果（Builder check: ran on this version. Questions for the user: …）；每个问题得到回答后都将其移除。

交接——v7 结尾的唯一例外

不写 docs/ 规范，不提交 commit，不用 writing-plans。在 v7 移交文档（项目）或说明获得批准（快速任务、小改动）时，按顺序完成以下 6 个步骤：

1. 检查正文是否符合该规模的要求：项目应有书面设计；快速任务或小改动应是简短说明，不要求特定章节（也不需要 builder check）。
2. 从标题中移除 [DRAFT]。
3. 将状态部分精简为该规模对应的交接后格式。
4. 提供 issue 链接和我的决策清单。
5. 提供该规模对应的交接语句：
   • 项目：“在新的会话中运行 issue-to-plan #N。”
   • 快速任务 / 小改动：“直接实施 #N，不需要计划”，然后列出状态部分中的构建步骤。
6. 停止（对于拆分任务，先提出下一个同级任务）。之后不再审查；运行下一步即表示批准。修改通过 brainstorming-to-issue #N 返回。

选择退出

用户选择跳过问题（开始时或之后均可）时：根据请求撰写 issue，保留此前得到的所有回答；标记我的决策；确定规模；添加 Opted out of questions.；然后交接。即使是项目，也不进行 builder check。

修订

1. 绝不重新添加 [DRAFT]。现在将旧的 <details> 日志转换（issue-lifecycle.md）。在新一轮交接之前，状态部分采用起草格式，并包含 Next:；照常持久化。
2. 针对用户希望修改的内容进行一轮 v7 对话；仅回放已修改的部分。
3. 设计有变更的项目必须针对新版本重新进行 builder check。
4. 重新确定规模，然后更新我的决策清单并再次交接。
5. 如果有未关闭的草稿 PR #M 为该 issue 提供了计划，则在交接时说明该计划现已过时，并将交接语句改为“关闭草稿 PR #M，然后在新的会话中运行 issue-to-plan #N。”不要自行编辑或关闭 PR 或计划。

同一会话内构建

用户提出要求时，可在此会话内按照 issue 的构建步骤构建快速任务或小改动；开始构建即表示批准。项目绝不能在此会话内构建：应指向在新的会话中运行 issue-to-plan #N。

拆分

当 v7 发现多个独立项目且你同意执行顺序时：为每个项目创建各自带有 Split: 行的 [DRAFT] issue，并一次讨论一个项目。交接后，提出下一个同级任务（用户可停止，并通过 brainstorming-to-issue #next 恢复）。同级任务之间真实存在的构建依赖应作为约束写入各自的设计。因正文达到 65k 限制而拆分，必须征得用户同意。

保护措施

• 仅使用 gh 处理 GitHub issues；从仓库内运行；绝不使用 --repo。
• 绝不压缩、删减或改述已记录的内容。如果正文接近 65,536 个字符，请让用户拆分。