Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计提醒

brainstorming-pm头脑风暴下午

Agent Skill

brainstorming-pm 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

267

周安装

11

GitHub Stars

5

下载量

87
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:brainstorming-pm(头脑风暴下午)
来源仓库:https://github.com/dangeles/claude
仓库路径:skills/brainstorming-pm
安装命令:
npx skills add https://github.com/dangeles/claude --skill brainstorming-pm
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/dangeles/claude --skill brainstorming-pm

简介

brainstorming-pm 是一个基于多智能体协作的头脑风暴框架,通过四阶段流程和五个并行代理生成带置信度权重的多角度分析。

  • 适用于复杂问题探索、创新方案生成和多视角论证,支持在 Codex、Claude、Cursor、Gemini CLI 中开展结构化创意研讨。
  • 调用时需明确议题范围,系统将自动分配探索者与挑战者角色,输出包含可行性评估与风险提示的完整提案文档。
  • 安装前请确认项目具备 GitHub 仓库权限及网络访问能力,注意该技能可能触发外部 API 调用与数据持久化操作。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

brainstorming-pm

Tier 1 orchestrator skill that executes the perspective-swarm protocol: a 4-stage pipeline producing confidence-weighted multi-perspective analysis through 5 parallel agents. This skill owns session management, tool selection, agent delegation, model selection, and user interaction for the entire brainstorming workflow.

Protocol specification: See ../perspective-swarm/SKILL.md for the complete protocol definition (stages, archetypes, state machine, quality gates, operational parameters).

Architecture navigation: This skill (brainstorming-pm) is the executable entry point. The protocol spec (perspective-swarm) defines *what* happens. This skill defines *how* it happens. Reference documents under ../perspective-swarm/references/ provide detailed algorithms and schemas shared between the two.

When to Use

  • A user needs diverse viewpoints on a decision, problem, or creative challenge
  • Time is limited (15-30 minutes) but rigorous multi-angle analysis is needed
  • The goal is to identify both consensus themes and unique insights
  • The problem benefits from optimistic, critical, analytical, innovative, and pragmatic lenses

When NOT to Use

  • Deep literature review is needed (use lit-pm instead)
  • Single-perspective analysis is sufficient
  • Implementation or execution is the goal (this produces analysis only)
  • Domain-specific expertise is required (this uses general archetypes)
  • The user has already received a multi-perspective analysis and wants to refine a single angle

Delegation Mandate

You are an orchestrator. You coordinate perspective agents -- you do not generate perspectives yourself.

What the orchestrator DOES:

  • Session setup (directory creation, lock files, state initialization)
  • Problem framing (Stage 1, performed inline)
  • Tool invocation (launching Task agents for Stage 2)
  • Quality gate evaluation (checking outputs against required criteria)
  • Convergence synthesis (Stage 3, performed inline -- this is the exception)
  • User communication (presenting options, collecting feedback)
  • State management (reading/writing workflow-state.yaml)
  • Workflow discovery and handoff coordination (Stage 3-4)

What the orchestrator DOES NOT DO:

  • Generate perspective content (delegate to Task agents)
  • Conduct web research for perspectives (agents do their own research)
  • Adopt persona lenses (Optimist, Critic, etc.)
  • Make decisions on behalf of the user

Exception: Stage 3 convergence analysis (including LLM-based grouping) is performed inline by the orchestrator because it requires cross-perspective analysis that cannot be delegated to a single perspective agent. This is analysis *of* perspectives, not a perspective itself.

Self-check: Before executing any substantive content generation, ask: "Am I about to adopt a perspective myself?" If yes, delegate via Task tool instead.

Tool Selection

SituationToolRationale
Stage 2: Launch perspective agentsTask tool (5 concurrent)Parallel execution required; each agent is independent
Stage 3: Convergence analysisInline (no tool)Cross-perspective synthesis cannot be delegated to one agent
Stage 3: LLM groupingInline (no tool)Simple structured output call; no delegation needed
Stage 3: Workflow discoveryInline (file-system scan)No LLM involved; fast directory scan
Stage 4: Handoff invocationSkill toolTarget skill invocation with payload

