Superpowers brainstorming 技能实战：把模糊想法变成经批准的规格说明

Superpowers 的 brainstorming 技能是该项目"先设计、后实现"方法论的第一道关卡：它规定在写任何代码之前，Agent 必须先通过协作对话把想法打磨成完整的设计文档（spec），并经用户批准后才允许进入实现规划。本文以 skills/brainstorming/SKILL.md 为主体，完整解析其硬门禁（HARD-GATE）、九步检查清单、流程状态图与规格自审机制，并结合配套指南 visual-companion.md 和零依赖服务器实现 server.cjs，说明视觉协作伴侣（Visual Companion）的协议、鉴权与生命周期细节，帮助读者在任意支持 skill 的 Agent 环境中复现这套"从 idea 到 spec"的工作流。

定位与触发：HARD-GATE 为什么存在

brainstorming 技能的 frontmatter 声明了它的触发条件与使命：

name: brainstorming
description: "You MUST use this before any creative work - creating features,
  building components, adding functionality, or modifying behavior.
  Explores user intent, requirements and design before implementation."

技能开篇给出总纲：先理解当前项目上下文，然后每次只问一个问题来打磨想法；一旦理解了要构建什么，就呈现设计并获得用户批准。

随后是全文最核心的一条约束——硬门禁：

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.

（在呈现设计并获用户批准之前，不得调用任何实现类技能、写任何代码、搭任何脚手架或采取任何实现动作。这适用于每一个项目，无论它看起来多简单。）

技能还专门辟一节击破最常见的合理化借口——反模式："这个太简单了，不需要设计"：

每个项目都走这个流程。待办清单、单函数工具、配置修改，全都算。"简单"项目恰恰是未经审视的假设造成最多返工的地方。设计可以很短（真正简单的项目几句话即可），但你必须呈现它并拿到批准。

这条硬门禁的意义在于：它把"是否先设计"从判断题变成了流程题。Agent 没有任何裁量空间，唯一的问题是设计该写多长。仓库 README.md 也将其列为工作流的第一环："brainstorming - Activates before writing code. Refines rough ideas through questions, explores alternatives, presents design in sections for validation. Saves design document."

九步检查清单与流程状态图

SKILL.md 要求 Agent 对下列每一项都创建任务并按序完成（You MUST create a task for each of these items and complete them in order）：

1. 探索项目上下文（Explore project context）——查看文件、文档、最近的提交；
2. 按需即时提供视觉伴侣（Offer the visual companion just-in-time）——不要开场就提。当第一次出现"画出来比说出来更清楚"的问题时再提出（单独一条消息）；用户批准后浏览器标签页为你打开。如果始终没有出现需要视觉呈现的问题，就永远不要提；
3. 提澄清问题（Ask clarifying questions）——一次一个，理解目的/约束/成功标准；
4. 提出 2-3 种方案（Propose 2-3 approaches）——附权衡与推荐；
5. 呈现设计（Present design）——按复杂度分节呈现，每节获得用户确认；
6. 写设计文档（Write design doc）——保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交；
7. 规格自审（Spec self-review）——快速内联检查占位符、矛盾、歧义、范围（详见下文）；
8. 用户审阅已写好的规格（User reviews written spec）——进入下一步前请用户审阅 spec 文件；
9. 过渡到实现（Transition to implementation）——调用 writing-plans 技能创建实施计划。

技能用一张 Graphviz 状态图明确了流程走向：

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

注意图中的双圆终点：brainstorming 的唯一合法后继是 writing-plans。技能原文强调："The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans."（头脑风暴之后你唯一允许调用的技能是 writing-plans。）这条单向出口设计保证了设计→计划→实现的链路不被跳步。

流程详解：范围检查、一次一问与隔离式设计

理解想法（Understanding the idea）

