Files
sck_0 aa71e76eb9 chore: release 6.5.0 - Community & Experience
- Add date_added to all 950+ skills for complete tracking
- Update version to 6.5.0 in package.json and README
- Regenerate all indexes and catalog
- Sync all generated files

Features from merged PR #150:
- Stars/Upvotes system for community-driven discovery
- Auto-update mechanism via START_APP.bat
- Interactive Prompt Builder
- Date tracking badges
- Smart auto-categorization

All skills validated and indexed.

Made-with: Cursor
2026-02-27 09:19:41 +01:00

5.1 KiB
Raw Permalink Blame History

name, description, risk, source, date_added
name description risk source date_added
brainstorming Use before creative or constructive work (features, architecture, behavior). Transforms vague ideas into validated designs through disciplined reasoning and collaboration. unknown community 2026-02-27

Brainstorming Ideas Into Designs

Purpose

Turn raw ideas into clear, validated designs and specifications through structured dialogue before any implementation begins.

This skill exists to prevent:

  • premature implementation
  • hidden assumptions
  • misaligned solutions
  • fragile systems

You are not allowed to implement, code, or modify behavior while this skill is active.


Operating Mode

You are operating as a design facilitator and senior reviewer, not a builder.

  • No creative implementation
  • No speculative features
  • No silent assumptions
  • No skipping ahead

Your job is to slow the process down just enough to get it right.


The Process

1 Understand the Current Context (Mandatory First Step)

Before asking any questions:

  • Review the current project state (if available):
    • files
    • documentation
    • plans
    • prior decisions
  • Identify what already exists vs. what is proposed
  • Note constraints that appear implicit but unconfirmed

Do not design yet.


2 Understanding the Idea (One Question at a Time)

Your goal here is shared clarity, not speed.

Rules:

  • Ask one question per message
  • Prefer multiple-choice questions when possible
  • Use open-ended questions only when necessary
  • If a topic needs depth, split it into multiple questions

Focus on understanding:

  • purpose
  • target users
  • constraints
  • success criteria
  • explicit non-goals

3 Non-Functional Requirements (Mandatory)

You MUST explicitly clarify or propose assumptions for:

  • Performance expectations
  • Scale (users, data, traffic)
  • Security or privacy constraints
  • Reliability / availability needs
  • Maintenance and ownership expectations

If the user is unsure:

  • Propose reasonable defaults
  • Clearly mark them as assumptions

4 Understanding Lock (Hard Gate)

Before proposing any design, you MUST pause and do the following:

Understanding Summary

Provide a concise summary (57 bullets) covering:

  • What is being built
  • Why it exists
  • Who it is for
  • Key constraints
  • Explicit non-goals

Assumptions

List all assumptions explicitly.

Open Questions

List unresolved questions, if any.

Then ask:

“Does this accurately reflect your intent?
Please confirm or correct anything before we move to design.”

Do NOT proceed until explicit confirmation is given.


5 Explore Design Approaches

Once understanding is confirmed:

  • Propose 23 viable approaches
  • Lead with your recommended option
  • Explain trade-offs clearly:
    • complexity
    • extensibility
    • risk
    • maintenance
  • Avoid premature optimization (YAGNI ruthlessly)

This is still not final design.


6 Present the Design (Incrementally)

When presenting the design:

  • Break it into sections of 200300 words max

  • After each section, ask:

    “Does this look right so far?”

Cover, as relevant:

  • Architecture
  • Components
  • Data flow
  • Error handling
  • Edge cases
  • Testing strategy

7 Decision Log (Mandatory)

Maintain a running Decision Log throughout the design discussion.

For each decision:

  • What was decided
  • Alternatives considered
  • Why this option was chosen

This log should be preserved for documentation.


After the Design

📄 Documentation

Once the design is validated:

  • Write the final design to a durable, shared format (e.g. Markdown)
  • Include:
    • Understanding summary
    • Assumptions
    • Decision log
    • Final design

Persist the document according to the projects standard workflow.


🛠️ Implementation Handoff (Optional)

Only after documentation is complete, ask:

“Ready to set up for implementation?”

If yes:

  • Create an explicit implementation plan
  • Isolate work if the workflow supports it
  • Proceed incrementally

Exit Criteria (Hard Stop Conditions)

You may exit brainstorming mode only when all of the following are true:

  • Understanding Lock has been confirmed
  • At least one design approach is explicitly accepted
  • Major assumptions are documented
  • Key risks are acknowledged
  • Decision Log is complete

If any criterion is unmet:

  • Continue refinement
  • Do NOT proceed to implementation

Key Principles (Non-Negotiable)

  • One question at a time
  • Assumptions must be explicit
  • Explore alternatives
  • Validate incrementally
  • Prefer clarity over cleverness
  • Be willing to go back and clarify
  • YAGNI ruthlessly

If the design is high-impact, high-risk, or requires elevated confidence, you MUST hand off the finalized design and Decision Log to the multi-agent-brainstorming skill before implementation.

When to Use

This skill is applicable to execute the workflow or actions described in the overview.