kevmoo/kevmoo_skills/just-brainstorm

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.

• Epistemic Separation & Capability Matrices: Explicitly separate **Shipped

/ Verified Reality (backed by merged commits, releases, or live code) from Committed Plans (open issues/PRs) and Speculative Proposals / Spikes** (unmerged prototypes or ideas). Never collapse unmerged branches, planned roadmap items, or third-party work into "Available / Shipped" cells in comparison matrices.

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.
• In any capability or gap-analysis table, include a Provenance / Evidence

column citing the primary source (file path, release version, or open PR/issue) for every status claim.

• 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).