• 先检查项目现状（文件、文档、最近的提交）；
• 先评估范围再问细节：如果请求描述的是多个独立子系统（例如"建一个带聊天、文件存储、计费和分析的平台"），要立即指出，不要在需要先分解的项目上浪费问题；
• 如果项目大到一份 spec 装不下，帮助用户分解为子项目——哪些是独立部分、它们如何关联、以什么顺序构建——然后对第一个子项目走正常设计流程。每个子项目各自经历 spec → plan → implementation 循环；
• 对范围合适的项目，一次一个问题来打磨想法；
• 优先用选择题，开放式也可以；每条消息只问一个问题，一个话题需要更多探索就拆成多个问题；
• 聚焦三件事：目的（purpose）、约束（constraints）、成功标准（success criteria）。

探索方案（Exploring approaches）

• 提出 2-3 个不同方案并给出权衡；
• 以对话式口吻呈现选项，推荐项放在最前并解释理由；
• 无情地执行 YAGNI——从每个方案和设计中删掉不必要的功能。

呈现设计（Presenting the design）

• 分节呈现，每节的篇幅与其复杂度匹配：直白的小节几句话即可，细腻的小节最多 200-300 词；
• 每节后询问"到这里看起来对吗"；
• 覆盖：架构、组件、数据流、错误处理、测试；
• 某节讲不通时随时返回澄清。

为隔离与清晰而设计（Design for isolation and clarity）

这是 SKILL.md 中最有方法论价值的一段：

• 把系统拆成更小的单元，每个单元只承担一个清晰职责，通过定义良好的接口通信，可被独立理解与测试；
• 对每个单元都应能回答：它做什么、怎么用、依赖什么？
• 如果不读内部实现就能理解一个单元的对外行为，并且修改内部实现不会破坏使用方，边界才算合格；
• 更小、边界清晰的单元对 Agent 本身也更友好——你能更好地推理"可以一次放进上下文"的代码，文件聚焦时你的编辑更可靠。文件变大往往是它职责过重的信号。

在既有代码库中工作（Working in existing codebases）

• 提出改动前先探索现有结构，遵循既有模式；
• 如果现有代码的问题会影响当前工作（例如文件过大、边界不清、职责纠缠），把针对性的改进纳入设计——就像优秀开发者顺手改进自己在动的代码；
• 不做与当前目标无关的重构。

设计之后：文档落盘、自审与用户审阅门禁

文档（Documentation）

• 把验证后的设计（spec）写到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md（用户对存放位置的偏好优先于此默认值）；
• 如有 elements-of-style:writing-clearly-and-concisely 技能可用则使用；
• 把设计文档提交到 git。

这个目录在本仓库本身就是活证据：docs/superpowers/specs/ 下存放着该技能反复产出的真实设计文档，例如 2026-02-19-visual-brainstorming-refactor-design.md、2026-03-11-zero-dep-brainstorm-server-design.md、2026-06-10-visual-companion-auth-hardening-design.md，命名全部符合 YYYY-MM-DD-<topic>-design.md 规范，且每个 spec 通常有对应的 docs/superpowers/plans/ 下的计划文档——正是第 9 步 writing-plans 的产物。

规格自审（Spec Self-Review）

写完 spec 后"用新眼睛"复查四项，发现问题直接内联修复，无需再走一轮审查：

1. 占位符扫描（Placeholder scan）：有没有 "TBD"、"TODO"、未完成章节或含糊需求？修掉；
2. 内部一致性（Internal consistency）：章节之间是否互相矛盾？架构与功能描述是否对得上？
3. 范围检查（Scope check）：是否聚焦到能装进单一实施计划，还是需要分解？
4. 歧义检查（Ambiguity check）：有没有能作两种解读的需求？有就选定一种并写明确。

仓库内还配套了一份用于派发审查子代理的提示词模板 spec-document-reviewer-prompt.md，它把自审的四项扩展为可量化的审查表（Completeness / Consistency / Clarity / Scope / YAGNI），并明确校准原则："只标记会在实施规划中造成真实问题的缺陷"——措辞润色、风格偏好不构成 issue，"除非会导致糟糕的计划，否则批准"。输出格式为 Status: Approved | Issues Found 加按节列出的问题与建议。