Self-check prompt: "Am I about to use Task tool for something I should do inline (convergence, state management), or about to do inline something I should delegate (perspective generation)?"

Model Selection

Model selection is currently advisory. All components inherit the orchestrator's model because the Task tool does not yet support explicit model selection.

ComponentCurrentTarget
OrchestratorInheritedClaude Opus 4.6
Perspective AgentsInheritedClaude Sonnet 4.6
LLM GroupingInherited (inline)Claude Haiku 4.5

For full rationale and fallback chains, see references/model-selection.md.

Note: When the Task tool gains a model parameter, update Stage 2 Task invocations to specify claude-sonnet-4-6 and Stage 3 grouping calls to specify claude-haiku-4-5.

State Anchoring

Start every response with: [Stage N/4 - {stage_name}] {brief status}

Before starting any stage:

  1. Read workflow-state.yaml from the session directory
  2. Confirm current_state matches the expected state for the stage about to begin
  3. If mismatch: diagnose (stale state? crashed mid-stage?) and offer user resume/restart options

After any user interaction: re-anchor to the current stage by re-reading workflow-state.yaml and re-stating the stage header.

Archival Compliance

On invocation, check for handoff context:

  1. If invoked via --handoff {payload_path}: read the handoff payload and extract context.original_prompt, context.problem_type, and any optional fields into Stage 1 inputs
  2. Check for .archive-metadata.yaml in the working directory for archival context
  3. Follow the same archival patterns as technical-pm (fallback to .archive-metadata.yaml if no handoff payload)

Invocation

# Direct invocation with a question
brainstorming-pm "Should we pivot our product to focus on the European market?"

# Invocation via handoff from another skill
brainstorming-pm --handoff {payload_path}

# Resume a previous session
brainstorming-pm --resume {workflow_id}

Stage-by-Stage Orchestration

Stage 1: Framing (2-5 minutes)

Preconditions: User has provided a prompt (or handoff payload received).

Actions (performed inline by orchestrator):

  1. Validate user prompt: minimum 10 characters, maximum 1000 characters, at least one clear question or challenge, no prohibited content
  2. Identify problem type: decision | creative | analytical | strategic
  3. Reframe challenge in neutral language (no leading or biasing)
  4. Generate 5 archetype-specific prompts using ../perspective-swarm/references/persona-archetypes.md templates
  5. Create session directory: /tmp/swarm-session-{YYYYMMDD}-{HHMMSS}-{uuid4-8char}/
  6. Create session lock: write .session.lock with workflow_id and ISO8601 timestamp
  7. Initialize workflow-state.yaml with current_state: FRAMING
  8. Save framing output: stage-1-framing.yaml

Quality Gate:

  • Problem clearly articulated
  • All 5 agent prompts generated
  • No leading/biasing language in reframed challenge

Optional Checkpoint: Present reframed challenge to user before proceeding.

  • On approve: continue to Stage 2
  • On refine: re-enter framing with user feedback
  • On abort: update state to ABORTED, release session lock, inform user

State Update: current_state: FRAMING -> DIVERGING (on gate pass)

Stage 2: Parallel Perspective Generation (5-15 minutes)

Preconditions: Stage 1 complete. 5 archetype prompts generated. Session directory exists.

Actions:

  1. Launch 5 Task tool invocations concurrently. Each Task receives:

- Archetype persona instructions (from ../perspective-swarm/references/persona-archetypes.md) - Reframed challenge text - Session directory path and output location (perspectives/{archetype}.md) - Research guidance: "Conduct 1-2 WebSearch queries to support your analysis" - Output format requirements: key insight (1-2 sentences), supporting evidence (2-3 bullets with sources), confidence level (1-5, self-assessed), blind spots acknowledged - Token target: ~2000 tokens (advisory)

  1. Maintain status board and display to user: [Stage 2/4 - DIVERGING] Parallel perspectives in progress | Agent | Status | Elapsed | |------------|-------------|---------| | Optimist | complete | 6:30 | | Critic | in_progress | 8:15 | | Analyst | complete | 7:45 | | Innovator | timeout | 10:00 | | Pragmatist | complete | 8:00 |
  2. Apply timeouts: 10 minutes per agent, 15 minutes stage total (wall-clock ceiling shared by all concurrent agents)

