Receber por email
← Voltar para o catálogo

brainstorming

Use when the user asks to design, plan, or explore approaches before implementing — creating features, building components, or adding functionality that would benefit from design exploration first.

14estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add redhat-community-ai-tools/claude-code-setup-evaluator

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/brainstorming-redhat-community-ai-tools/svg)](https://www.skillteca.com.br/skills/brainstorming-redhat-community-ai-tools)
#ai

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs through collaborative dialogue.

When this skill activates, present a design before writing code. The design can be short (a few sentences for simple projects) — scale it to the complexity of the task. Get the user's approval before proceeding to implementation.

Process

  1. Explore context — check files, docs, recent commits
  2. Ask clarifying questions — one at a time, prefer multiple choice, understand purpose/constraints/success criteria
  3. Propose 2-3 approaches — with trade-offs and your recommendation
  4. Present design — scale each section to its complexity, ask after each section if it looks right
  5. Write spec — save to docs/specs/ (create directory if needed) and commit
  6. User reviews spec — wait for approval before proceeding
  7. Transition — invoke writing-plans skill to create implementation plan

Design Principles

  • One question at a time — don't overwhelm with multiple questions
  • YAGNI ruthlessly — remove unnecessary features
  • Design for isolation — break into units with one clear purpose, well-defined interfaces, testable independently
  • Explore alternatives — always propose 2-3 approaches before settling
  • Scope check — if the request describes multiple independent subsystems, decompose into sub-projects first

Working in Existing Codebases

  • Explore the current structure before proposing changes. Follow existing patterns.
  • Where existing code has problems that affect the work, include targeted improvements as part of the design.
  • Don't propose unrelated refactoring. Stay focused on what serves the current goal.

After Design Approval

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

Compartilhar X LinkedIn