用户审阅门禁（User Review Gate）

自审通过后，必须先请求用户审阅 spec 再继续，技能给出了逐字话术：

"Spec written and committed to <path>. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."

然后等待用户回复。用户要求修改就修改并重新跑自审循环；只有用户批准后才继续。

进入实现（Implementation）

调用 writing-plans 技能创建详细实施计划——再次强调：不得调用任何其他技能，writing-plans 是唯一的下一步。writing-plans 技能则规定计划保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md，形成 spec 与 plan 一一对应的目录结构（如 2026-03-11-zero-dep-brainstorm-server.md 对应前述 spec）。

Visual Companion：按需开启的浏览器协作

设计哲学：是工具，不是模式

SKILL.md 的 Visual Companion 一节定义了一个浏览器端伴侣，用于在头脑风暴中展示 mockup、图表和可视化选项。它被明确定位为工具而非模式：接受伴侣意味着"对受益于视觉呈现的问题可以使用它"，而不是"每个问题都走浏览器"。

何时提供（just-in-time offering）

不要开场就提供。等到真的出现"画出来比说清楚更好"的问题——是真正的 mockup/布局/图表问题，而不仅是 UI 话题——才第一次、单独一条消息提出：

"This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you."

要求：这条 offer 必须是独立消息——只有 offer 本身，不含澄清问题、摘要或其他内容——然后等待用户回复。用户接受后，用 --open 启动服务器让其浏览器自动打开第一个界面；用户拒绝则继续纯文本，除非用户主动提起，否则不再提供。

逐问题决策（Per-question decision）

即使用户接受了伴侣，也要对每个问题单独决定走浏览器还是终端。判据只有一条："用户通过'看'是否比'读'理解得更好？"

• 用浏览器：内容本身就是视觉的——mockup、线框图、布局对比、架构图、并排视觉设计；
• 用终端：内容是文字的——需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策。

一个反复出现的例子说明这条判据："这个语境下 personality 是什么意思？"是概念问题——用终端；"哪个向导（wizard）布局更好？"是视觉问题——用浏览器。关于 UI 话题的问题不自动等于视觉问题。

用户同意使用后，Agent 需先读取详细操作指南 visual-companion.md 再继续。

Visual Companion 实操手册：从启动到收尾

工作原理与目录结构

服务器监视一个目录里的 HTML 文件，把最新的那个服务给浏览器。Agent 把 HTML 写入 screen_dir，用户在浏览器中看到并可点击选择选项；选择被记录到 state_dir/events，Agent 在下一轮读取。

内容片段 vs 完整文档：如果 HTML 文件以 <!DOCTYPE 或 <html 开头，服务器原样服务（只注入 helper 脚本）；否则服务器自动用 frame 模板包裹——加上页头、CSS 主题、连接状态与全部交互基础设施。默认写内容片段，只有在需要完全控制页面时才写完整文档。这一点在源码中有对应实现：server.cjs 中的 isFullDocument() 用 trimStart().toLowerCase() 判断前缀，wrapInFrame() 把内容替换进 frame-template.html 的 <!-- CONTENT --> 占位符。

启动会话与参数全解

# 在用户批准伴侣之后再启动。--open 在第一个界面自动打开浏览器；
# --project-dir 让 mockup 持久化并支持同端口重启。
scripts/start-server.sh --project-dir /path/to/project --open

# 返回:
# {"type":"server-started","port":52341,
#  "url":"http://localhost:52341/?key=ab12…",
#  "screen_dir":"/path/to/project/.superpowers/brainstorm/12345-1706000000/content",
#  "state_dir":"/path/to/project/.superpowers/brainstorm/12345-1706000000/state"}

启动后保存响应中的 screen_dir 和 state_dir。带 --open 时推送第一个界面后浏览器自己打开，无需让用户手动打开，但仍要分享 URL 作为后备（无头/远程环境不会自动打开）。

stop-server.sh 与 start-server.sh 支持的完整参数（以脚本头注释为准）：