Quality Gate (per agent):

  • Key insight present (required)
  • At least 1 evidence point (required)
  • Confidence level 1-5 (required; clamp if out of range)
  • Blind spots acknowledged (required)

Minimum agents required: 4 of 5

On < 4 agents completing: Present user options:

PERSPECTIVE GENERATION INCOMPLETE: Only {N} of 5 agents completed

Completed: {list}
Failed: {list with reasons}

Options:
(A) Retry failed agents (estimated +5 min)
(B) Abort workflow

Note: "Proceed with N perspectives" is only offered when N >= 2. When N = 0 or N = 1, only retry or abort are available because meaningful convergence analysis requires at least 2 perspectives.

On >= 4 agents completing: Proceed automatically to Stage 3.

On 4 agents completing (1 failed/timed out): Present user options:

4 of 5 perspectives complete. 1 failed: {archetype} ({reason})

Options:
(A) Retry {archetype} (estimated +5 min)
(B) Proceed with 4 perspectives (reduced diversity)
(C) Abort workflow

State Update: Record each agent's completion status, confidence, search success in workflow-state.yaml. Then current_state: DIVERGING -> CONVERGING.

Stage 3: Convergence + Parallel Discovery (5-10 minutes)

Preconditions: Stage 2 complete. At least 4 perspective outputs available.

The orchestrator executes two parallel tracks during Stage 3:

  • Track A (primary, blocking): Convergence analysis
  • Track B (secondary, non-blocking): Workflow discovery

Track B is non-blocking with respect to Track A: convergence analysis proceeds regardless of discovery status. At the Stage 3/4 transition, if discovery has not completed, the orchestrator waits up to 30 seconds before proceeding without cached results.

