brainstorm

将头脑风暴转化为设计

与宿主无关的工作流。通过技能名称（brainstorm）调用。Claude Code 斜杠命令路由、YAML 钩子加载器和 .claude/chain 的相关内容见 references/claude-code.md。

通过智能的 Agent 选择和结构化探索，将粗略想法转化为完善的设计。

核心原则： 分析主题，动态选择相关 Agent，并行探索备选方案，逐步呈现设计。

参数解析

TOPIC = "$ARGUMENTS"  # Full argument string, e.g., "API design for payments"
# $ARGUMENTS[0] is the first token (CC 2.1.59 indexed access)

---

步骤 -1：MCP 探测 + 恢复检查

在技能启动时探测一次 MCP 服务，保存其能力，并从任何先前崩溃的会话中恢复。每个阶段都会生成一个 JSON 交接文件，供下一阶段使用。

完整流程和交接文件表：Read("references/mcp-probe-resume.md")

---

步骤 0：项目上下文发现

先加载上下文。 分叉技能不会运行 frontmatter 钩子（#4683），因此请自行运行加载器，并留意其 additionalContext：

echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/prior-decisions-loader
echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/brainstorm-instructions-loader

在创建任务或选择 Agent 之前，检测项目层级。这将成为所有后续决策的复杂度上限。

自动检测（扫描代码库）

# PARALLEL — quick signals (launch all in ONE message)
Grep(pattern="take-home|assignment|interview|hackathon", glob="README*", output_mode="content")
Grep(pattern="take-home|assignment|interview|hackathon", glob="*.md", output_mode="content")
Glob(pattern=".github/workflows/*")
Glob(pattern="**/Dockerfile")
Glob(pattern="**/terraform/**")
Glob(pattern="**/k8s/**")
Glob(pattern="CONTRIBUTING.md")

层级分类

信号	层级
README 提到“take-home”、“assignment”或时间限制	1. 面试
文件少于 10 个、没有 CI、没有 Docker	2. 黑客松
.github/workflows/、10-25 个依赖项	3. MVP
模块边界、Redis、后台任务	4. 成长阶段
K8s/Terraform、DDD 结构、单体仓库	5. 企业级
CONTRIBUTING.md、LICENSE、依赖项极少	6. 开源

如果置信度较低，请询问用户：

AskUserQuestion(questions=[{
  "question": "What kind of project is this?",
  "header": "Project tier",
  "options": [
    {"label": "Interview / take-home", "description": "8-15 files, 200-600 LOC, simple architecture"},
    {"label": "Startup / MVP", "description": "MVC monolith, managed services, ship fast"},
    {"label": "Growth / enterprise", "description": "Modular monolith or DDD, full observability"},
    {"label": "Open source library", "description": "Minimal API surface, exhaustive tests"}
  ],
  "multiSelect": false
}])

将检测到的层级作为上下文传递给所有后续 Agent 和阶段。 层级决定哪些模式适用——完整矩阵见 scope-appropriate-architecture 技能。

覆盖： 用户始终可以覆盖检测到的层级。如果用户选择的层级高于检测结果，请提醒其注意权衡。

---

步骤 0a：使用 AskUserQuestion 确认用户意图

明确头脑风暴的限制条件：