参数	说明
--project-dir <path>	会话文件存到 <path>/.superpowers/brainstorm/ 而非 /tmp，服务器停止后文件仍保留
--host <bind-host>	绑定地址（默认 127.0.0.1；远程/容器环境用 0.0.0.0）
--url-host <host>	返回 URL JSON 中显示的域名
--idle-timeout-minutes <n>	空闲 n 分钟后自动关闭（默认 240 = 4 小时，须为正整数）
--open	用户批准后第一个界面自动打开浏览器
--foreground（别名 --no-daemon）	在前台运行，不做后台化
--background（别名 --daemon）	强制后台模式（覆盖 Codex 的自动前台化）

会话 key 鉴权：URL 中带 ?key=… 会话密钥，服务器拒绝任何不带它的请求，所以必须把 url 字段中的完整 URL 给用户——绝不能剥掉查询串或只给裸 http://host:port。key 同时守卫 HTTP 与 WebSocket 访问，防止网络中其他机器的游离标签页读取界面或注入事件。首次加载后浏览器把 key 写入 cookie（cookie 名为 brainstorm-key-<port>），之后刷新和 /files/* 静态资源无需重复携带。源码注释（server.cjs 第 115-126 行）说明了选 key 而非 Host/Origin 白名单的原因：key 在 loopback、tunnel、remote 绑定下一致地认证真实客户端，且能防御 DNS rebinding；token 用 crypto.randomBytes(32) 生成，并随端口一起持久化到 .superpowers/brainstorm/.last-token（权限 600），重启后同一 tab 的 cookie 依然有效。

找回连接信息：服务器把启动 JSON 写到 $STATE_DIR/server-info。如果后台启动时没捕获 stdout，读该文件拿 URL 和端口；使用 --project-dir 时可在 <project>/.superpowers/brainstorm/ 下找会话目录。

平台化启动方式（核心问题是"服务器必须在对话轮次之间保持后台存活"）：

环境	做法
Claude Code	默认模式即可，脚本自行把服务器放到后台
Windows（Git Bash）	脚本自动检测并切前台模式（会阻塞工具调用）；需给 Bash 工具调用加 run_in_background: true，下一轮读 $STATE_DIR/server-info 拿 URL/端口
Codex	Codex 会收割后台进程；脚本检测 CODEX_CI 环境变量自动切前台，正常运行即可
Gemini CLI	加 --foreground，并在 shell 工具调用上设 is_background: true
Copilot CLI	加 --foreground，用 bash 工具 mode: "async" 启动，保存返回的 shellId 以便后续 read_bash/stop_bash
其他环境	若环境会收割 detached 进程，用 --foreground 配合平台自己的后台执行机制

从源码看，这套跨平台适配在 start-server.sh 里落成了具体逻辑：CODEX_CI 非空时自动 FOREGROUND="true"；is_windows_like_shell() 通过 OSTYPE/MSYSTEM/uname -s 判定类 Windows 环境并同样自动前台化；后台模式下用 nohup … & disown 启动并轮询日志等待 server-started（最多 50×0.1s），且启动后还会额外验证 2 秒内进程未被"收割"，被杀则返回含 --foreground 重试建议的错误 JSON。

远程/容器化：如果 URL 从浏览器不可达，绑定非回环地址并用 --url-host 控制显示的主机名：

scripts/start-server.sh \
  --project-dir /path/to/project \
  --host 0.0.0.0 \
  --url-host localhost

持久化提醒：务必传项目根目录作为 --project-dir，mockup 会留在 .superpowers/brainstorm/ 并在服务器重启后存活；不传则文件进 /tmp 会被清理。同时提醒用户把 .superpowers/ 加入 .gitignore（若尚未加入）。

主循环（The Loop）

