just-brainstorm

name	just-brainstorm
description	Ponder architectural designs, explore potential solutions, weigh tradeoffs, or analyze the impact of proposed codebase changes without making code changes. Always outputs the analysis to a Markdown artifact.
key_features	["Architectural design","Trade-off evaluation","Impact & \"what-if\" analysis","Codebase metric gathering"]

When to use this skill

Activate this skill when you need to think through a design, explore options, or evaluate the impact of a potential change before writing code.

Examples of trigger phrases:

• "Let me brainstorm..."
• "Just brainstorming here..."
• "What if we [do specific change]..."
• "What would break if we..."
• "How hard would it be to migrate..."
• "Help me design..."

Critical Rule: Zero Codebase Changes

• NO CODEBASE FILE EDITS OR CREATION: Do not edit existing project files, write new implementation code, or modify repository state.
• MANDATORY ARTIFACT GENERATION: The only permitted file creation is the design/analysis artifact (.md file in the conversation artifacts directory).

Procedural Workflow

1. Gather Context & Empirical Data (Read-Only)

• Inspect the codebase using read-only tools (grep_search, view_file, list_dir) to ground your brainstorming or analysis in reality.
• For Impact Analysis ("What-if"): Gather real statistics. Calculate usage counts, identify affected call sites, and map out dependencies. Do not guess.

2. Interactive Alignment (ask_question)

• Use ask_question early if the goals, constraints, or the scope of the "what-if" scenario are unclear.

3. Generate the Artifact

• Write the output to a .md file in the conversation artifacts directory.
• Use RequestFeedback: false in the artifact metadata (do not block with "Proceed" gates).
• Structure for Design Brainstorming:
  • Present 2–4 distinct options.
  • Highlight tradeoffs (pros/cons) and relative complexity.
• Structure for Impact Analysis ("What-if"):
  • Detail the step-by-step impact if the change were executed.
  • List breaking changes, migration friction, and affected modules with metrics.
  • Provide a summary risk/feasibility verdict.

4. Conclude with Next Steps

• Suggest 1–3 actionable next steps (e.g., create an implementation plan, explore a specific option deeper, or start implementation).