brainstorming

Brainstorming Ideas Into Designs

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "brainstorming" with this command: npx skills add okwinds/miscellany/okwinds-miscellany-brainstorming

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:

  • Review current project context first (key files/docs, recent commits, existing patterns).

  • Ask one question per message to refine the idea (prefer multiple-choice when possible).

  • Focus on: purpose, constraints, success criteria, non-goals.

Exploring approaches:

  • Propose 2–3 approaches with trade-offs.

  • Recommend one approach and explain why.

Presenting the design:

  • Present the design in 200–300 word chunks and confirm after each chunk.

  • Cover: architecture, components, data flow, error handling, testing.

  • Be ready to backtrack if the user says something doesn’t fit.

After the Design

Documentation:

  • Write the validated design to docs/plans/YYYY-MM-DD-<topic>-design.md when that convention exists; otherwise create docs/plans/ or ask where to put it.

  • If you have a writing-quality skill available, use it before finalizing the doc.

  • If the repo is under git and the user wants it tracked, commit the design doc.

Implementation (if continuing):

  • Ask: “Ready to set up for implementation?”

  • If the user wants a separate workspace, use a git worktree.

  • Create a concrete implementation plan before writing code.

Key Principles

  • One question at a time — Don’t overwhelm with a questionnaire.

  • Multiple choice preferred — Faster to answer and reduces ambiguity.

  • YAGNI ruthlessly — Remove unnecessary scope/features from designs.

  • Explore alternatives — Always consider 2–3 viable approaches.

  • Incremental validation — Confirm each design chunk before continuing.

  • Be flexible — Adjust quickly when something doesn’t fit.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

headless-web-viewer

No summary provided by upstream source.

Repository SourceNeeds Review
General

prd-to-engineering-spec

No summary provided by upstream source.

Repository SourceNeeds Review
General

prd-writing-guide

No summary provided by upstream source.

Repository SourceNeeds Review