brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requi...

Security Scan

The skill's purpose and instructions are generally coherent for a brainstorming helper, but it also directs the agent to write design files and commit them to the repository without declaring required credentials or describing permission/approval flows.

Purpose & Capability

Name and description match the instructions: the skill is meant to turn ideas into designs through dialogue and iterative validation. It does not request unrelated binaries, env vars, or config paths.

Instruction Scope

Most runtime instructions stay within brainstorming (ask questions, propose approaches, present designs). However, the SKILL.md explicitly instructs the agent to write validated designs to docs/plans/YYYY-MM-DD-<topic>-design.md and to commit the design to git. It also tells the agent to 'use' other skills (writing-clearly-and-concisely, using-git-worktrees, writing-plans). Writing and committing changes is a material extension of 'brainstorming' and should be treated as an action that requires explicit permission and credential handling.

Install Mechanism

Instruction-only skill with no install spec and no code files; nothing will be written to disk by an installer. This is the lowest-risk install profile.

Credentials

The skill declares no required environment variables or credentials, yet its instructions imply the need to access project files and perform git commits. Committing will typically require repository write credentials or tooling access; those are not declared or explained, which is disproportionate to the declared requirements.

Persistence & Privilege

always: false and no special privileges are requested. The skill may be invoked autonomously by the agent (default behavior) and references other skills, but it does not request persistent presence or modify other skills' configs.

What to consider before installing

This skill is largely what it says — a guided brainstorming/design helper — but it also tells the agent to write a design file into your repo and commit it. Before installing or enabling it: verify how the agent will obtain permission to write/commit (will it ask you first?), restrict repository credentials if you don't want automated commits, and confirm whether invoking the referenced helper skills is allowed in your environment. If you only want advisory brainstorming, prefer a read-only setup (deny git write access) or require manual approval before any file write/commit actions. If you can, ask the skill author to clarify the commit workflow and explicitly declare any credentials or scopes needed.

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