Skill-ul Writing Plans - Planuri de Implementare
Ce face
Writing-plans transformă o specificație sau un set de cerințe într-un plan de implementare detaliat, structurat pe task-uri mici de 2-5 minute. Fiecare pas urmează TDD: scrii testul care pica, rulezi, implementezi minimul necesar, rulezi iar, apoi comiți. Planul presupune că dezvoltatorul știe să codeze, dar nu cunoaște codebase-ul, toolset-ul sau domeniul problemei. Include maparea fișierelor, interfețe clare, responsabilități unice per fișier și recomandări de testare.
Când îmi folosește
Îl folosești înainte de a atinge codul, ori de câte ori ai o cerință multi-step. Dacă specificația acoperă subsisteme independente, skill-ul sugerează să o spargi în planuri separate. Este ideal pentru proiecte unde vrei ca fiecare task să producă software funcțional și testabil independent.
Cum îl invoc / declanșez
Skill-ul se activează automat când primești o specificație clară. La începutul răspunsului, agentul anunță verbatim: “I’m using the writing-plans skill to create the implementation plan.” Nu există comandă manuală de invocat de la utilizator; verifică doctrina pentru detalii exacte dacă lucrezi într-un worktree izolat creat cu superpowers:using-git-worktrees.
Exemplu practic
Primești cerința: “Adaugă validare de email la formularul de contact”. Planul va conține:
- maparea fișierelor (ex: src/validators/email.ts, tests/validators/email.test.ts)
- task-uri separate: “Scrie testul failing”, “Rulează testul”, “Implementează logica minimă”, “Rulează testele”, “Commit”
- indicații despre structura fișierelor și cum să testezi fără a presupune cunoștințe preexistente despre proiect.
Output / unde aterizează
Planul se salvează automat la docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md. Header-ul obligatoriu include titlu, goal, architecture, tech stack și checklist cu checkbox-uri pentru sub-agenti. Poți suprascrie locația prin preferințe personale.
Limite / gotchas
Nu aplica skill-ul pe task-uri triviale sau single-file. Dacă fișierele devin prea mari, planul poate propune split-uri, dar respectă pattern-urile existente ale codebase-ului. Fiecare plan trebuie să producă software working și testabil singur; nu combina subsisteme diferite într-un singur document.