brainstorming-to-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming Into a GitHub Issue

头脑风暴沉淀为GitHub Issue

Overview

概述

Reuse the full

superpowers:brainstorming

dialogue, but persist the spec as a GitHub issue instead of a

docs/

file — and persist it incrementally, across sittings. The issue is created early with a

[DRAFT]

title prefix and rewritten after every answer, so you can walk away and resume anytime. On final approval the prefix is stripped and the issue becomes the durable "what/why" spec. This skill ends the moment the issue is finalized; implementation is a separate, later concern.

Core principle: brainstorming's dialogue is medium-agnostic and reused unchanged. Only its persistence (steps 6-9) is overridden — and here that persistence is a resumable draft lifecycle, not a single end-of-session write.

复用完整的

superpowers:brainstorming

对话流程，但将规格说明持久化为GitHub issue而非

docs/

目录下的文件——且支持跨会话增量持久化。issue会在早期创建，标题带有

[DRAFT]

前缀，每次得到回答后都会更新内容，因此你可以随时暂停并在之后恢复。最终获批后，前缀会被移除，该issue即成为长期有效的“做什么/为什么做”规格说明。本技能在issue定稿后立即结束；实现工作是后续独立的事项。

核心原则： 头脑风暴的对话过程与媒介无关，可原样复用。仅其持久化环节（第6-9步）会被覆盖——此处的持久化是可恢复的草稿生命周期，而非单次会话结束时的一次性写入。

When to Use

适用场景

You want a spec captured somewhere trackable and linkable, not buried in
```
docs/
```
.
You want to brainstorm over time — start now, answer more questions later — without losing context between sittings.
Building will happen later or by someone/something else — the issue is the handoff.

When NOT to use: you're about to implement immediately in this same session with no need for a durable spec artifact (use

superpowers:brainstorming

directly), or the spec belongs in a versioned design doc.

你希望规格说明存放在可追踪、可链接的地方，而非埋没在
```
docs/
```
目录中。
你希望跨时间开展头脑风暴——现在启动，之后再回答更多问题——且不会在多次会话间丢失上下文。
开发工作将在后续进行，或由其他人员/工具完成——issue作为交接载体。

不适用场景： 你打算在同一次会话中立即开始实现，不需要长期有效的规格说明产物（可直接使用

superpowers:brainstorming

），或者规格说明需要存放在版本化的设计文档中。

State Model

状态模型

Two title states, no new labels:

Title	Meaning
`[DRAFT] feat(scope): summary`	brainstorm in progress (resumable)
`feat(scope): summary`	approved — reads like any normal repo spec issue

Find in-progress drafts with:

gh issue list --search "[DRAFT] in:title"

仅两种标题状态，不新增标签：

标题	含义
`[DRAFT] feat(scope): summary`	头脑风暴进行中（可恢复）
`feat(scope): summary`	已获批——与仓库中普通的规格issue无差异

查找进行中的草稿可使用：

gh issue list --search "[DRAFT] in:title"

Entry: Start, Dedupe, or Resume

入口：启动、去重或恢复

Determine which mode you're in before asking any questions. Exact

gh

commands are in

issue-lifecycle.md

dot

digraph entry {
    "Issue number given?" [shape=diamond];
    "Load issue, read body + Brainstorm log" [shape=box];
    "Search open issues for a match" [shape=box];
    "Plausible placeholder/draft found?" [shape=diamond];
    "Ask user: adopt #N or start fresh?" [shape=box];
    "Create [DRAFT] issue immediately" [shape=box];
    "Resume the loop from next open question" [shape=doublecircle];

    "Issue number given?" -> "Load issue, read body + Brainstorm log" [label="yes"];
    "Issue number given?" -> "Search open issues for a match" [label="no"];
    "Search open issues for a match" -> "Plausible placeholder/draft found?";
    "Plausible placeholder/draft found?" -> "Ask user: adopt #N or start fresh?" [label="yes"];
    "Plausible placeholder/draft found?" -> "Create [DRAFT] issue immediately" [label="no"];
    "Ask user: adopt #N or start fresh?" -> "Load issue, read body + Brainstorm log" [label="adopt"];
    "Ask user: adopt #N or start fresh?" -> "Create [DRAFT] issue immediately" [label="fresh"];
    "Load issue, read body + Brainstorm log" -> "Resume the loop from next open question";
    "Create [DRAFT] issue immediately" -> "Resume the loop from next open question";
}