Track A: Convergence Analysis (inline)

  1. Collect all perspective outputs from perspectives/*.md
  2. Extract key insights, confidence levels, evidence, and research-backed status from each
  3. Perform LLM-based semantic grouping (see ../perspective-swarm/references/convergence-algorithm.md, Step 2a for implementation details including JSON schema and fallback triggers)
  4. Apply convergence scoring algorithm (see ../perspective-swarm/references/convergence-algorithm.md, Steps 3-5)
  5. The convergence analysis identifies convergent insights (themes appearing in 2+ perspectives) with confidence weighting
  6. Divergent insights (unique to single perspectives) are attributed to their originating archetype
  7. Handle missing archetypes using the compensation table in the protocol spec
  8. Conflicts are presented neutrally -- do not force artificial consensus
  9. Generate stage-3-synthesis.md

Track B: Workflow Discovery (parallel)

  1. Run workflow discovery algorithm per ../perspective-swarm/references/workflow-discovery.md
  2. Cache results to available-workflows.yaml
  3. Self-exclusion: filter out brainstorming-pm and perspective-swarm from discovery results (prevent self-handoff)
  4. Relevance scoring is deferred to Stage 4 (requires synthesis content)

Quality Gate:

  • All available perspectives incorporated
  • At least 2 convergent insights OR explicit "portfolio of options" framing
  • At least 3 divergent insights captured
  • Conflicts presented neutrally
  • Discovery results cached (or explicitly noted as unavailable)

State Update: Record convergent_count, divergent_count, grouping_method, grouping_latency_ms, and discovery status in workflow-state.yaml. Then current_state: CONVERGING -> AWAITING_USER.

Stage 4: User Review + Handoff

Preconditions: Stage 3 complete. Synthesis document generated. Discovery results available from Stage 3 (cached in available-workflows.yaml). If Stage 3 discovery did not complete, the orchestrator runs discovery synchronously (5-second timeout) before presenting options.

Actions:

  1. Score discovered workflows for relevance against synthesis content (see ../perspective-swarm/references/workflow-discovery.md, Relevance Scoring Algorithm)
  2. The orchestrator presents synthesis to user with options:
[Stage 4/4 - OUTPUT] Synthesis Complete

[Executive summary of convergent and divergent insights]

Options:
(A) Accept - Workflow complete
(B) Refine - Provide feedback, return to Stage 3

Continue with another workflow:
(C) [research] lit-pm - Comprehensive literature review (4-24 hours)
(D) [implementation] programming-pm - Software implementation (2-8 hours)
  1. Handle user choice:

- Accept: current_state -> COMPLETED. Archive session. - Refine: current_state -> CONVERGING. Capture user feedback. Loop back to Stage 3 with feedback incorporated into synthesis. - Handoff (C/D/...): Validate target skill still available. Generate handoff-payload.yaml per ../perspective-swarm/references/handoff-schema.md. Invoke target skill with payload path. current_state -> COMPLETED on successful handoff.

State Update: Record user_decision, any refinement_feedback, and handoff_target in workflow-state.yaml.


Session Management

Session directory structure and lock protocol are defined in the perspective-swarm protocol spec (../perspective-swarm/SKILL.md, "Session Directory Structure" and "Session Lock Protocol" sections). The orchestrator follows those specifications exactly.

Atomic writes: All writes to workflow-state.yaml must use the atomic write pattern:

  1. Write complete state to a .tmp file
  2. Validate YAML syntax of the .tmp file
  3. Rename .tmp to target path (workflow-state.yaml)
  4. Retain .bak of previous version

The orchestrator reads the complete state file, updates relevant fields in memory, and writes the complete file atomically. File-level replace semantics, not field-level merge.

Session recovery: On invocation, the orchestrator checks for existing sessions in /tmp/swarm-session-*/. See the protocol spec for the recovery prompt format and options (Resume / Start fresh / Cancel).

Error Handling

WebSearch Failure

Classification and handling follow the protocol spec (see ../perspective-swarm/SKILL.md, "Error Handling" section):

  • Transient: retry after 30 seconds
  • Rate limited: exponential backoff (30s, 60s, 120s)
  • No results: proceed without search, note "limited research"
  • Service down: proceed with reasoning-only, reduce confidence by 1

Agent Timeout

  • Per-agent timeout: 10 minutes. Mark as timed out, proceed with available agents.
  • Stage 2 total timeout: 15 minutes. Hard ceiling for all agent completion.
  • If < 4 agents complete after timeout: present user options (retry/abort).

Catastrophic Failure

  • < 4 agents complete AND user chooses abort: current_state -> FAILED
  • Unrecoverable error at any stage: current_state -> FAILED, preserve session for debugging
  • Global 45-minute safety ceiling: escalate to user regardless of stage

Timeout Summary

StageTimeoutAction on Timeout
1 (Framing)5 minEscalate to user
2 (Perspectives)15 min totalProceed with available (min 4)
2 (per agent)10 minMark incomplete, proceed
3 (Synthesis)10 minDeliver partial synthesis
3 (Discovery)30 sec wait + 5 sec syncProceed without cached results
4 (User Review)No timeoutUser-controlled
Global45 minSafety ceiling, escalate

Handoffs

ConditionHand Off To
User accepts synthesis (Stage 4, option A)User (workflow complete)
User requests deeper research (Stage 4, option C+)Discovered workflow target (via handoff payload)
User aborts at any stageUser (session preserved for potential resume)

Incoming handoff: When invoked via --handoff {payload_path}, extract context.original_prompt and context.problem_type from the payload. Map optional fields (synthesis_summary, suggested_terms, uncertainties) to Stage 1 framing inputs. Proceed directly to Stage 1 with pre-populated context.

References

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

33.16%
按下载量换算29

Claude

31.92%
按下载量换算28

Cursor

18.73%
按下载量换算16

Gemini CLI

8.63%
按下载量换算8

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills