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 instructions are broadly consistent with a 'brainstorming' helper, but there are a few internal inconsistencies and surprise behaviors (notably automatic file writes/commits and mixed guidance about which other skills may be invoked) that you should understand before installing.

Purpose & Capability

The name and description match the instructions: the skill is intended to explore intent, propose approaches, and produce a design doc. However, the SKILL.md assumes the agent will read the repository, write files, and make git commits, yet the skill metadata declares no required binaries or tools (e.g., git) or config paths. This is a modest mismatch: reading/writing the project and committing is reasonable for this purpose, but the skill should declare that it expects repository access and git capabilities.

Instruction Scope

The runtime instructions explicitly direct the agent to inspect project files, explore recent commits, write a design file under docs/plans/, and commit it to git. Those actions will read and modify user project data and change version control history — behavior that can be surprising if the user did not expect automatic writes/commits. The instructions also contain a contradictory guidance: a hard gate that allows only invoking writing-plans after brainstorming, but elsewhere suggests using an 'elements-of-style:writing-clearly-and-concisely' skill if available. This mixed guidance is ambiguous and grants the agent discretion to call other skills in practice.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so it doesn't download or install third-party code. That is the lowest-risk install mechanism.

Credentials

The skill requests no environment variables, credentials, or config paths. The actions it prescribes (reading repository files and committing) are consistent with its purpose and do not require external credentials by default. However, if commits or repository operations in your environment require credentials (e.g., pushing to remote), the skill may trigger credential usage implicitly — the SKILL.md does not discuss or restrict that.

Persistence & Privilege

always is false and autonomous invocation is allowed (default). The skill instructs writing files inside the project and committing them to git — this is a modest persistence/privilege requirement (modifying the user's repo). It's not requesting permanent platform-level privileges, but you should be aware it intends to change your repository state and could be invoked autonomously unless you restrict it.

What to consider before installing

This skill is mostly coherent for a design/brainstorming helper, but review these before installing: - Expect repository reads and writes: the SKILL.md tells the agent to inspect files and recent commits and to write docs/plans/YYYY-MM-DD-<topic>-design.md and commit it. If you do not want an agent making commits automatically, do not grant it repo write/commit permissions or require explicit confirmation before file changes. - Confirm git/tool availability: the skill assumes git and filesystem access but does not declare required binaries. Ensure your agent environment provides the tools you expect and that you understand which credentials (if any) will be used to commit/push. - Clarify allowed follow-on skills: the instructions both restrict follow-on invocation to writing-plans and also suggest using an elements-of-style skill. Ask the author to remove the contradiction or explicitly list permitted helper skills. - Consider limiting autonomy: because the agent may invoke other skills and can modify your repo, restrict autonomous invocation or require user approval steps for writes/commits. If you want to proceed, ask the skill author to: declare expected binaries/permissions (git, write access), remove the ambiguous cross-skill guidance, and change automatic commit behavior to require explicit user confirmation (or create the file but not commit it). These changes would raise confidence to 'high' and likely move the assessment to 'benign.'

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 and get user approval.

<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>

Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

Checklist

You MUST create a task for each of these items and complete them in order:

1. Explore project context — check files, docs, recent commits
2. Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
3. Propose 2-3 approaches — with trade-offs and your recommendation
4. Present design — in sections scaled to their complexity, get user approval after each section
5. Write design doc — save to docs/plans/YYYY-MM-DD-<topic>-design.md and commit
6. Transition to implementation — invoke writing-plans skill to create implementation plan

Process Flow

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Invoke writing-plans skill";
}

The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

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
• Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
• 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:

• Invoke the writing-plans skill to create a detailed implementation plan
• Do NOT invoke any other skill. writing-plans is the next step.

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, get approval before moving on
• Be flexible - Go back and clarify when something doesn't make sense