// 当用户想要 brainstorm 一个想法、设计 feature 或 spec 时使用。通过对话探索意图与需求，然后将 spec 文档写入 .brainstorm/ 并 STOP。不会自动接 implementation planning 或任何其他技能。
Create single-file, self-contained HTML artifacts for complex, visual, comparison-heavy, reviewable, or shareable work outputs. Use this skill when the user asks for an HTML artifact, browser-viewable report, implementation plan, PR/code review report, architecture explainer, design comparison, research briefing, incident report, status dashboard, temporary structured-data editor, mini deck, or design-system specimen. Prefer this skill for long Markdown-like outputs that benefit from navigation, cards, diagrams, filters, copy/export buttons, or annotated diffs. Do not use it for short answers, simple commands, commit messages, tiny patch summaries, or production UI implementation unless the user explicitly asks for a review artifact.
Modify the Beautiful Mermaid live editor itself rather than writing ordinary Mermaid diagrams. Use when the task mentions the Beautiful Mermaid repo, `editor.ts`, generated `editor.html`, config panel/options, themes or dark mode, zoom, PNG/SVG export, clipboard behavior, sample presets, or renderer wiring for the editor. Do not use for generic Mermaid syntax help or normal Markdown Mermaid authoring.
Audit and improve Claude Code CLAUDE.md guidance files, .claude/rules/ path-scoped rules, and companion code_map.md navigation maps. Use when the user asks to check, audit, update, optimize, or fix CLAUDE.md files; mentions nested CLAUDE.md, additive loading, ancestor/descendant loading, path-scoped rules, @import chains, CLAUDE.local.md, claudeMdExcludes, or code_map.md; or says "优化 CLAUDE.md", "审计 CLAUDE.md", "检查嵌套 CLAUDE.md", "Claude Code 项目指导", "生成 code_map (Claude)". Make sure to use this skill whenever the user wants to manage Claude Code memory files at any layer, even if they only mention CLAUDE.md without explicit audit wording.
Audit and improve Codex AGENTS.md guidance files and companion code_map.md navigation maps in repositories. Use when the user asks to check, audit, update, optimize, or fix AGENTS.md files; asks for Codex project guidance maintenance; mentions nested AGENTS.md conflicts, code maps, stale commands, scoped instructions, sandbox or approval boundaries; or says "优化 AGENTS.md", "审计 AGENTS.md", "检查 nested AGENTS.md", "更新 Codex 项目指导", or "生成 code_map.md".
Review a codebase for architectural friction, rank deep-module refactoring opportunities, and draft RFCs for safer interfaces and boundary-test strategies. Use when the user wants to improve architecture, identify refactoring seams, consolidate tightly coupled modules, deepen shallow modules, redesign an interface around a core concept, replace brittle unit tests with boundary tests, or turn an architecture review into an RFC or issue draft. Chinese trigger phrases also apply: 架构改进, 抽象太浅, 模块拆得太碎, 接口太多, 测试钉死实现细节, 想写架构 RFC, 这块代码改一改, 模块边界乱.
Archive root-level planning files (`task_plan.md`, `findings.md`, and `progress.md`) into a timestamped `.plannings/` directory for the current feature. Use when Codex should run `$archive-planning [feature-name]`, close out an active plan, preserve completed planning context, or replace the deprecated Codex prompt workflow with a deterministic skill script.
| name | brainstorming-baha |
| version | 0.1.0 |
| category | development-workflows |
| tags | ["brainstorming","design","spec","discovery"] |
| description | 当用户想要 brainstorm 一个想法、设计 feature 或 spec 时使用。通过对话探索意图与需求，然后将 spec 文档写入 .brainstorm/ 并 STOP。不会自动接 implementation planning 或任何其他技能。 |
通过自然的协作对话，帮助将想法转化为完整的设计与 spec 文档。
首先了解当前项目的上下文，然后逐一提问来完善想法。一旦理解了要构建的内容，就展示设计方案并获得用户批准，再把验证过的 spec 落盘。
在展示设计方案并获得用户批准之前，不要调用任何实现类技能，不要写代码，不要搭建任何项目，不要采取任何实现行动。这适用于所有项目，无论看起来多简单。每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（真正简单的项目几句话就够了），但必须展示出来并获得批准。
为以下每一项创建一个任务，并按顺序完成：
.brainstorm/YYYY-MM-DD-<topic>-design.md 并提交 gitdigraph brainstorming {
"探索项目上下文" [shape=box];
"有视觉相关问题?" [shape=diamond];
"提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box];
"提出澄清问题" [shape=box];
"提出 2-3 种方案" [shape=box];
"分节展示设计" [shape=box];
"用户批准设计?" [shape=diamond];
"写 spec 文档" [shape=box];
"Spec 自检\n（就地修复）" [shape=box];
"用户复核 spec?" [shape=diamond];
"交付 spec 路径并 STOP" [shape=doublecircle];
"探索项目上下文" -> "有视觉相关问题?";
"有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"];
"有视觉相关问题?" -> "提出澄清问题" [label="否"];
"提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题";
"提出澄清问题" -> "提出 2-3 种方案";
"提出 2-3 种方案" -> "分节展示设计";
"分节展示设计" -> "用户批准设计?";
"用户批准设计?" -> "分节展示设计" [label="否，修改"];
"用户批准设计?" -> "写 spec 文档" [label="是"];
"写 spec 文档" -> "Spec 自检\n（就地修复）";
"Spec 自检\n（就地修复）" -> "用户复核 spec?";
"用户复核 spec?" -> "写 spec 文档" [label="需要修改"];
"用户复核 spec?" -> "交付 spec 路径并 STOP" [label="通过"];
}
终态是把 spec 路径交付给用户并 STOP。 不要调用其他技能，不要开始实现规划，不要写代码。报告 spec 路径并结束你的回合——后续怎么用 spec，由用户自己决定。
理解想法：
探索方案：
展示设计：
面向隔离和清晰的设计：
在现有代码库中工作：
写文档：
.brainstorm/YYYY-MM-DD-<topic>-design.md
Spec 自检： 写完 spec 后，用新鲜的眼光再看一遍：
发现问题就地修复。修完即可，不需要再次复核。
用户复核闸门： spec 自检通过后，请用户在继续之前审阅 spec 文件：
"Spec 已经写入并提交到
<path>。请你审阅一下，看是否需要修改，然后我们再考虑下一步。"
等待用户回复。如果他们要求修改，改完后再走一次 spec 自检。只有用户批准后才进入下一步。
完成——在此 STOP：
一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。
提供伴侣： 当预计后续问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：
"我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"
此提议必须是一条独立的消息。 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。
逐问题决策： 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：用户看到它是否比读到它更容易理解？
关于 UI 主题的问题不一定是视觉问题。"在这个上下文中个性化是什么意思？"是一个概念问题——使用终端。"哪种向导布局更好？"是一个视觉问题——使用浏览器。
如果用户同意使用伴侣，在继续之前阅读详细指南：
visual-companion.md