Issue number given ("brainstorm gh issue 47") → this is the resume/adopt path. Load it. If it lacks the
```
[DRAFT]
```
prefix or the structured body, add them (fold any existing body text into Summary/Motivation) — see
```
issue-lifecycle.md
```
.
No number → dedupe first, with BOTH searches (you may have already logged a placeholder):
1. ```
gh issue list --state open --search "<keywords>"
```
2. ```
gh issue list --search "[DRAFT] in:title"
```
If a plausible match exists, surface it and ask before adopting. Never silently reuse.
No match → create the
```
[DRAFT]
```
issue immediately, from the raw idea, with a mostly-TBD body. Do this before the dialogue so nothing is ever conversation-only.

在提出任何问题之前，先确定当前处于哪种模式。具体的

gh

命令请参考

issue-lifecycle.md

。

dot

digraph entry {
    "Issue number given?" [shape=diamond];
    "Load issue, read body + Brainstorm log" [shape=box];
    "Search open issues for a match" [shape=box];
    "Plausible placeholder/draft found?" [shape=diamond];
    "Ask user: adopt #N or start fresh?" [shape=box];
    "Create [DRAFT] issue immediately" [shape=box];
    "Resume the loop from next open question" [shape=doublecircle];

    "Issue number given?" -> "Load issue, read body + Brainstorm log" [label="yes"];
    "Issue number given?" -> "Search open issues for a match" [label="no"];
    "Search open issues for a match" -> "Plausible placeholder/draft found?";
    "Plausible placeholder/draft found?" -> "Ask user: adopt #N or start fresh?" [label="yes"];
    "Plausible placeholder/draft found?" -> "Create [DRAFT] issue immediately" [label="no"];
    "Ask user: adopt #N or start fresh?" -> "Load issue, read body + Brainstorm log" [label="adopt"];
    "Ask user: adopt #N or start fresh?" -> "Create [DRAFT] issue immediately" [label="fresh"];
    "Load issue, read body + Brainstorm log" -> "Resume the loop from next open question";
    "Create [DRAFT] issue immediately" -> "Resume the loop from next open question";
}

提供了issue编号（比如“brainstorm gh issue 47”）→ 这是恢复/采纳路径。加载该issue。如果它缺少
```
[DRAFT]
```
前缀或结构化正文，请补充（将现有正文内容整合到“摘要/动机”部分）——详见
```
issue-lifecycle.md
```
。
未提供编号 → 先进行去重，需执行两种搜索（你可能之前已经记录了占位issue）：
1. ```
gh issue list --state open --search "<keywords>"
```
2. ```
gh issue list --search "[DRAFT] in:title"
```
如果存在合理的匹配项，将其展示给用户，并在采纳前先询问。绝不能静默复用。
无匹配项 → 立即基于原始想法创建
```
[DRAFT]
```
issue，正文大部分内容标记为待确定（TBD）。请在对话开始之前完成创建，确保所有内容都不会仅存在于对话中。

The Draft Lifecycle (core loop — all 4 steps)

草稿生命周期（核心循环——共4步）