# NOTE: AskUserQuestion caps each question at 4 options (CC schema: minItems 2,
# maxItems 4). Use plain `label` + `description` only — the schema permits a
# `preview` field, but on current CC it forces a side-by-side picker layout with
# dead up/down keyboard nav (confirmed 2026-05-28), so skills no longer use it
# (`markdown` was never valid). The 6 legacy
# modes are split across 3 valid questions: Q1 = exploration flow, Q2 folds the
# old "Constrained design" mode into constraints, Q3 carries the orthogonal
# "Plan first" preamble (it composes with any Q1 mode — it was never mutually
# exclusive). "Quick ideation" + STEP 0c /effort=low overlap; both downscale.
AskUserQuestion(
  questions=[
    {
      "question": "What type of design exploration?",
      "header": "Mode",
      "options": [
        {"label": "Open exploration (Recommended)", "description": "Generate 10+ ideas, evaluate all, synthesize top 3"},
        {"label": "Comparison", "description": "Compare 2-3 specific approaches I have in mind"},
        {"label": "Quick ideation", "description": "Generate ideas fast, skip deep evaluation"},
        {"label": "Iterative optimization", "description": "Try, measure, keep/discard, repeat (autoresearch-style)"}
      ],
      "multiSelect": false
    },
    {
      "question": "Any preferences or constraints?",
      "header": "Constraints",
      "options": [
        {"label": "None", "description": "Explore all possibilities"},
        {"label": "Use existing patterns", "description": "Prefer patterns already in codebase"},
        {"label": "Minimize complexity", "description": "Favor simpler solutions"},
        {"label": "Fixed requirements (constrained)", "description": "Hard requirements to work within — skip divergent phase, focus on feasibility (old 'Constrained design' mode)"}
      ],
      "multiSelect": false
    },
    {
      "question": "Research before ideating?",
      "header": "Plan-first",
      "options": [
        {"label": "No — dive straight in (Recommended)", "description": "Go directly to ideation"},
        {"label": "Yes — plan first", "description": "Read-only research (EnterPlanMode): scan codebase, map the solution space, then ExitPlanMode for approval before Phase 1 (old 'Plan first' mode)"}
      ],
      "multiSelect": false
    }
  ]
)

如果 Q3 = 'Yes — plan first'（可与任意 Q1 模式组合）：

# 1. Enter read-only plan mode
EnterPlanMode("Brainstorm exploration: $TOPIC")

# 2. Research phase — Read/Grep/Glob ONLY, no Write/Edit
#    - Scan existing codebase for related patterns
#    - Search for prior decisions on this topic (memory graph)
#    - Identify constraints, dependencies, and trade-offs

# 3. Produce structured exploration plan:
#    - Key questions to answer
#    - Dimensions to explore
#    - Agents to spawn and their focus areas
#    - Evaluation criteria

# 4. Exit plan mode — returns plan for user approval
ExitPlanMode()

# 5. User reviews. If approved → continue to Phase 1 with plan as input.

根据回答调整工作流：

• 开放探索（Q1）：完整的 7 阶段流程，使用所有 Agent
• 方案比较（Q1）：跳过构思阶段（跳过阶段 2），直接进入评估阶段
• 快速构思（Q1）：生成想法，跳过深入评估
• 迭代优化（Q1）：跳过阶段 2-6（不进行阶段 2 的扇出），进入 autoresearch 风格循环（见下文）
• 约束设计（Q2 = "Fixed requirements"）：跳过发散阶段（跳过阶段 2），专注于在既定要求内评估可行性；可与任意 Q1 模式组合

**如果选择了“迭代优化”：**跳过阶段 2-6，进入由指标驱动的 autoresearch 风格循环。

完整子流程（指标问题、基线、循环主体）：Read("references/iterative-optimization-mode.md")

---

步骤 0b：选择编排模式（层级 1-2 时跳过）

选择 Agent Teams（网状结构，Agent 讨论并质疑想法）或 Agent 工具（星形结构，所有 Agent 向负责人汇报）：

1. Agent Teams 模式（自 CC 2.1.33 起正式可用）→ 推荐用于 3 个或更多 Agent（实时讨论能产生更好的想法）
2. Agent 工具模式 → 适用于快速构思
3. ORCHESTKIT_FORCE_TASK_TOOL=1 → Agent 工具（覆盖设置）

方面	Agent 工具	Agent Teams
想法生成	每个 Agent 独立生成	Agent 相互启发、接续构思
反方论证	所有 Agent 完成后由负责人提出质疑	Agent 实时相互质疑
成本	约 150K 个 token	约 400K 个 token
最适合	快速构思、约束设计	开放探索、深入评估

回退： 如果 Agent Teams 遇到问题，剩余阶段改用 Agent 工具。

---

步骤 0c：按投入程度调整阶段范围（CC 2.1.76；xhigh 在 2.1.111 中新增）

读取 /effort 设置并调整头脑风暴的深度——low 仅运行阶段 0/2/5，high（默认值）运行全部 7 个阶段，xhigh 会增加额外的反方论证轮次和综合轮次。步骤 0a 中用户的明确选择始终优先于缩减范围。

