Stats
Actions
Tags
From composir
Drive an interactive brainstorming session for popular science writing. Use when starting a new article or series, discussing topic, angle, target audience, whether to make a series, series structure, article count, and logical flow. Produces a brainstorm.md document summarizing all decisions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/composir:brainstormThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
所有对外部 URL 的抓取走下面三层，**不要直接调 WebFetch**。
所有对外部 URL 的抓取走下面三层，不要直接调 WebFetch。
占位符约定：下面代码里
<URL>、<your prompt>、<在这里...>等尖括号项是你要替换的占位符，不是字面字符串。执行前换成实际值。
P=$(${CLAUDE_PLUGIN_ROOT}/bin/composir-fetch "<URL>") && echo "$P"
exit 0 → Read "$P"，用 Grep 定位需要的事实/引文，结束。
W=$(${CLAUDE_PLUGIN_ROOT}/bin/composir-fetch --wf-path "<URL>")
[ -s "$W" ] && cat "$W"
扫一遍已有的 ## Q: ... 条目。若某条 Q 的答案能覆盖当前问题，引用，结束。
判断原则：语义覆盖，不是字符匹配——"发布年份"能答"发布时间"；但"具体哪一天"不一定被"哪一年"覆盖。
分两步：
3a. 调 WebFetch（响应进入你当前对话上下文，不是 shell 变量）：
WebFetch "<URL>" "<your prompt>"
3b. 把响应文本追加到 wf-cache（$W 是上一步 §2 已拿到的路径；若尚未求值，先 W=$(${CLAUDE_PLUGIN_ROOT}/bin/composir-fetch --wf-path "<URL>")）：
# 首次写入先加 header（幂等）
[ ! -f "$W" ] && printf '# WebFetch cache for %s\n' "<URL>" > "$W"
# 追加 Q/A 条目；heredoc 用未引号的 WFEOF 以便 $TS 展开
TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)
cat >> "$W" <<WFEOF
## Q: <your prompt> ($TS)
<在这里直接粘贴 WebFetch 返回的完整响应文本>
---
WFEOF
下次同 URL 的 agent 在 §2 就能命中这条记录。
驱动一轮结构化的写作头脑风暴，和用户讨论清楚：写什么、怎么写、是单篇还是系列、系列的结构。最终产出 brainstorm.md 文档。
用户输入的 topic hint 作为起点：$ARGUMENTS
一开始就问用户文章系列要放到哪个目录。brainstorm 和后续 plan、review 报告都会写到该目录下的 .composir/ 子文件夹里——文章本身仍放在系列根目录。这一步不能省略。
用 AskUserQuestion 询问，给几个合理的候选：
cwd/.composir/cwd/<topic>/.composir/<slug>-brainstorm.md 命名，避免和该目录已有的其他 brainstorm 冲突如果用户一开始就在 prompt 里说了路径，跳过这一步。
提醒规则：如果用户在整个 brainstorm 过程中没提保存位置、也没回答这个问题，主动提醒用户："我们需要决定文章放到哪里，否则 brainstorm、plan、文章也不知道放哪。"
.composir/ 文件夹的用途：存放写作过程的元信息（<slug>-brainstorm.md、<slug>-plan.md、<article>-review-*-iterN.md 等）。文章本身写在系列根目录（.composir/ 的上一级），避免把元信息和正文混在一起。
命名前缀：.composir/ 下所有文件都带前缀——brainstorm/plan 用 slug 前缀（系列 slug 或单篇 slug），review 报告用文章 slug 前缀。这样同一个 .composir/ 可以容纳多个单篇文章的独立元信息，不会冲突。
用 AskUserQuestion 逐步澄清：
不要一次问 4 个问题，分 2-3 轮逐步深入。每轮根据用户回答调整下一轮问题。
如果用户的主题是分析某个开源项目 / 代码库 / 工具的实现（例："写一篇关于 X 项目架构的文章"、"分析 Y 库是怎么实现的"），而用户只给了 GitHub URL、没有提供本地路径：
必须先要求用户把仓库 clone 到本地，不要用 WebFetch 去抓 GitHub 页面。原因：
（这是 §抓网页协议 的 "例外" 条款：local repo-first 优先级更高。其他 URL 仍走三层缓存。）
具体怎么做：
用 AskUserQuestion 问用户类似这样的问题：
这个主题需要深度分析代码。建议你把仓库 clone 到本地，这样我能用更高效的工具读代码，你也可以在编辑器里一起看。你方便 clone 吗？
- 选 A：我现在 clone，稍后告诉你本地路径
- 选 B：我已经 clone 了，路径是 [填写]
- 选 C：暂时不 clone，先用 URL 讨论个大概
选 A 或 B 的话，等用户提供本地路径后再继续 brainstorm。把本地路径记录到 brainstorm.md 的"代码库位置"字段，后面 plan 和写作阶段都能用。
同时记录 commit/tag：问用户"你想基于哪个 commit 或 tag 讨论？"，给几个合理候选：
main（或仓库默认分支）的 HEAD —— 用 git -C <path> rev-parse HEAD 拿 hashv2.1.7）—— 用 git -C <path> tag --sort=-v:refname | head -1 看候选这个 commit/tag 会记录到 brainstorm.md 的"代码库位置"字段，供 fact-checker 和 academic-reviewer 核查时定位到同一个版本（仓库更新了也还能核对 —— 核查员会注意到当前 checkout 和记录不一致）。
选 C 的话，提醒用户："那我先用 URL 讨论方向，但等到真正深入分析代码时，还是需要本地路径和 commit/tag —— 到时候再提醒你。"
用户可能有多个公众号合集/栏目（例："AI之旅"、"AI群星闪耀时"、"随笔之旅"）。用 AskUserQuestion 问用户：
为什么要在 brainstorm 阶段确定：合集归属影响文章第一句的模板（例："本文是'[合集名]'合集 [系列名] 系列的第N篇"），也会写进 plan.md 供写作阶段使用。
基于前面讨论的复杂度判断。如果主题能 2000-3000 字讲清楚 → 单篇。如果需要拆成多个递进的视角 → 系列。
用 AskUserQuestion 让用户拍板：
如果是系列，进一步确定：
每篇之间的过渡要想清楚——第 N 篇结尾怎么自然引出第 N+1 篇。
让用户和你一起列出：
这一步为后面的 plan 和事实核查打基础。
目的：核查阶段的 fact-checker 和 academic-reviewer 需要一份"一手权威源"列表，才能判断哪些证据够硬、哪些只能作 advisory。科普文选题太多样，没有通用白名单——必须 per-topic 和用户确认一遍。
用 AskUserQuestion 给用户推荐一份初稿，根据主题归类：
claude.com/en/*、github.com/anthropics/*）让用户增删，不让用户从零列。初稿要具体（给具体域名或 URL），不要写"官方文档"这种模糊的说法。
最终清单会写入 brainstorm.md 的"权威源"节，并由 /composir:plan 继承到 plan.md，供核查 agent 读取。
在保存前，先确定用于文件命名的 slug（后续 plan.md 和 review 报告也会用它）。
ai-journey-android-skills）git-worktree）规则：
.composir/ 下不能和已有 slug 冲突）用 AskUserQuestion 给出你推荐的 slug，让用户确认或修改。
把讨论的所有内容整理成一个结构化 Markdown 文档，保存到 <系列目录>/.composir/<slug>-brainstorm.md——其中 <slug> 是第 8 步确定的值。如果 .composir/ 不存在，用 Write 工具会自动创建（无需 mkdir）。使用你读到这份文档时的时间做日期记录（比如用 Bash date 命令，或者从环境信息里推断）。
brainstorm.md 写好后不要以一句"随时运行 /composir:plan"结束对话——那会让用户必须手工敲命令。
用 AskUserQuestion 主动问：
<绝对路径>。现在基于这份 brainstorm 生成 plan.md 吗？"Skill 工具调用 composir:plan，args 传 brainstorm.md 的绝对路径/composir:plan。"规则：
args 传过去，让 plan skill 不用再 glob 找# 头脑风暴：[主题/系列名]
**日期**：YYYY-MM-DD
**状态**：brainstorm 完成，待生成 plan
## 合集归属
- **合集（中文）**：[合集名，例："AI之旅" / "AI群星闪耀时" / "随笔之旅" / 无]
- **合集（英文）**：[英文译名，例："AI Journey"；如果用户不打算写英文可留空]
## 核心主题
[主题一句话概括]
## 代码库位置（如果主题涉及代码分析）
- **GitHub URL**：[原始 URL]
- **本地路径**：[用户 clone 后的路径，例 /Users/xxx/workspaces/yyy]
- **基于 commit/tag**：[例 `v2.1.7` 或 `a1b2c3d4...`] —— 写作时讨论的是哪个版本
- **状态**：已 clone / 未 clone（仅 URL 讨论）
如果主题不涉及代码分析，删除这一节。
## 目标读者
[描述目标读者群体]
## 想解决的问题
[读者看完应该获得什么]
## 切入角度
[从哪个角度开始讲]
## 形式：[单篇 / 系列]
### 如果是系列
- **系列名**：...
- **篇数**：N
- **逻辑线**：...
- **文章列表**：
1. 第 1 篇：[标题初稿] — [一句话概括]
2. 第 2 篇：[标题初稿] — [一句话概括]
...
## 关键概念
- [概念 1]：[初步理解]
- [概念 2]：[初步理解]
...
## 需要核查的事实
- [事实 1]
- [事实 2]
...
## 候选类比
- [主题 X] 像 [生活中的 Y]，因为 [共通点]
- ……
## 权威源
**fact-checker 和 academic-reviewer 在核查阶段认的一手源**。只有这些源里的证据可以升为 Critical；其他来源（个人博客、SNS、二手转述）最多支持 Warning。
- [具体源 1：例 `claude.com/en/*`]
- [具体源 2：例 `github.com/anthropics/claude-code`]
- [具体源 3：例 某篇 arxiv 论文的 URL]
- ...
**本地代码库**（如适用，和"代码库位置"节配合）：
- 路径：[本地 clone 路径]
- 基于 commit/tag：[如适用]
## 待决定的问题
- [ ] [还没讨论清楚的问题]
...
## 下一步
运行 `/composir:plan` 把这份 brainstorm 转成结构化的 `<slug>-plan.md`。
关于 slug：在 brainstorm.md 正文里可以不写 slug（它已经体现在文件名里了）。template 里不加专门的字段。
<系列目录>/.composir/<slug>-brainstorm.mdnpx claudepluginhub agenticfish/marketplace --plugin composirProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.