REQUIRED SUB-SKILL: Run
```
superpowers:brainstorming
```
for the dialogue — steps 1-5 exactly as written: explore context, clarifying questions one at a time, propose 2-3 approaches, present the design in sections, get user approval. Do NOT collapse this into a single self-answered pass; the one-question-at-a-time HIL loop is the point.
Override inside that sub-skill — its persistence only (brainstorming's own steps 6-9 are replaced by this skill):
- Never write a spec file under
```
docs/
```
  (no
```
docs/superpowers/specs/…
```
  ).
- Never commit a spec doc.
- Never invoke
```
writing-plans
```
  — there is no plan step here.
- The spec's only home is the GitHub issue. This override removes brainstorming's ending only — when the dialogue completes, continue with THIS skill's Finalize → Ready below.
Persist after EVERY answer — all three parts, immediately, every round (see
```
issue-lifecycle.md
```
):
1. Fold the answer into the relevant spec section.
2. Check off the answered log item.
3. Set the next
```
[ ]
```
  question.
Not batched, not deferred to the end: a hard interruption after any answer must leave the issue current. Build each update from the issue's current body — never regenerate it from conversation memory, and never drop, shorten, or paraphrase earlier answers.
Repeat until the design is presented and approved.

The body is the living spec; a

## Brainstorm log

section (visible while draft) carries the checkboxed Q&A + the next open question, which IS the resume state.

必选子技能： 运行
```
superpowers:brainstorming
```
完成对话——严格按照其第1-5步执行：探索上下文、每次只提一个澄清问题、提出2-3种方案、分模块展示设计、获得用户批准。不要将其压缩为单次自问自答的流程；每次一个问题的人在回路（HIL）循环是核心。
覆盖该子技能的仅持久化环节（头脑风暴本身的第6-9步将被本技能替换）：
- 不要在
```
docs/
```
  目录下写入任何规格文件（不要创建
```
docs/superpowers/specs/…
```
  ）。
- 不要提交规格文档。
- 不要调用
```
writing-plans
```
  ——此处没有计划阶段。
- 规格说明的唯一载体是GitHub issue。该覆盖仅移除头脑风暴的结尾部分——对话完成后，继续执行本技能的“定稿→就绪”流程。
每次得到回答后立即持久化——每一轮都要立刻完成以下三个步骤（详见
```
issue-lifecycle.md
```
）：
1. 将回答整合到对应的规格章节中。
2. 勾选已回答的日志项。
3. 设置下一个待回答的
```
[ ]
```
  问题。
不要批量处理，也不要推迟到最后：即使在任何回答后发生强制中断，也必须保证issue内容是最新的。每次更新都要基于issue的当前正文进行——绝不要从对话记忆中重新生成，也不要删除、精简或改写之前的回答。
重复上述流程，直到设计方案被展示并获得批准。

issue正文是活的规格说明；其中

## Brainstorm log

（头脑风暴日志）章节（草稿状态下可见）记录了带复选框的问答内容和下一个待回答问题，这就是恢复状态的依据。

Finalize → Ready (all 5 steps, in order)

定稿→就绪（共5步，按顺序执行）

Pre-finalize gate — when the design is approved, confirm each check aloud before editing:

The user explicitly approved the presented design.
The issue body is current through the latest answer (nothing exists only in conversation).
No
```
docs/
```
spec file was written and
```
writing-plans
```
was never invoked.

Then:

Spec self-review on the issue body: scan for placeholders/TBDs, internal contradictions, scope creep, ambiguous requirements. Fix inline.
Strip the
[DRAFT]
prefix from the title.
Collapse
## Brainstorm log
into a
<details>
block at the bottom so the spec reads clean by default while the decision trail stays recoverable.
Show the user the issue URL and ask them to review. If they request changes, edit and re-run the self-review. This is the spec review gate — keep it.
STOP. The issue is the handoff. Do not branch, plan, or implement.

Exact commands for all of the above are in

issue-lifecycle.md

定稿前检查项——设计获批后，在编辑前请逐一确认以下内容：

用户已明确批准所展示的设计方案。
issue正文已更新至最新的回答（没有内容仅存在于对话中）。
未创建任何
```
docs/
```
目录下的规格文件，且从未调用过
```
writing-plans
```
。

然后：

规格自审：检查issue正文，查找占位符/待确定项、内部矛盾、范围蔓延、需求模糊等问题，直接在正文中修复。
移除标题中的
[DRAFT]
前缀。
将
## Brainstorm log
（头脑风暴日志）折叠到页面底部的
<details>
块中，这样默认查看规格时更整洁，同时决策轨迹仍可追溯。
向用户展示issue的URL并请其审核。如果用户提出修改，编辑后重新执行自审。这是规格审核的关口——必须保留。
停止。 issue已作为交接产物。不要创建分支、制定计划或开始实现。

上述所有操作的具体命令请参考

issue-lifecycle.md

。

Issue Backend:

gh

Issue 底层工具：

gh

This skill deliberately uses GitHub issues (
gh
). Do not route the spec to a non-GitHub tracker and do not hesitate — the whole purpose of this skill is a GitHub-issue spec. (If a caller genuinely wants a different tracker, they want a different skill, not this one.)

本技能明确使用GitHub issues（通过
gh
命令）。不要将规格说明转到非GitHub的跟踪工具，也不要犹豫——本技能的核心目的就是生成GitHub issue格式的规格说明。（如果用户确实需要其他跟踪工具，他们需要的是其他技能，而非本技能。）

Downstream (out of scope — do not do it here)

下游工作（不在范围内——此处不执行）

Implementation happens later. When it does, any implementation plan is optional, scope-gated, and lives in the PR description — never in

docs/

, never in this issue. This skill does not produce or persist a plan.

实现工作将在后续进行。当开始实现时，任何实现计划都是可选的、受范围约束的，且存放在PR描述中——绝不要放在

docs/

目录中，也绝不要放在这个issue里。本技能不生成或持久化任何计划。

Common Mistakes

常见错误

Mistake	Fix
Creating the issue only at the end	Create the `[DRAFT]` issue on start (or adopt one); persist every round
Batching persistence / holding answers in conversation only	Update the issue body after EVERY answer
Silently reusing a found issue	Surface the match and ask before adopting
Skipping the dedupe search when no number is given	Search open issues first — a placeholder may already exist
Stopping when brainstorming's steps 6-9 are overridden	The override replaces those steps with THIS skill's Finalize → Ready — run it
Finalizing without stripping `[DRAFT]`	Ready = prefix stripped + log collapsed to `<details>`
Following brainstorming to a `docs/` file + commit	Divert per the persistence override; the issue is the only artifact
Invoking `writing-plans`	No plan step — stop at the issue
Self-answering all clarifying questions in one pass	Run the real one-question-at-a-time dialogue with the user
Ad-hoc issue structure that differs every run	Use the template in `issue-lifecycle.md`
Hardcoding `--repo owner/name`	Run from the repo; let `gh` infer from the remote
Compressing or summarizing recorded decisions as the body grows	Never — fidelity first; if the body nears GitHub's 65,536-character limit, surface it and ask the user to split the spec into multiple issues

错误做法	修正方法
仅在最后才创建issue	启动时就创建 `[DRAFT]` issue（或采纳已有issue）；每轮都更新持久化
批量持久化/仅在对话中保留回答	每次得到回答后立即更新issue正文
静默复用找到的issue	展示匹配项，在采纳前先询问用户
未提供编号时跳过去重搜索	先搜索开放的issue——可能已经存在占位issue
头脑风暴的第6-9步被覆盖后就停止	覆盖是用本技能的“定稿→就绪”流程替换这些步骤——继续执行该流程
定稿时未移除 `[DRAFT]` 前缀	就绪状态 = 移除前缀 + 日志折叠到 `<details>` 中
按照头脑风暴流程生成 `docs/` 文件并提交	按照持久化覆盖规则调整；issue是唯一产物
调用 `writing-plans`	没有计划阶段——到issue环节就停止
一次性自问自答完所有澄清问题	与用户进行真实的、每次一个问题的对话
每次运行的issue结构都不统一	使用 `issue-lifecycle.md` 中的模板
硬编码 `--repo owner/name`	在仓库目录下运行；让 `gh` 从远程仓库自动推断
随着正文增长压缩或总结已记录的决策	绝对不要——保真优先；如果正文接近GitHub的65536字符限制，告知用户并请其将规格拆分为多个issue

Red Flags — STOP

危险信号——立即停止

About to ask questions before the
```
[DRAFT]
```
issue exists (or is adopted)
Answers accumulating in the conversation but not on the issue
About to shorten or summarize recorded spec content (for any reason, including GitHub's 65k body limit) instead of asking the user to split the spec
About to reuse a found issue without asking
Finalizing with the
```
[DRAFT]
```
prefix still in the title
About to write anything under
```
docs/superpowers/specs/
```
About to invoke
```
writing-plans
```

All of these mean: get the draft issue current first, with real HIL approval, before continuing.

在
```
[DRAFT]
```
issue创建（或被采纳）之前就打算提问
回答仅累积在对话中，未更新到issue
打算缩短或总结已记录的规格内容（出于任何原因，包括GitHub正文65k字符限制），而不是请用户拆分规格
打算不询问就复用找到的issue
定稿时标题中仍带有
```
[DRAFT]
```
前缀
打算在
```
docs/superpowers/specs/
```
目录下写入任何内容
打算调用
```
writing-plans
```

出现以上任何情况都意味着：在继续之前，先确保草稿issue是最新的，且获得了真实的人在回路（HIL）批准。

brainstorming-to-issue

Original

Translation

Brainstorming Into a GitHub Issue

头脑风暴沉淀为GitHub Issue

Overview

概述

When to Use

适用场景

State Model

状态模型

Entry: Start, Dedupe, or Resume

入口：启动、去重或恢复

The Draft Lifecycle (core loop — all 4 steps)

草稿生命周期（核心循环——共4步）

Finalize → Ready (all 5 steps, in order)

定稿→就绪（共5步，按顺序执行）

Issue Backend:
`gh`

Issue 底层工具：
`gh`

Downstream (out of scope — do not do it here)

下游工作（不在范围内——此处不执行）

Common Mistakes

常见错误

Red Flags — STOP

危险信号——立即停止

brainstorming-to-issue

Original

Translation

Brainstorming Into a GitHub Issue

头脑风暴沉淀为GitHub Issue

Overview

概述

When to Use

适用场景

State Model

状态模型

Entry: Start, Dedupe, or Resume

入口：启动、去重或恢复

The Draft Lifecycle (core loop — all 4 steps)

草稿生命周期（核心循环——共4步）

Finalize → Ready (all 5 steps, in order)

定稿→就绪（共5步，按顺序执行）

Issue Backend: gh

Issue 底层工具：gh

Downstream (out of scope — do not do it here)

下游工作（不在范围内——此处不执行）

Common Mistakes

常见错误

Red Flags — STOP

危险信号——立即停止

Issue Backend:
`gh`

Issue 底层工具：
`gh`