完整等级表和检测规则：Read("references/effort-scaling.md")

阶段 2 始终以 low 投入程度运行，不受上述等级影响：低投入最适合环内构思，不适合评分。此技能故意不设置 effort: 前置元数据（否则也会降低阶段 4 的投入）；workflows/brainstorm-diverge.js 会改为向每个生成器传入 effort: "low"。详情见同一参考文档。

**扇出规则：**当所选模式会运行阶段 2 时，单次执行绝不能作为备用方案。阶段 2 通过 Workflow 调用、Agent Teams 或 Agent 工具运行；由于此技能没有 Workflow 工具，因此会内联运行（#4696）。如果这些方式都无法启动生成器，则以 BLOCKED 结束运行并说明原因。跳过阶段 2 的模式（比较、迭代优化、约束设计）不算违反规则。

---

**完成标准。**完成意味着：根据全部七个维度对首选方案进行评分，并呈现权衡，供用户选择。遵循 Read("../../shared/rules/long-run-protocol.md")：某个步骤无需用户输入时继续执行；只有在无法继续或即将进行破坏性操作前才暂停并询问；接受任何子 Agent 的结果前都要核查其证据；对于无法确认的内容，标明查阅过的位置。

🚨 关键：任务管理为强制要求（CC 2.1.16）

# 1. Create main task IMMEDIATELY
TaskCreate(
  subject="Brainstorm: {topic}",
  description="Design exploration with parallel agent research",
  activeForm="Brainstorming {topic}"
)

# 2. Create subtasks for each phase
TaskCreate(subject="Analyze topic and select agents", activeForm="Analyzing topic")          # id=2
TaskCreate(subject="Search memory for past decisions", activeForm="Searching knowledge graph") # id=3
TaskCreate(subject="Generate divergent ideas (10+)", activeForm="Generating ideas")          # id=4
TaskCreate(subject="Feasibility fast-check", activeForm="Checking feasibility")              # id=5
TaskCreate(subject="Evaluate with devil's advocate", activeForm="Evaluating ideas")          # id=6
TaskCreate(subject="Synthesize top approaches", activeForm="Synthesizing approaches")        # id=7
TaskCreate(subject="Present design options", activeForm="Presenting options")                # id=8

# 3. Set dependencies (sequential chain: 2→3→4→5→6→7→8)
for i in range(3, 9):
    TaskUpdate(taskId=str(i), addBlockedBy=[str(i-1)])

# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress")  # When starting
TaskUpdate(taskId="2", status="completed")    # When done — repeat for each subtask

---

🔄 七阶段流程

阶段	活动	输出
0. 主题分析	对关键词分类，选择 3-5 个 Agent	Agent 列表
1. 记忆 + 上下文	搜索图谱、检查代码库、阅读实验日志	先前模式
2. 发散探索	生成 10 个以上的创意，不做筛选	创意池
3. 保留/剔除关卡	二元可行性判断：保留、剔除或否决（每个创意 10 秒）	仅保留项
4. 评估与评分	按 7 个维度评分（0-10 分，包括简洁性），并进行反方论证	排序后的创意
5. 综合	筛选出排名前 2-3 的方案，制作权衡表，为每种方案制定测试策略	选项
6. 设计展示	以 200-300 词的篇幅分段展示，记录到实验日志	已验证的设计
6.4. 动态计划 Playground（可选，应用户要求或用于多轮计划）	通过 visualize-plan 的动态计划路径生成可更新的 LPP Playground	<slug>.html（动态）
6.5. 音频播客（信号触发，可选）	当综合评分≥8.0 且方案数≥4 时，自动生成 brainstorm-podcast.m4a	.m4a 文件

阶段 6.4 — 动态计划 Playground（可选）

