home / skills / revokslab / shipfree / brainstorming

brainstorming skill

/.cursor/skills/brainstorming

This skill helps brainstorm and translate ideas into designs and specs for a Next.js SaaS boilerplate.

This is most likely a fork of the brainstorming skill from openclaw
npx playbooks add skill revokslab/shipfree --skill brainstorming

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.4 KB
---
name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
---

# Brainstorming Ideas Into Designs

## Overview

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.

## The Process

**Understanding the idea:**
- Check out the current project state first (files, docs, recent commits)
- Ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message - if a topic needs more exploration, break it into multiple questions
- Focus on understanding: purpose, constraints, success criteria

**Exploring approaches:**
- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why

**Presenting the design:**
- Once you believe you understand what you're building, present the design
- Break it into sections of 200-300 words
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense

## After the Design

**Documentation:**
- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
- Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git

**Implementation (if continuing):**
- Ask: "Ready to set up for implementation?"
- Use superpowers:using-git-worktrees to create isolated workspace
- Use superpowers:writing-plans to create detailed implementation plan

## Key Principles

- **One question at a time** - Don't overwhelm with multiple questions
- **Multiple choice preferred** - Easier to answer than open-ended when possible
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
- **Explore alternatives** - Always propose 2-3 approaches before settling
- **Incremental validation** - Present design in sections, validate each
- **Be flexible** - Go back and clarify when something doesn't make sense

Overview

This skill guides collaborative brainstorming before any creative or engineering work, turning rough ideas into validated designs and specs. It insists on exploring user intent, constraints, and success criteria through one-question-at-a-time dialogue. The goal is clear, incremental validation and a repeatable path from idea to implementable plan.

How this skill works

Begin by understanding project context, reviewing files, docs, and recent commits when available. Ask a single clarifying question (prefer multiple-choice) and refine the idea step by step. Propose 2–3 approaches with trade-offs, recommend one, then present the design in 200–300 word sections, checking for validation after each section.

When to use it

  • Before adding a new feature, component, or API endpoint
  • When modifying core behavior or architecture
  • When preparing specs for implementation or handoff
  • When multiple stakeholders need aligned design decisions
  • During sprint planning to reduce rework and scope creep

Best practices

  • Ask exactly one question per message to avoid cognitive overload
  • Prefer multiple-choice questions to speed decision-making
  • Propose 2–3 alternative approaches and lead with a recommended option
  • Keep designs YAGNI-focused: remove unnecessary features early
  • Present designs in 200–300 word sections and validate after each

Example use cases

  • Designing a new subscription flow for a Next.js SaaS app
  • Planning a refactor of authentication and session handling
  • Specifying component props and data flow for a shared UI library
  • Deciding on database schema changes and migration strategy
  • Creating test strategy and error handling for a new API

FAQ

What happens if stakeholders disagree during validation?

Record the differing viewpoints, propose a small experiment or lightweight prototype, and return with measured results to resolve disputes incrementally.

How long should each design section be?

Keep sections between 200–300 words focused on one topic area (architecture, components, data flow, etc.) and ask for confirmation before proceeding.