1. 确认服务器存活，然后写 HTML 到 screen_dir 的新文件：

   • 在引用 URL 或推送界面前必须先确认 $STATE_DIR/server-info 存在且 $STATE_DIR/server-stopped 不存在；若已停止，用同样的 --project-dir 重启——它会复用同一端口，用户已打开的标签页显示"paused"覆盖层并自动重连，无需再发新 URL。服务器空闲 4 小时自动退出（可用 --idle-timeout-minutes 调整）；
   • 用语义化文件名：platform.html、visual-style.html、layout.html；
   • 绝不复用文件名——每个界面都是新文件（迭代用 layout-v2.html 这类版本后缀）；
   • 用文件创建工具写文件，绝不用 cat/heredoc（会往终端倒噪音）；
   • 服务器自动服务最新文件（按 mtime 排序，见 server.cjs 的 getNewestScreen()）。

2. 告诉用户预期并结束本轮：每步都重提 URL（不只第一次）；给一句屏幕内容摘要（如"展示首页的 3 种布局选项"）；请用户在终端回应："Take a look and let me know what you think. Click to select an option if you'd like."

3. 下一轮（用户终端回复后）：若 $STATE_DIR/events 存在则读取——它是浏览器交互（点击、选择）的 JSON Lines；与终端文字合并才是全貌。终端消息是主要反馈，events 提供结构化交互数据。

4. 迭代或推进：反馈改变当前界面就写新文件（如 layout-v2.html）；当前步骤验证通过才进入下一个问题。

5. 回终端时卸载：下一步不需要浏览器时（澄清问题、权衡讨论），推一个等待屏清掉过期内容，防止用户盯着一个已经解决的问题：

   <!-- filename: waiting.html (or waiting-2.html, etc.) -->
   <div style="display:flex;align-items:center;justify-content:center;min-height:60vh">
     <p class="subtitle">Continuing in terminal...</p>
   </div>
   

6. 重复直至完成。

内容片段写法与可用 CSS 类

最小可用片段（无需 <html>、无需 CSS、无需 <script> 标签）：

<h2>Which layout works better?</h2>
<p class="subtitle">Consider readability and visual hierarchy</p>

<div class="options">
  <div class="option" data-choice="a" onclick="toggleSelect(this)">
    <div class="letter">A</div>
    <div class="content">
      <h3>Single Column</h3>
      <p>Clean, focused reading experience</p>
    </div>
  </div>
  <div class="option" data-choice="b" onclick="toggleSelect(this)">
    <div class="letter">B</div>
    <div class="content">
      <h3>Two Column</h3>
      <p>Sidebar navigation with main content</p>
    </div>
  </div>
</div>

frame 模板提供的 CSS 类：

• Options（A/B/C 选项）：如上示例；容器加 data-multiselect 即可多选，每次点击切换选中态；
• Cards（视觉设计卡）：<div class="cards"><div class="card" data-choice="design1" onclick="toggleSelect(this)"><div class="card-image"><!-- mockup --></div><div class="card-body"><h3>Name</h3><p>Description</p></div></div></div>；
• Mockup 容器：<div class="mockup"><div class="mockup-header">Preview: Dashboard Layout</div><div class="mockup-body">…</div></div>；
• Split view（并排）：<div class="split"> 内放两个 .mockup；
• Pros/Cons：.pros-cons 内 .pros/.cons 各带 <h4> 与列表；
• 线框积木：.mock-nav、.mock-sidebar、.mock-content、.mock-button、.mock-input、.placeholder；
• 排版：h2 页标题、h3 节标题、.subtitle 标题下副文本、.section 带底边距的内容块、.label 小字号大写标签。

CSS 与交互的完整参考见 frame-template.html 和客户端脚本 helper.js。

浏览器事件格式

用户点击选项时，交互被追加到 $STATE_DIR/events（每行一个 JSON 对象，服务器每次推送新界面时自动清空——对应 server.cjs 中 fs.appendFileSync(eventsFile, …) 的实现）：

{"type":"click","choice":"a","text":"Option A - Simple Layout","timestamp":1706000101}
{"type":"click","choice":"c","text":"Option C - Complex Grid","timestamp":1706000108}
{"type":"click","choice":"b","text":"Option B - Hybrid","timestamp":1706000115}