当用户要求输出 Playground，或综合结果产生了多轮计划（包含 2 轮以上的执行阶段和可验证事项）时，应将设计生成为动态计划 Playground，而非一次性渲染：计划阶段来自阶段 5 的综合结果，七维评分来自阶段 4，剔除的创意及其原因来自阶段 3；每个工作单元对应一项，并包含“完成条件”证据检查。通过 visualize-plan 的动态计划路径生成（示例 living-plan.template.html；其 references/format-dispatch.md §Living-plan update mode 中规定了更新模式契约）。此后，制品会跟踪自身的执行情况：后续会话在内嵌的 lpp-state JSON 中更新事项状态，并向变更日志追加记录——一个计划对应一个文件，绝不分叉。

阶段 6.5 — 合成后的音频播客（信号触发，可选）

阶段 6 完成后，可选择调用 scripts/post_synth_podcast.py <session-dir>，自动生成一段音频播客，总结主要方案及其权衡。遇到任何非理想路径都会自动跳过，因此绝不会中断头脑风暴：

python3 ${CLAUDE_SKILL_DIR}/scripts/post_synth_podcast.py "$CLAUDE_JOB_DIR"

自动跳过条件（均以 0 退出，均记录为 WARN）：

跳过原因	触发条件
signal absent	composite[recommended] < 8.0 或 len(approaches) < 4
design-doc.md not found	阶段 6 未在会话目录中写入设计文档
yg-mcp-core not importable	未安装 yg-mcp-core>=0.3.0（orchestkit 为公开项目；yg-mcp-core 位于私有源 pypi.yonyon.ai，仅限 HQ 使用）
hq-content MCP unreachable	MCP 服务已关闭，或 .mcp.json 未定义 hq-content

会话目录必须包含 brainstorm-output.json（含有 recommended、composite、approaches）和 design-doc.md。成功时，位于 <session-dir>/brainstorm-podcast.json 的交接 JSON 会记录 status（fired / skipped）和 m4a_path。

对应 Yonatan-HQ/hq-ext-plugin#194（/hq-ext:decide 的 audio_podcast 处理器）。

渐进式输出（CC 2.1.76）

每个阶段结束后都要逐步输出结果，不要等到最后才一次性输出所有内容：

阶段结束后	向用户展示
0. 主题分析	选定的 Agent、层级分类
1. 记忆 + 上下文	先前的决策、相关模式、实验日志摘要
2. 发散探索	各 Agent 返回的想法（不要等待全部返回）
3. 保留/舍弃关卡	保留的想法和舍弃原因（逐项标明保留/舍弃/崩溃）
4. 评估	评分最高的想法及其 7 个维度的得分

对于阶段 2 中并行运行的 Agent，要在每个 Agent 返回后立即输出其想法，不要等待所有 Agent 都返回。这样用户可以尽早看到想法，并在需要时调整探索方向。逐步展示想法还能帮助用户比等待最终汇总更快地建立对解决方案空间的整体认知。

加载阶段工作流以获取详细说明：

Read("references/phase-workflow.md")

---

⚠️ 不适用场景

以下情况应跳过头脑风暴：

• 需求非常明确、具体
• 只有一种显而易见的方案
• 用户已经设计好解决方案
• 时间紧迫的错误修复或紧急问题

---

快速参考：Agent 选择

主题示例	要启动的 Agent
"brainstorm API for users"	workflow-architect, backend-system-architect, security-auditor, test-generator
"brainstorm dashboard UI"	workflow-architect, frontend-ui-developer, test-generator
"brainstorm RAG pipeline"	workflow-architect, llm-integrator, data-pipeline-engineer, test-generator
"brainstorm caching strategy"	workflow-architect, backend-system-architect, frontend-performance-engineer, test-generator
"brainstorm design system"	workflow-architect, frontend-ui-developer, design-context-extractor, component-curator, test-generator
"brainstorm event sourcing"	workflow-architect, event-driven-architect, backend-system-architect, test-generator
"brainstorm pricing strategy"	workflow-architect, product-strategist, web-research-analyst, test-generator
"brainstorm deploy pipeline"	workflow-architect, infrastructure-architect, ci-cd-engineer, test-generator

始终包含：workflow-architect，用于系统设计视角；test-generator，用于可测试性评估。

---

Agent Teams 替代方案：头脑风暴团队

在 Agent Teams 模式下，组建一个头脑风暴团队，让 Agent 实时讨论想法。根据主题分析（阶段 0）动态选择团队成员：

