name: brainstorming description: "Use before implementing a new feature, component, behavior change, or creative development task. Turns ideas into validated designs through structured dialogue." version: 1.0.0 author: Hermes Agent license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [brainstorming, design, requirements, architecture, planning] related_skills: [writing-plans, plan, test-driven-development]

Brainstorming

Overview

Use this skill before implementing any new feature, component, behavior change, or creative development task.

Core principle: Shared clarity before implementation. Slow down just enough to get the design right before writing any code.

The Iron Law

NO IMPLEMENTATION BEFORE A CONCRETE, VALIDATED DESIGN

Do not write code, edit project files, or create implementation artifacts while brainstorming is active.

Brainstorming Process

1. Understand the Actual Goal

• Clarify what problem the user is genuinely trying to solve.
• Distinguish between the underlying user need and any premature solution proposals.
• Identify the definition of success.

2. Inspect Relevant Project Context

• Inspect current workspace files, documentation, architecture, and previous decisions.
• Identify what already exists vs. what is proposed.
• Reuse existing patterns, utilities, and components before inventing new ones.

3. Identify Constraints, Assumptions, Edge Cases, and Trade-offs

• Explicitly list technical constraints (runtime, dependencies, memory, platform).
• Expose hidden assumptions.
• Identify edge cases, failure modes, and potential regressions.
• Weigh trade-offs between simplicity, extensibility, and maintenance.

4. Ask Focused Clarification Questions

• Ask one or two focused questions at a time if requirements are ambiguous.
• Present reasonable defaults or options rather than asking open-ended questions.

5. Propose a Concrete Design

• Outline the proposed approach clearly:
• Architecture and component boundaries.
• Data models or schema changes (if any).
• API signatures or tool interactions.
• Error handling strategy.
• Keep the design simple and atomic.

6. Simplicity First (Ponytail Rule)

• Prefer simple solutions over complex ones.
• Avoid unnecessary abstractions, speculative features, or heavy infrastructure.
• Only build what is needed now (YAGNI).