brainstorming

Beginner-first idea exploration and design. Use when the user wants to brainstorm features, shape requirements, compare options, and produce a design document. Works for any project or topic. The final output is a saved design doc — no validation, no implementation planning.

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 vibemastery/toolkit/vibemastery-toolkit-brainstorming

Brainstorming

Turn rough ideas into a clear, beginner-friendly design document.

Hard Rules

  1. Do not write implementation code during this skill.
  2. Do not commit changes. The user must review everything first.
  3. Ask one question at a time.
  4. Never work on main (or the default branch). Check the current branch at the start — if on main, create a feature branch before any file changes.

Goals

  1. Understand what the user wants to build and why.
  2. Gather as much context as possible about the problem space.
  3. Explain choices in simple terms for beginners.
  4. Produce a design document in a user-approved location.

Workflow

  1. Check the current git branch. If on main (or the default branch), create and switch to a feature branch named feature/<short-topic>. Ask the user to confirm the branch name.
  2. Explore project context (files, existing patterns, constraints).
  3. Clarify the idea through guided questions (see Questioning Standard below).
  4. Propose 2-3 implementation approaches with trade-offs.
  5. Recommend one approach and explain why it is best.
  6. Ask the user to approve the recommended approach.
  7. Ask if they want to save the design document in docs/plans/ or a different directory.
  8. Write the design document using the filename format YYYY-MM-DD-<topic>-design.md.
  9. Tell the user they can invoke writing-plans when they are ready to create a step-by-step implementation plan.

Questioning Standard

Do not rapid-fire questions. The goal is to help the user think through their idea, not to interrogate them.

  • Ask one question at a time.
  • If the user is unsure or gives a vague answer, help them explore the answer. Offer options, examples, or explain what the trade-offs are so they can decide.
  • Only move to the next question once the current one has a clear answer.
  • Use simple language and concrete examples when framing questions.

Output Structure

The design document must include these sections:

  • Idea in simple terms
  • Options and trade-offs
  • Recommended approach
  • Workflow and why
  • Next step — always: "Run writing-plans when ready to create the implementation plan."

Beginner Explanation Standard

  • Use simple language, short sentences, and concrete examples.
  • Avoid jargon when possible. If needed, define it in one line.
  • Explain both what to do and why it matters.
  • Keep each section concise and practical.

Completion Criteria

The brainstorming session is complete only when:

  1. The user approves the recommended approach.
  2. The design document is saved to a user-approved location.
  3. The user has been told they can invoke writing-plans when ready.
  4. No commit has been created.

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

setup-wizard

No summary provided by upstream source.

Repository SourceNeeds Review
General

executing-plans

No summary provided by upstream source.

Repository SourceNeeds Review
General

debug-coach

No summary provided by upstream source.

Repository SourceNeeds Review
General

writing-plans

No summary provided by upstream source.

Repository SourceNeeds Review