# CC 2.1.178+: one implicit team per session — no TeamCreate.
# Spawn teammates directly via Agent(name=...). Requires
# CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (set in ork.settings.json).

# Always include the system design lead
Agent(subagent_type="ork:workflow-architect", name="system-designer",
     team_name="brainstorm-{topic-slug}",
     prompt="""You are the system design lead for brainstorming: {topic}
     DIVERGENT MODE: Generate 3-4 architectural approaches.
     When other teammates share ideas, build on them or propose alternatives.
     Challenge ideas that seem over-engineered — advocate for simplicity.
     After divergent phase, help synthesize the top approaches.""")

# Domain-specific teammates (select 2-3 based on topic keywords)
Agent(subagent_type="ork:backend-system-architect", name="backend-thinker",
     team_name="brainstorm-{topic-slug}",
     prompt="""Brainstorm backend approaches for: {topic}
     DIVERGENT MODE: Generate 3-4 backend-specific ideas.
     When system-designer shares architectural ideas, propose concrete API designs.
     Challenge ideas from other teammates with implementation reality checks.
     Play devil's advocate on complexity vs simplicity trade-offs.""")

Agent(subagent_type="ork:frontend-ui-developer", name="frontend-thinker",
     team_name="brainstorm-{topic-slug}",
     prompt="""Brainstorm frontend approaches for: {topic}
     DIVERGENT MODE: Generate 3-4 UI/UX ideas.
     When backend-thinker proposes APIs, suggest frontend patterns that match.
     Challenge backend proposals that create poor user experiences.
     Advocate for progressive disclosure and accessibility.""")

# Always include: testability assessor
Agent(subagent_type="ork:test-generator", name="testability-assessor",
     team_name="brainstorm-{topic-slug}",
     prompt="""Assess testability for each brainstormed approach: {topic}
     For every idea shared by teammates, evaluate:
     - Can core logic be unit tested without external services?
     - What's the mock/stub surface area?
     - Can it be integration-tested with docker-compose/testcontainers?
     Score testability 0-10 per the evaluation rubric.
     Challenge designs that score below 5 on testability.
     Propose test strategies for the top approaches in synthesis phase.""")

# Optional: Add security-auditor, llm-integrator based on topic

**主要优势：**Agent 可以实时接续彼此的想法并扮演反方，而不是各自独立地产生想法。 Fork 模式（CC 2.1.89 #1227；CC 2.1.232 起明确支持）： 所有头脑风暴 Agent 都符合 fork 条件：提示词少于 500 个单词、不指定自定义模型、不使用工作树。CC 会在 fork 之间共享父级缓存的 API 前缀，从而降低约 60% 的成本。不要在 Agent 调用中添加 model=。从 CC 2.1.232 起，fork 默认启用，subagent_type: "fork" 可显式选择该模式，因此这些条件仅对普通的 Agent() 调用适用。参见 chain-patterns/references/fork-pattern.md。

嵌套委派（CC 2.1.172+）： 可以指示队友将范围明确的子问题委派给已声明的子 Agent（例如，让 backend-thinker 委派给 database-engineer，对某个架构思路进行合理性检查），而不是直接猜测。链路深度保持在 ≤ 3 层；发散式构思本身仍保持扁平——上方并行的队友就是针对独立想法进行的扇出。参见 chain-patterns 模式 9（CC 2.1.172+）。

综合后拆除团队：

# After Phase 5 synthesis and design presentation
# CC 2.1.178+: no TeamDelete — teammates wind down at turn end
# (press Ctrl+F twice to stop lingering background teammates).

# Worktree cleanup (CC 2.1.72) — for Tier 3+ projects that entered a worktree
# If EnterWorktree was called during brainstorm (e.g., Plan first → worktree), exit it
ExitWorktree(action="keep")  # Keep branch for follow-up implement

备用方案： 如果无法组建团队，请加载 Read("references/phase-workflow.md")，并使用标准的 Phase 2 Task 启动方式。

