brainstorming

Guides collaborative requirement exploration and produces approved design specs before implementation.

1|Updated Dec 30, 2025
One-click install
npx skills add https://github.com/Fidasek009/agents --skill brainstorming-fidasek009
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: brainstorming
Source: https://github.com/Fidasek009/agents/tree/main/.agents/skills/brainstorming
Command: npx skills add https://github.com/Fidasek009/agents --skill brainstorming-fidasek009

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often jump into coding before understanding requirements, leading to wasted work on wrong assumptions. This Skill enforces a structured design-first workflow that turns vague ideas into reviewed, approved specification documents before any implementation begins. ## Core Features & Use Cases - Structured Discovery Dialogue: Explores project context, then asks clarifying questions one at a time to understand purpose, constraints, and success criteria. - Approach Comparison: Proposes 2-3 implementation approaches with trade-offs and a clear recommendation, applying YAGNI to cut unnecessary features. - Spec Generation & Review Gates: Writes the approved design to docs/specs/YYYY-MM-DD-<topic>-design.md, runs a self-review for placeholders and contradictions, and requires user sign-off before implementation. - Use Case: Before building a new feature, use this Skill to decompose the request, present design sections for approval, and commit a reviewed spec document to git. ## Quick Start Use the brainstorming skill to help me design the new notification feature before writing any code.

Frequently Asked Questions about brainstorming

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a design spec before implementing a feature?▼

Start by exploring the current project context, then ask clarifying questions one at a time about purpose, constraints, and success criteria. Propose 2-3 approaches with trade-offs, present the design in sections for approval, and write the final spec to docs/specs/ with a dated filename.

How to break down a large software project into smaller specs?▼

Identify the independent subsystems first, map how they relate, and decide the build order. Then run the full design flow on the first sub-project only, giving each sub-project its own spec document rather than one oversized spec.

Should simple projects still go through a design review process?▼

Yes, every project goes through the design process regardless of perceived simplicity. The design can be just a few sentences for trivial work, but it must be presented and approved, since simple projects are where unexamined assumptions cause the most wasted effort.

What should a spec self-review check before implementation?▼

Check for placeholders like TBD or TODO, internal contradictions between sections, scope that spans multiple independent subsystems, and requirements ambiguous enough to be interpreted two ways. Fix issues inline and then ask the user to review the committed spec file.

When should I not start coding after brainstorming a design?▼

Do not write code or invoke implementation skills until the design has been presented, the spec document written and committed, and the user has explicitly approved the spec. Change requests send the process back through the review loop.