Brainstorming

Socratic design refinement before coding. Use when user requests feature without clear spec.

Security Scan

The skill is an instruction-only 'brainstorming' helper that asks clarifying questions, proposes approaches, and produces a design doc—its requirements and instructions are consistent with its stated purpose.

Purpose & Capability

Name/description (Socratic design refinement) match the SKILL.md workflow (clarifying questions, alternatives, design doc). The actions requested (produce design text, save a doc, hand off to a planning skill) are proportionate to that purpose.

Instruction Scope

Instructions are narrowly scoped to eliciting requirements, generating alternatives, creating a design doc, and saving it to docs/design/YYYY-MM-DD-feature-name.md. This is expected, but be aware it instructs the agent to write a file to the workspace and to pass the doc to another skill (writing-plans). If you don't want automatic file writes or cross-skill handoffs, note that behavior.

Install Mechanism

No install spec and no code files — instruction-only skill with no binaries or downloads. Low install risk.

Credentials

Requires no environment variables, credentials, or config paths. Declared requirements match the SKILL.md (which does not reference secrets or external services).

Persistence & Privilege

always is false and the skill is user-invocable; it does not request elevated or persistent privileges. Model invocation is enabled (normal default), which allows autonomous calls, but nothing in the skill justifies elevated persistence.

Assessment

This skill appears coherent and low-risk: it asks questions, outlines approaches, creates a design doc, and suggests saving it in docs/design. Before installing, decide whether you are comfortable with the agent writing files into your workspace and automatically handing documents to another skill (writing-plans). If you prefer tighter control, run it only when invoked manually, inspect generated docs before committing, and verify the permissions/behavior of any downstream skill (writing-plans) that will receive the design doc.

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:

# 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:

I'll add Redis caching to the API.

Good:

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.