Integrazione Superpowers + GSD: skill invoca agent che esegue plan

Superpowers e Get Shit Done sono utili separatamente. Diventano un sistema unico nel momento in cui una skill innesca uno spawn agent GSD che esegue uno specifico plan. È il punto in cui i due framework smettono di essere giocattoli separati. Questo è l'ultimo cluster della serie e descrive il pattern di integrazione che uso quotidianamente.

Disclaimer di indipendenza: non sono affiliato a obra, qrx, o Anthropic. Il pattern descritto è il workflow consolidato sul portfolio brownfield dopo ~12 mesi di uso parallelo dei due framework.

Il pattern essenziale

Una skill Superpowers attiva (es. code-reviewer) durante la sua procedura scopre situazione X che richiede planning strutturato (es. duplicazione cross-file che meriterebbe fase refactor dedicata). La skill, invece di limitarsi al report, suggerisce un comando GSD al modello. Il modello presenta il comando all'utente per conferma. Utente conferma. GSD prende il controllo: crea fase, discuss, plan, eventualmente execute.

Senza integrazione: tu (l'utente) devi capire da solo che il report skill richiede fase refactor, lanciare comandi GSD manualmente. Con integrazione: skill propone comando, tu approvi in 3 click.

Trigger pattern: skill che riconoscono "GSD-worthy moments"

Ogni skill nel mio portfolio è stata estesa nel body con sezione che identifica "situazioni che meritano GSD". Esempi:

• code-reviewer trova ≥3 MEDIUM duplicazione cross-file → suggerisce /gsd-phase <descrizione refactor>.
• brainstorming raggiunge fase Converge con 2+ alternative equivalenti e tradeoff lungo termine → suggerisce /gsd-discuss-phase N per catturare formalmente la decisione.
• debugging identifica causa di un bug che richiede modifiche cross-cutting su 3+ moduli → suggerisce /gsd-phase <descrizione hotfix multi-modulo>.
• tdd-guide incontra feature complessa con 10+ edge case → suggerisce /gsd-phase <feature> per pianificare proper coverage matrix invece di TDD ad-hoc.

Esempio sintetico: skill code-reviewer + /gsd-phase

Sintesi di una sessione tipica (non literal transcript):

[Modello scrive feature X in 5 file]

[Skill code-reviewer auto-invocata post-write]

Code Review Report:
  CRITICAL: 0
  HIGH: 0
  MEDIUM: 3
    - Duplicazione validazione fra src/payment/checkout.ts:42
      e src/payment/refund.ts:67
    - Duplicazione di errore mapping fra src/checkout.ts:80
      e src/payment-method.ts:55
    - Naming inconsistente: paymentMethod vs payment_method
      vs pm in 4 file

[Skill detect: 3 MEDIUM duplicazione cross-file = GSD-worthy]

Suggestion:
  Queste 3 MEDIUM indicano debito strutturale che merita una
  fase refactor dedicata invece di fix puntuali. Posso lanciare:

  /gsd-phase "Consolidate payment validation + error mapping +
              naming consistency cross-file"

  Procedere? [Y/n]

Utente conferma. GSD /gsd-phase crea fase nella ROADMAP + directory in .planning/phases/. Da lì il workflow GSD standard (discuss → plan → execute).

Pattern: skill che reads GSD state

Inverso: skill che usano informazione da .planning/STATE.md per decisioni context-aware.

Esempio. Skill debugging custom estesa: prima di iniziare investigation, legge STATE.md per capire la fase corrente. Se la fase corrente è Phase 17 (Search Console Fix), il body della skill adjusta priorità ipotesi (canonical, hreflang, INP mobile prima di altre cause).

Pattern: skill di dominio + state corrente = ipotesi più informate. Skill generica avrebbe valutato tutte le cause con peso uguale.

Pattern: GSD che usa skill durante execute

Doppio inverso: durante esecuzione di un plan GSD, gsd-executor può invocare skill durante la sua procedura.

Esempio (sintesi). Plan 20-02 (Phase 20 backend) include task "Implement LeadMagnetController endpoint extension". L'executor mentre scrive il controller, auto-invoca skill tdd-guide su nuovo business logic + skill code-reviewer post-write + skill security-reviewer su endpoint exposed.

Le tre skill girano dentro il contesto di un'esecuzione orchestrata. GSD fornisce structure macro; skill forniscono qualità micro.

Mantenere human-in-loop

Cruciale: skill non lanciano direttamente comandi GSD destructive senza confirm utente. Il pattern è suggest + confirm, non auto-execute.

Mantiene controllo utente:

• Skill propone comando.
• Modello presenta comando + rationale.
• Utente approva o rifiuta esplicitamente.
• Se approva, modello esegue comando GSD.

Eccezione: workflow YOLO mode (config workflow_mode: yolo in .planning/config.json) auto-conferma alcuni comandi. Uso solo per task low-risk (es. /gsd:capture). Comandi che modificano ROADMAP o spawn execute restano confirm-required anche in YOLO.

Quando NON integrare

1. Skill su task one-shot: scrivi una skill, la usi una volta. Non vale la pena estenderla con GSD suggestion.
2. GSD su progetti molto piccoli: 5-10 file totali. GSD è overkill, skill da sole bastano.
3. Sessioni esplorative: durante exploration, niente suggestion automatiche. Lascia spazio cognitivo al thinking libero. Integration kick in post-exploration.

Anti-pattern: skill che auto-eseguono GSD senza confirm

L'errore peggiore: skill che chiama direttamente /gsd-execute-phase senza confirm utente. Risk: execute parte mentre tu pensavi di "discutere solo" del problema. Plan partially completed, commit di fix prematuri.

Mitigation strict: skill propongono comandi GSD ma non li eseguono. Modello presenta. Utente approva.

Anti-pattern: troppe skill che propongono GSD

Se ogni skill suggerisce GSD ad ogni opportunità, il workflow diventa "ad ogni messaggio una nuova fase". Counter-productive.

Heuristica: skill propone GSD solo quando la situazione è chiaramente GSD-worthy. Esempi che ho considerato e scartato:

• Code-reviewer trova 1 MEDIUM → NO. Fix puntuale basta.
• Brainstorming raggiunge Converge con 1 raccomandazione forte → NO. Già deciso.
• Debugging risolve bug puntuale → NO. Skill sufficiente.

Soglia per suggerire GSD: situazione richiede modifiche su 3+ file o decisioni che durano mesi.

Setup minimo per provare l'integrazione

1. Skill code-reviewer di Superpowers attiva (auto-invoke post-write).
2. GSD installato + .planning/ initializzato.
3. Estendi body della skill code-reviewer con sezione "GSD-worthy moments" che propone /gsd-phase se trova ≥3 MEDIUM cross-file.
4. Test su un PR realistic. Verifica che suggestion appaia + confirm flow human-in-loop funzioni.

Conclusione di serie

Questo è l'ultimo cluster della serie. 18 articoli che coprono Superpowers (6), GSD (6), Claude Code platform (4), cross-framework workflow (2). Il pattern di integrazione descritto qui è il punto di sintesi: i due framework non sono concorrenti, sono complementari. L'uno fornisce structure macro (planning fasato), l'altro fornisce qualità micro (skill per ogni momento del workflow). Insieme formano un meta-IDE che non vive nell'editor ma nei file del repository.

Cosa ho imparato scrivendo questa serie

18 cluster + cornerstone + 2 sub-pages = 21 articoli, ~80k parole scritte. La lezione meta-cognitiva è che scrivere il workflow espliciti rende il workflow stesso migliore. Pattern che usavo per istinto sono diventati pattern documentati, condivisibili, iterabili. La serie non era solo content per i lettori; era esercizio di consolidamento personale del know-how che si era accumulato in modo tacito.

Secondo insight: pubblicare con disclaimer di indipendenza e tono onestamente bilanciato (mix di partisan + pragmatic + honest pro/con) crea più trust di un partisan post entusiasta. Quando dico "Cursor è meglio per IDE-native pair-programming" mentre uso Claude Code + Superpowers + GSD, la mia raccomandazione finale ha più peso perché ho riconosciuto i tradeoff veri.

Anti-pattern evitati nella serie intera

• Vendere il workflow come prodotto. Niente Premium tier "GSD Setup Personalizzato €200 + 1h call". Serie educational, non commerciale.
• Esempi code production-ready. Frammenti illustrativi sempre, mai pretese di runnable mission-critical. Riduce risk di obsolescenza framework.
• Skill che auto-eseguono GSD. Human-in-loop sempre.

Una storia ricevuta che vale la pena condividere

Sezione segnaposto finale. Se hai integrato Superpowers + GSD nel tuo workflow e vuoi raccontarmi cosa funziona (o cosa hai modificato rispetto al pattern descritto qui), scrivimi a federico@federicocalo.dev. Le storie pseudonimizzate (con consenso esplicito) saranno citate in articoli di update della serie e nel PDF lead-magnet "Workflow Agentico 2026: 18 pattern dal portfolio".

Grazie per essere arrivato fino all'ultimo cluster. Buon workflow.

← Torna al cornerstone della serie ← Cluster precedente: Debug-skill end-to-end