Brainstorming: De la Idee la Design Aprobat

Brainstorming-ul din Wednesday e skill-ul care te obligă să transformi o idee vagă într-un design clar și aprobat înainte să scrii vreun rând de cod sau să modifici ceva. Nu e opțional și se aplică la orice: feature nou, componentă, refactor sau chiar o listă de todo-uri. Scopul e să înțelegi contextul, intenția utilizatorului, constrângerile și criteriile de succes printr-un dialog natural, pas cu pas.

Ce face

Skill-ul explorează proiectul existent, pune întrebări de clarificare una câte una și propune 2-3 abordări cu trade-off-uri. După ce primești aprobarea pe design, generează un document de specificații salvat în docs/superpowers/specs/, face o auto-review și cere confirmarea ta înainte să treacă la implementare. Tot procesul e guvernat de un hard-gate: nimic nu se implementează până nu ai aprobat designul.

Când îmi folosește

Îl folosești obligatoriu înainte de orice activitate creativă. Chiar și la schimbări „simple” – un config tweak sau o funcție mică – unde presupunerile neexaminate pot genera cel mai mult rework. Dacă sari peste el, riști să construiești ceva ce nu rezolvă problema reală sau nu se potrivește cu restul sistemului.

Cum îl invoc / declanșez

Skill-ul pornește automat când detectează intenție creativă. Pentru detalii exacte despre triggeri și comenzi verifică doctrina pentru detalii exacte. Odată activat, urmează checklist-ul intern: context, întrebări, abordări, design secționat și aprobare.

Exemplu practic

Spui „vreau să adaug dark mode”. Brainstorming-ul verifică mai întâi structura actuală a temelor, apoi întreabă: „Care e scopul principal – accesibilitate, preferințe user sau branding?” După răspuns, propune trei variante (CSS variables, context API, library externă), recomandă una și prezintă designul în secțiuni mici. Abia după ce aprobi fiecare secțiune și spec-ul final, trece la planul de implementare.

Output / unde aterizează

Rezultatul final e un fișier docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md commit-uit, plus tranziția automată către skill-ul de writing-plans. Totul rămâne trasabil și revizuibil.

Limite / gotchas

Nu combina niciodată întrebările cu oferte de visual companion – asta vine într-un mesaj separat. Nu invoca skill-uri de implementare până nu ai aprobare explicită, indiferent cât de mic pare proiectul. Dacă spec-ul conține placeholder-e sau contradicții, self-review-ul le prinde înainte să ajungă la tine. All guides