just-brainstorm

Files (2)

• SKILL.md
• evals.json · evals/

SKILL.md (first lines)

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

From FMorschel/agents, MIT.

More from FMorschel/agents