✓ Verified 💻 Development ✓ Enhanced Data

Brainstorming 2

Socratic design refinement before coding.

Rating: 4.3 (363 reviews)
Downloads: 740 downloads
Version: 1.0.0

Overview

Socratic design refinement before coding.

✨Key Features

Understand Intent

Explore Alternatives

Design Document

Transition to Planning

Complete Documentation

View Source →

Brainstorming Skill

When to Use

Trigger BEFORE writing code when:

User request is vague ("make it better", "add feature X")
Complex feature with multiple approaches
Design decisions impact multiple components

Workflow

Step 1: Understand Intent

Ask clarifying questions:

What problem are we solving?
Who is the user?
What's the success criteria?
What constraints exist? (time, compatibility, dependencies)

Step 2: Explore Alternatives

Present 2-3 approaches:

Approach A (simple): [description]
Approach B (robust): [description]
Approach C (future-proof): [description]

For each: Pros, Cons, Complexity (1-5)

Step 3: Design Document

After user picks approach, create design doc:

markdown

# Feature: [Name]

## Problem
[1-2 sentences]

## Solution
[Chosen approach, 3-5 sentences]

## Components Affected
- [Component 1]: [Change description]
- [Component 2]: [Change description]

## Testing Strategy
- Unit tests: [What to test]
- Integration tests: [What to test]

## Edge Cases
- [Case 1]
- [Case 2]

## Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

Save to: docs/design/YYYY-MM-DD-feature-name.md

Step 4: Transition to Planning

Pass design doc to writing-plans skill.

Anti-Patterns

❌ Jump straight to implementation ❌ Present only one approach ❌ Skip edge case discussion ❌ Forget to save design doc

Example

User: "Add caching"

Bad:

text

I'll add Redis caching to the API.

Good:

text

Let me understand the requirements first:

1. What should be cached? (API responses, DB queries, computed results?)
2. What's the invalidation strategy? (TTL, event-based, manual?)
3. What's the acceptable staleness? (seconds, minutes, hours?)

Based on your answers, I'll present 3 approaches with trade-offs.

Installation

Terminal bash


openclaw install brainstorming-2

Copied!

💻Code Examples

- [ ] [Criterion 2]

----criterion-2.txt

Save to: `docs/design/YYYY-MM-DD-feature-name.md`

### Step 4: Transition to Planning
Pass design doc to writing-plans skill.

## Anti-Patterns

❌ Jump straight to implementation
❌ Present only one approach
❌ Skip edge case discussion
❌ Forget to save design doc

## Example

User: "Add caching"

Bad:

example.md

# Feature: [Name]

## Problem
[1-2 sentences]

## Solution
[Chosen approach, 3-5 sentences]

## Components Affected
- [Component 1]: [Change description]
- [Component 2]: [Change description]

## Testing Strategy
- Unit tests: [What to test]
- Integration tests: [What to test]

## Edge Cases
- [Case 1]
- [Case 2]

## Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

example.txt

Let me understand the requirements first:

1. What should be cached? (API responses, DB queries, computed results?)
2. What's the invalidation strategy? (TTL, event-based, manual?)
3. What's the acceptable staleness? (seconds, minutes, hours?)

Based on your answers, I'll present 3 approaches with trade-offs.