/workflows-brainstorm
Explore methodological approaches through structured analysis before planning implementation
$ npx -y skills add brycewang-stanford/Auto-Empirical-Research-Skills --skill workflows-brainstorm --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/workflows-brainstorm
Context preview
The summary Claude sees to decide when to auto-load this skill.
Explore methodological approaches through structured analysis before planning implementation
SKILL.md
workflows-brainstorm.SKILL.mdname: workflows:brainstorm
description: Explore methodological approaches through structured analysis before planning implementation
argument-hint: "<research question or methodological problem>"
allowed-tools: Read, Glob, Bash
Brainstorm a Research Approach or Methodological Decision
**Pipeline mode:** This command operates fully autonomously. All decisions are made automatically.
Brainstorming helps answer **WHAT** approach to take through structured analysis. It precedes `/workflows:plan`, which answers **HOW** to implement it.
**Process knowledge:** See `references/brainstorming-techniques.md` for detailed question techniques, approach exploration patterns, and parsimony principles.
Research Question
<feature_description> #$ARGUMENTS </feature_description>
**If the research question above is empty:** Infer the question from recent context — open files, recent conversation, or the project's estimation code. If no context is available, state "No research question provided" and stop.
Execution Flow
Phase 0: Assess Scope
Evaluate whether brainstorming is needed based on the research question.
**Clear requirements indicators:**
- Specific estimator or method already chosen
- Referenced existing implementation to follow
- Described exact identification strategy
- Constrained, well-defined methodological scope
**If requirements are already clear:** Skip brainstorming and note: "Requirements are detailed enough to proceed directly to planning. Run `/workflows:plan` to continue." Then stop.
**If requirements need exploration:** Proceed to Phase 1.
Phase 1: Understand the Problem
1.1 Codebase and Literature Research
Run a targeted scan to understand existing patterns and related methods:
- Task methods-explorer("Understand existing methodological patterns and approaches related to: <research_question>")
Focus on: existing estimation code, identification strategies used in this project, methodology documented in papers or notes.
1.2 Problem Decomposition
Analyze the research question systematically without user interaction:
1. **Core question**: What is the fundamental methodological decision being made? 2. **Constraints**: What data limitations, computational budgets, or identification requirements constrain the choice? 3. **Prior art**: What has this project already done that's similar? What methods are established in the literature? 4. **Success criteria**: What would a good solution look like? (e.g., consistent estimation, reasonable computational cost, testable identification)
Document findings from the research agent and decomposition. If the question is ambiguous, pick the most natural interpretation given the project context and note the assumption.
Phase 2: Compare Approaches
Propose **2-3 concrete methodological approaches** based on research and analysis.
For each approach, provide:
| Criterion | Approach A | Approach B | Approach C | |-----------|-----------|-----------|-----------| | **Description** | 2-3 sentence summary | 2-3 sentence summary | 2-3 sentence summary | | **Theoretical properties** | Consistency, efficiency, robustness to misspecification | ... | ... | | **Identification requirements** | What assumptions are needed? How testable are they? | ... | ... | | **Computational cost** | Estimation time, convergence difficulty, parallelizability | ... | ... | | **Data requirements** | Sample size needs, variable availability, panel structure | ... | ... | | **Software availability** | Packages (Python/R/Julia), maturity, documentation | ... | ... | | **Monte Carlo evidence** | Finite-sample performance from methodology literature | ... | ... |
**Recommendation:** Select the simplest approach that satisfies the identification requirements. Apply parsimony — prefer well-understood methods with established software implementations over novel approaches unless the research question specifically demands novelty.
Document why the recommended approach was chosen and what conditions would favor the alternatives.
Phase 3: Capture the Analysis
**Entry condition:** Phase 2 comparison table is complete with all criteria filled for all approaches. **Exit condition:** Document written to docs/brainstorms/ with all required YAML frontmatter fields.
Artifact Storage
Write the brainstorm output to `docs/brainstorms/<topic>-requirements.md` with YAML frontmatter:
---
status: active
date: YYYY-MM-DD
topic: <descriptive topic>
---
If `docs/brainstorms/` contains a recent document matching this topic, ask the user: "Found existing brainstorm on this topic. Continue from it, or start fresh?"
Write a brainstorm document to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`.
Ensure `docs/brainstorms/` directory exists before writing.
**Document structure:**
---
title: [Brainstorm Topic]
date: YYYY-MM-DD
status: complete
recommended-approach: [Name of recommended approach]
---
# [Brainstorm Topic]
## Research Question
[The question being explored]
## Problem Decomposition
- Core question: [...]
- Key constraints: [...]
- Prior art in this project: [...]
- Success criteria: [...]
## Approaches Compared
### Approach A: [Name]
- **Description:** [...]
- **Theoretical properties:** [...]
- **Identification requirements:** [...]
- **Computational cost:** [...]
- **Data requirements:** [...]
- **Software:** [...]
- **Monte Carlo evidence:** [...]
- **Verdict:** [...]
### Approach B: [Name]
[Same structure]
### Approach C: [Name] (if applicable)
[Same structure]
## Recommendation
**Selected: [Approach Name]**
[Why this approach. What conditions would favor alternatives. Key tradeoffs accepted.]
## Key Decisions
- [Decision 1 and rationale]
- [Decision 2 and rationale]
## Assumptions Made
- [Any assumptions made during autonomous analysis]
## Open Questions
- [Questions that should be resolved during planning or implementation]
## References
- [Methodological papers cited]
- [Software doc
Read more
name: workflows:brainstorm description: Explore methodological approaches through structured analysis before planning implementation argument-hint: "<research question or methodological problem>" allowed-tools: Read, Glob, Bash
Brainstorm a Research Approach or Methodological Decision
**Pipeline mode:** This command operates fully autonomously. All decisions are made automatically.
Brainstorming helps answer **WHAT** approach to take through structured analysis. It precedes `/workflows:plan`, which answers **HOW** to implement it.
**Process knowledge:** See `references/brainstorming-techniques.md` for detailed question techniques, approach exploration patterns, and parsimony principles.
Research Question
<feature_description> #$ARGUMENTS </feature_description>
**If the research question above is empty:** Infer the question from recent context — open files, recent conversation, or the project's estimation code. If no context is available, state "No research question provided" and stop.
Execution Flow
Phase 0: Assess Scope
Evaluate whether brainstorming is needed based on the research question.
**Clear requirements indicators:**
- Specific estimator or method already chosen
- Referenced existing implementation to follow
- Described exact identification strategy
- Constrained, well-defined methodological scope
**If requirements are already clear:** Skip brainstorming and note: "Requirements are detailed enough to proceed directly to planning. Run `/workflows:plan` to continue." Then stop.
**If requirements need exploration:** Proceed to Phase 1.
Phase 1: Understand the Problem
1.1 Codebase and Literature Research
Run a targeted scan to understand existing patterns and related methods:
- Task methods-explorer("Understand existing methodological patterns and approaches related to: <research_question>")
Focus on: existing estimation code, identification strategies used in this project, methodology documented in papers or notes.
1.2 Problem Decomposition
Analyze the research question systematically without user interaction:
1. **Core question**: What is the fundamental methodological decision being made? 2. **Constraints**: What data limitations, computational budgets, or identification requirements constrain the choice? 3. **Prior art**: What has this project already done that's similar? What methods are established in the literature? 4. **Success criteria**: What would a good solution look like? (e.g., consistent estimation, reasonable computational cost, testable identification)
Document findings from the research agent and decomposition. If the question is ambiguous, pick the most natural interpretation given the project context and note the assumption.
Phase 2: Compare Approaches
Propose **2-3 concrete methodological approaches** based on research and analysis.
For each approach, provide:
| Criterion | Approach A | Approach B | Approach C | |-----------|-----------|-----------|-----------| | **Description** | 2-3 sentence summary | 2-3 sentence summary | 2-3 sentence summary | | **Theoretical properties** | Consistency, efficiency, robustness to misspecification | ... | ... | | **Identification requirements** | What assumptions are needed? How testable are they? | ... | ... | | **Computational cost** | Estimation time, convergence difficulty, parallelizability | ... | ... | | **Data requirements** | Sample size needs, variable availability, panel structure | ... | ... | | **Software availability** | Packages (Python/R/Julia), maturity, documentation | ... | ... | | **Monte Carlo evidence** | Finite-sample performance from methodology literature | ... | ... |
**Recommendation:** Select the simplest approach that satisfies the identification requirements. Apply parsimony — prefer well-understood methods with established software implementations over novel approaches unless the research question specifically demands novelty.
Document why the recommended approach was chosen and what conditions would favor the alternatives.
Phase 3: Capture the Analysis
**Entry condition:** Phase 2 comparison table is complete with all criteria filled for all approaches. **Exit condition:** Document written to docs/brainstorms/ with all required YAML frontmatter fields.
Artifact Storage
Write the brainstorm output to `docs/brainstorms/<topic>-requirements.md` with YAML frontmatter:
--- status: active date: YYYY-MM-DD topic: <descriptive topic> ---
If `docs/brainstorms/` contains a recent document matching this topic, ask the user: "Found existing brainstorm on this topic. Continue from it, or start fresh?"
Write a brainstorm document to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`.
Ensure `docs/brainstorms/` directory exists before writing.
**Document structure:**
--- title: [Brainstorm Topic] date: YYYY-MM-DD status: complete recommended-approach: [Name of recommended approach] --- # [Brainstorm Topic] ## Research Question [The question being explored] ## Problem Decomposition - Core question: [...] - Key constraints: [...] - Prior art in this project: [...] - Success criteria: [...] ## Approaches Compared ### Approach A: [Name] - **Description:** [...] - **Theoretical properties:** [...] - **Identification requirements:** [...] - **Computational cost:** [...] - **Data requirements:** [...] - **Software:** [...] - **Monte Carlo evidence:** [...] - **Verdict:** [...] ### Approach B: [Name] [Same structure] ### Approach C: [Name] (if applicable) [Same structure] ## Recommendation **Selected: [Approach Name]** [Why this approach. What conditions would favor alternatives. Key tradeoffs accepted.] ## Key Decisions - [Decision 1 and rationale] - [Decision 2 and rationale] ## Assumptions Made - [Any assumptions made during autonomous analysis] ## Open Questions - [Questions that should be resolved during planning or implementation] ## References - [Methodological papers cited] - [Software doc
📌 文档结构(2026-07-22 起): 本文件是中文默认入口 —— banner + badges + 信任面 + 9 阶段流水线速览 + 76 行合集总表。 每个合集的完整描述、按用途分组、精确数字、验证方法在 docs/CONTENT_ZH.md(扩展正文,总表行内的 → 直接跳转到对应锚点)。 English version: README-en.md · 中文扩展正文:docs/CONTENT_ZH.md · README-zh-CN.md 已弃用(重定向占位) 🌐 语言: English |
Other skills on auto-empirical-research-skills.
- /pipeline
Classical end-to-end empirical analysis workflow in the traditional Python econometric stack — pandas + numpy + scipy + statsmodels + linearmodels + pyfixest + rdrobust + econml + causalml + matplotlib/seaborn. **Defaults to economics empirical-paper style** (AER / QJE / AEJ) —
Open skill - /pipeline
Classical end-to-end empirical analysis workflow in the modern tidyverse + econometrics R ecosystem — dplyr + tidyr + haven + fixest + sandwich + lmtest + clubSandwich + AER + ivreg + did + bacondecomp + HonestDiD + eventstudyr + rdrobust + rddensity + Synth + gsynth + synthdid
Open skill - /pipeline
Classical end-to-end empirical analysis workflow in the traditional Stata ecosystem — native Stata + reghdfe + ivreg2 + csdid + did_imputation + eventstudyinteract + sdid + rdrobust + rddensity + synth + synth_runner + psmatch2 + teffects + ebalance + coefplot + esttab + asdoc +
Open skill - /00-Full-empirical-analysis-skill_StatsPAI
Use when the user asks to run a full empirical / causal analysis in Python — by default in the style of an applied economics paper (AER / QJE / JPE / ReStud / AEJ) with DID / RD / IV / SCM / DML / matching, written-out estimating equation + identifying assumption, Table 1 /
Open skill - /00.1-Full-empirical-analysis-skill_Python
Classical end-to-end empirical analysis workflow in the traditional Python econometric stack — pandas + numpy + scipy + statsmodels + linearmodels + pyfixest + rdrobust + econml + causalml + matplotlib/seaborn. **Defaults to economics empirical-paper style** (AER / QJE / AEJ) —
Open skill - /00.2-Full-empirical-analysis-skill_Stata
Classical end-to-end empirical analysis workflow in the traditional Stata ecosystem — native Stata + reghdfe + ivreg2 + csdid + did_imputation + eventstudyinteract + sdid + rdrobust + rddensity + synth + synth_runner + psmatch2 + teffects + ebalance + coefplot + esttab + asdoc +
Open skill