部分结果（CC 2.1.76，CC 2.1.246 扩展）： 被终止的后台 Agent（超时、上下文限制）会返回带有 [PARTIAL RESULT] 标记的响应。从 CC 2.1.246 起，达到 maxTurns 限制后停止的 Agent 也会被报告为部分结果：其摘要会显示“在 N 轮限制处停止（部分结果；使用 SendMessage 向 task-id 发送消息以继续）”，输出也会标记为部分结果，而不是显示为已完成。收集 Phase 2 的发散想法时，请检查每个 Agent 的输出是否符合上述任一情况。如果符合，请纳入部分想法，但在 Phase 3 可行性评估中注明内容不完整。对于轮数限制的情况，向该 Agent 的 id 发送“从停止的地方继续”这条 SendMessage 消息可复用其上下文；重新启动则会从头开始，并再次消耗提示词成本。切勿将达到轮数限制的 Agent 视为已完成。

跨会话回复会发送给父级（CC 2.1.248）： 子 Agent 向另一个会话发送 SendMessage 时，回复会发送到父级会话的对话中，而不会发送给子 Agent；子 Agent 发送消息后会继续执行，父级则读取答案。跨会话 SendMessage / ListAgents 也适用于 Bedrock、Vertex 和 Foundry，以及禁用遥测的情况（CC 2.1.248）。

PostCompact 恢复： 长时间的头脑风暴会话可能触发上下文压缩。PostCompact hook 会重新注入分支和任务状态。如果头脑风暴过程中发生压缩，请检查 .claude/chain/state.json 中最后完成的阶段，并从下一个交接文件恢复（参见 Phase Handoffs 表）。响应式压缩（CC 2.1.142+）现在会根据实际溢出量确定首次摘要的长度，因此很少会在轮次中途停滞——无需预期还会进行第二次压缩。

上下文满时（CC 2.1.141+）： 不要结束会话，而是使用回退菜单中的“总结到此处”，压缩较早的轮次，同时保留近期上下文——这是一个有意设置的压缩节点，可与上文改进后的响应式压缩配合使用。

会话回顾（CC 2.1.108+）： 闲置一段时间后，使用 /recap 恢复对话上下文，同时继续利用检查点恢复功能。从 CC 2.1.110 起默认启用（即使禁用遥测也会启用）。

推送通知（CC 2.1.110+）： 对于长时间的头脑风暴会话，可使用 PushNotification 在综合完成时发送提醒（需要启用 Remote Control，并选择“Push when Claude decides”）。

更轻量的替代方案（CC 2.1.141+）： Hook 可通过 hook JSON 输出中的 terminalSequence 字段，原生发出桌面通知、窗口标题和提示音——无需 Remote Control，也无需与 Anthropic 往返通信。Ork 的通知 hook（notification/desktop、notification/sound）已通过 terminalSequence 发出通知（#1847，已发布）。

手动清理： 如需停止仍在运行的后台队友，请按两次 Ctrl+F（前台显示/停止）。注意：/clear（CC 2.1.72+）会保留后台 Agent——它只会清除前台任务。 队友的后台任务可在回合结束后继续运行（CC 2.1.183）： 由队友启动的后台任务，在该队友结束回合时不再会被终止。第 2 阶段的队友可以放心启动耗时较长的 run_in_background 任务（例如可行性构建），让任务在自己的回合结束后继续运行——综合阶段仍可收集结果。在 2.1.183 之前，必须由主 Agent 持有后台任务。

此说法不适用于自动转入后台的工作（#3448）： 被执行环境在超时后转入后台的前台 Bash 调用，属于另一条路径。完成通知会发送给启动该调用的 Agent；如果该 Agent 已经以“我会等待”结束回合，通知就会无处可送，输出也会丢失，且不会记录任何错误。因此有两条规则。任何文档所述运行时间可能接近 Bash 超时时限的研究调用（tavily-research 标注为 30-120s，实际查询会超过 180s），都由主 Agent 持有。任何队友结束回合时，都不能只说“我会等待 X”，除非它已收集 X 的结果，或已将 X 的所有权移交给主 Agent。

---

核心原则