完整事件流展示的是用户的探索路径——用户可能在定型前点击多个选项。最后一个 choice 事件通常是最终选择，但点击模式可能暴露值得追问的犹豫或偏好。若 events 不存在，说明用户没碰浏览器——只用其终端文字。

设计技巧与文件命名

• 保真度匹配问题——布局问题画线框，精修问题才做精修稿；
• 每页解释问题本身——写"哪个布局更显专业？"而不是只写"选一个"；
• 先迭代再前进——反馈改变当前界面就写新版本；
• 每屏最多 2-4 个选项；
• 该用真实内容就用——摄影作品集就用真实图片，占位内容会掩盖设计问题；
• 保持 mockup 简单——聚焦布局与结构，不追求像素级完美；
• 文件命名：语义化、绝不复用、迭代加 -v2/-v3 后缀、服务器按修改时间服务最新文件。

收尾清理

scripts/stop-server.sh $SESSION_DIR

使用过 --project-dir 时，mockup 文件留在 .superpowers/brainstorm/ 供日后参考；只有 /tmp 会话目录会在停止时删除。从源码看，stop-server.sh 做了几件防御性工作：用 --brainstorm-server-id 实例 ID 校验 PID 确实属于本会话的服务器（无法证明就输出 stale_pid 并拒绝发信号，防止 PID 回绕误杀无关进程）；先 kill 优雅退出、等待约 2 秒后升级为 SIGKILL；并写入 server-stopped 标记文件——这正是主循环第 1 步"检查存活"所读取的信号。

服务端实现要点：零依赖与自愈重连

从源码结构看，整个视觉伴侣是一个零第三方依赖的 Node 实现（这与 2026-03-11-zero-dep-brainstorm-server-design.md 的设计意图一致）。server.cjs 自行实现了 RFC 6455 WebSocket 协议（SHA-1 accept key、帧编解码、10MB 帧上限、强制客户端掩码），并用标准库 http/fs/crypto 完成 HTTP 服务。几个值得注意的实现细节印证了前文的协议约定：

• 端口复用：preferredPort() 的优先级是显式 BRAINSTORM_PORT → .last-port 文件中该会话上次绑定的端口 → 随机高位端口（49152+）。这就是"用同一 --project-dir 重启后旧标签页自动重连"的机制；
• 空闲与属主看门狗：服务器周期性检查属主进程（harness）是否死亡以及是否空闲超时（默认 240 分钟，BRAINSTORM_IDLE_TIMEOUT_MS 可覆盖），超时即 shutdown('idle timeout') 并落盘 server-stopped；
• 无 key 拒绝页：不带 ?key= 的访问会得到 "Session key required" 提示页，引导用户复制完整 URL；
• 客户端自愈：helper.js 实现了指数退避重连（500ms 起步、翻倍、上限 30s），断连 15 秒后显示 "Companion paused" 覆盖层并提示"让 Agent 把它拉回来，页面会自动重连"；key 存于 sessionStorage，WebSocket URL 与页面跳转都自动携带。

测试侧也有对应覆盖：tests/brainstorm-server/ 下的 auth.test.js、ws-protocol.test.js、lifecycle.test.js 等分别验证会话 key 鉴权、WebSocket 帧协议与启停生命周期，可作为上述行为的可执行依据。

小结：一条"想法 → spec → plan"的确定性流水线

brainstorming 技能的价值在于把三个高频失败点变成了硬性流程约束：用 HARD-GATE 消灭"直接开写"，用"九步检查清单 + 唯一出口 writing-plans"消灭"设计到一半跑偏去实现"，用"spec 自审 + 用户审阅门禁"消灭"文档写完没人看"。Visual Companion 则以 just-in-time 的方式补充了纯文本对话难以承载的视觉决策——且其服务器端用会话 key 鉴权、端口/token 持久化与客户端自动重连，把"本地浏览器 + Agent 终端"这个组合的可靠性问题也一并解决了。仓库内 docs/superpowers/specs/ 与 docs/superpowers/plans/ 下成对的 spec/plan 文档，正是这条流水线长期运转的直接产物。