原则	应用方式
动态选择 Agent	根据主题关键词选择 Agent
并行研究	在一条消息中启动 3-5 个 Agent
记忆优先	研究前先检查图谱中是否记录了过往决策
先发散	筛选前先生成 10 个以上的创意
任务跟踪	使用 TaskCreate/TaskUpdate 展示进度
严格遵循 YAGNI	移除不必要的复杂性

---

使用 /goal 无人值守运行

使用 /goal 设置完成条件（CC 2.1.139+，此技能推荐使用 2.1.143+），此技能便会跨回合持续运行，直到满足条件。适用于交互模式、-p 和 Remote Control。覆盖面板会实时显示已用时间、回合数和 token 数。

为何需要 2.1.143+： 在 2.1.143 之前，/goal 评估器可能会在后台 shell 或委派的子 Agent 仍在运行时触发——这会与此技能在第 2 阶段启动的并行 Agent 发生竞态。此问题已在 CC 2.1.143 中修复（更新日志：“/goal 评估器在后台 shell 或委派的子 Agent 仍在运行时触发”）。

此技能的完成条件示例：

/goal until design.options_count >= 2 AND user_chose_option, or stop after 8 turns

在满足以下条件时停止：提出 2 个以上已排名的设计选项，且用户选定其中一个（若通过 -p 无人值守运行，则在第 6 阶段后停止）。兼容 claude.ai Remote Control 运行。

---

质量标准

满足以下所有条件即为完成：

• 第 2 阶段在任何筛选前提出 >=10 个不同的创意，并在各 Agent 返回结果时逐一呈现
• 每个通过保留/舍弃关卡的创意，都附有一行保留/舍弃/崩溃判定
• 每个保留下来的创意，都在全部 7 个维度上获得 0-10 分（包括简洁性），并附带一项唱反调的质疑
• 综合分析将方案收敛至 2-3 种，并提供权衡表和每种方案的测试策略
• 输出以供用户选择的排名选项结尾（若通过 -p 无人值守运行，则在第 6 阶段完成）

📜 相关技能

• ork:architecture-decision-record - 记录头脑风暴中做出的关键决策
• ork:implement - 头脑风暴完成后执行实施计划
• ork:explore - 深入探索代码库，了解现有模式
• ork:assess - 按维度细分进行 0-10 分质量评估
• ork:design-to-code - 将头脑风暴生成的 UI 设计转化为组件
• ork:component-search - 构建新组件前查找现有组件
• ork:competitive-analysis - 为产品头脑风暴运用波特五力分析和 SWOT 分析

Picker 回退 (#1795)

orchestkit#1795 中报告的 Picker 卡顿是架构断裂，而非 CC 输入错误：包含超过 4 个选项或带有 markdown 字段（markdown 键无效；架构字段是 preview）的问题无法通过 AskUserQuestion 验证，因此 Picker 不会显示。所有技能中的问题都符合架构要求（2–4 个选项，multiSelect 时不设置 preview），并由 tests/skills/structure/test-askuserquestion-schema.sh 强制执行。另一方面，虽然架构允许使用 preview 字段，但当前 CC 会将任何使用该字段的问题渲染为并排 Picker 布局，导致 ↑/↓ 键盘导航失效（已于 2026-05-28 确认）。因此，技能现在统一仅使用普通的 label + description，不再设置 preview。如果未来的 CC 版本中仍遇到卡顿，ORK_ASK_FALLBACK=text 仍可作为防御性选择启用：此时 lifecycle/ask-fallback-injector 钩子会提示助手以编号列表的形式直接列出选项。钩子全局生效，无需逐个修改技能。

参考资料

按需使用 Read("references/<file>") 加载：

文件	内容
phase-workflow.md	详细的 7 阶段说明
divergent-techniques.md	SCAMPER、思维导图等
evaluation-rubric.md	0–10 分评分标准
devils-advocate-prompts.md	挑战模板
socratic-questions.md	需求探索
common-pitfalls.md	需要避免的错误
example-session-dashboard.md	完整示例
mcp-probe-resume.md	STEP -1 探测 + 恢复 + 交接文件表
iterative-optimization-mode.md	Autoresearch 风格的指标循环子流程
effort-scaling.md	/effort 级别和阶段缩放规则