Risposta diretta
Ho strutturato il mio portfolio brownfield usando Superpowers e Get Shit Done su Claude Code, risolvendo problemi di memoria operativa e scalabilità con un "meta-IDE" che vive nei file di planning del repository, migliorando la produttività e riducendo gli errori.
Questo non è un articolo che vende un workflow. È il diario di come ho strutturato il lavoro sul mio portfolio brownfield usando due framework che girano sopra Claude Code: Superpowers di obra e Get Shit Done di qrx. Diciannove phase eseguite, sessantaquattro sub-agent registrati, cinquecentododici dev-tool, settecentodue articoli pubblicati. Numeri reali, niente demo “hello-world-claude-code”.
Disclaimer di indipendenza: Non affiliato a Anthropic, a obra o a qrx. Pago il mio piano Claude Code come tutti, ho scoperto i due framework cercando un modo per non perdere il filo su un portfolio cresciuto oltre la mia memoria operativa. Quello che leggi è la sintesi onesta di cosa ha funzionato e cosa no - incluse le volte in cui ho buttato giorni di lavoro perché un pattern apparentemente solido si è rotto in produzione.
Perché un altro articolo sui framework agentici nel 2026?
Nel 2026 ci sono almeno cinque modi seri per scrivere codice con un LLM:
Cursor IDE, Aider, Cline, Claude Code nudo e Claude Code con framework sopra.
Io ne ho provati quattro in produzione su un repository vero - il monorepo
che gira federicocalo.dev - e da circa un anno sto su Claude Code +
Superpowers + GSD per una ragione molto semplice: su progetti brownfield
long-running, gli altri tool mi facevano perdere il filo. Non perché
siano peggio, ma perché ottimizzano un’altra cosa.
Cursor è formidabile per pair-programming inline. Aider è perfetto per atomic commit con un occhio sul diff. Cline lascia il controllo umano puntuale nel VS Code. Tutti e tre presumono però che la decisione su cosa fare la prendi tu, sessione per sessione. Quando il backlog passa dai dieci ai mille task e le decisioni di sei mesi fa contano per quelle di oggi, quel modello non scala più. GSD risolve esattamente questo. Superpowers risolve un problema gemello: quale comportamento dovrebbe avere l’LLM in una data fase di lavoro (brainstorming, debugging, TDD, code review, security review). Insieme formano un “meta-IDE” che non vive nell’editor ma nei file di planning del repository.
Cosa trovi in questa cornerstone
- Quattro track tematiche: Superpowers (skill marketplace), GSD (planning system), Claude Code platform (MCP, hooks, IDE/CLI, cost) e Cross-framework workflow.
- Diciotto cluster article tecnici che approfondiscono ogni track con esempi tratti dal portfolio.
- Una matrice comparativa 5×10 contro Cursor, Aider, Cline e Claude Code nudo.
- Cinque lead-magnet PDF scaricabili (workflow patterns, skill cookbook, GSD recipe book, agent orchestration patterns, cost optimization decision matrix).
- Una CTA email semplice: scrivimi il tuo workflow Claude Code e lo discutiamo.
Le quattro track della serie
Ho diviso i diciotto cluster in quattro track tematiche, una per ogni area in cui ho effettivamente speso ore di sperimentazione. Non è una tassonomia teorica: è la mappa dei capitoli che avrei voluto leggere un anno fa quando ho aperto la prima volta una skill SKILL.md di Superpowers e mi sono chiesto “ok, ma a cosa serve davvero?”.
Track 1 - Superpowers (sei cluster)
Superpowers è uno skill marketplace per Claude Code. La parte che colpisce
non è il marketplace in sé, è il meccanismo di skill auto-discovery:
Claude Code legge il frontmatter YAML di ogni SKILL.md nella
cartella .claude/skills/ e decide da solo quando invocarlo, in
base al campo description. La promessa è: “il modello sa
quando ha bisogno di brainstorming, debug, TDD, code-review - tu scrivi
la skill bene e lui la invoca al momento giusto.”
Un esempio illustrativo di frontmatter - non serve copiarlo ed eseguirlo, mostra solo come la skill si presenta al modello:
I sei cluster Superpowers in questa serie raccontano i pattern che ho davvero usato sul portfolio: skill design pattern (perché alcune skill funzionano e altre vengono ignorate dal modello), brainstorming skill (divergent thinking guidato), debugging skill (scientific method + checkpoint), TDD enforcement skill (RED-GREEN-REFACTOR forzato sul codice nuovo), code-reviewer skill (gate post-write integrato nel workflow di commit) e refactor-cleaner skill (cleanup dead code con knip + depcheck + ts-prune).
Track 2 - Get Shit Done (sei cluster)
GSD è la parte di workflow che mi ha cambiato di più il modo di lavorare. È
un planning system fasato: tutto il lavoro vive sotto una directory
.planning/ con quattro file canonici (PROJECT.md,
REQUIREMENTS.md, ROADMAP.md, STATE.md) e
cartelle phases/NN-slug/ dove ogni fase raccoglie i propri artefatti
(CONTEXT, AI-SPEC, UI-SPEC, RESEARCH, PATTERNS, VALIDATION, N×PLAN, VERIFICATION).
Il flusso tipico è una catena di comandi slash che chiamo “pipeline GSD”:
Il valore non è nei comandi: è in cosa fanno sotto. Il plan-checker, per esempio, è un sub-agent che legge i PLAN.md prodotti dal planner e li valuta su otto-dieci dimensioni (copertura requirement, copertura decisioni, qualità dei task, threat model, must_haves, ecc.). Se trova BLOCKER ti restituisce una lista strutturata di issue, e il workflow rispawna il planner per la revisione. Massimo tre iterazioni. Sulla mia Phase 19 il plan-checker iter 1 ha trovato cinque BLOCKER e sei WARNING che ho risolto in iter 2 - senza il checker, sarei andato in execute con piani rotti e me ne sarei accorto solo al commit di Wave 4.
I sei cluster GSD coprono: ROADMAP-driven planning (horizontal vs
vertical phasing), plan-checker (come risolvere BLOCKER/WARNING in
modo iterativo), agent orchestration (delegare a sub-agent senza
perdere il filo), wave-based parallel execution (speedup misurato 3-5x
su fasi multi-plan indipendenti), ingest-docs synthesizer (consolidare
sessanta-più documenti di planning sparsi in un singolo contesto coerente) e
memory management (la directory memory/ auto-curata
con sessanta-più file MD che persistono fra le conversazioni).
Track 3 - Claude Code platform (quattro cluster)
I framework girano sopra Claude Code, ma il sottostante non è banale. Quattro
cluster coprono gli elementi della piattaforma che impattano direttamente
il workflow: MCP server development (come collegare Claude Code a
tool esterni via Model Context Protocol), hooks system
(PreToolUse, PostToolUse, Stop - quando
vale la pena scriverli e quando sono solo over-engineering), IDE / web /
CLI / desktop (in quale ambiente conviene fare cosa) e cost
optimization (decision matrix Opus 4.7 / Sonnet 4.6 / Haiku 4.5 + pattern
di sub-agent isolation con worktree per evitare race condition sui file).
Track 4 - Cross-framework workflow (due cluster)
Due cluster a chiudere la serie, perché in pratica Superpowers e GSD si parlano di continuo. Il primo è debug-skill troubleshooting end-to-end con plan-checker + agent: come un bug reale viene affrontato dalla skill di debugging, ripreso dal plan-checker se il fix richiede modifiche al piano, e poi delegato a un sub-agent per l’implementazione. Il secondo è integrazione Superpowers + GSD: il pattern operativo in cui una skill invoca un agent che esegue uno specifico plan - è il punto in cui i due framework smettono di essere giocattoli separati e diventano un sistema unico.
La mia esperienza: 19 phase su un portfolio brownfield reale
Prima di entrare nella matrice comparativa vale la pena raccontare da dove
arriva questo metodo. Il portfolio federicocalo.dev non è un
progetto greenfield: è un monorepo con tre microservizi che hanno
compiuto un anno di vita in produzione su un VPS Hetzner, con
diciannove phase GSD completate, sessantaquattro sub-agent
registrati nel sistema, cinquecentododici dev-tool live, settecentodue
articoli pubblicati su diciotto lingue. Tutto questo è cresciuto
incrementalmente, con un budget cognitivo umano limitato (il mio) e una
finestra di context window AI altrettanto limitata.
Senza framework il mio collo di bottiglia era la memoria
operativa fra una sessione e l’altra. Aprivo Claude, gli spiegavo
il contesto, lavoravamo bene per due ore, poi mi alzavo per un meeting
e al ritorno dovevo ricostruire da zero la prossima decisione. Il primo
vero salto è stato quando ho iniziato a usare la directory
memory/ auto-curata di GSD: ogni decisione, feedback o
preferenza importante viene salvata come file MD con tag categoria
(project / feedback / reference / pattern). Oggi ne ho oltre sessanta
e il modello li ricarica all’inizio di ogni nuova sessione lavorativa.
Non è perfetto, ma ha trasformato il context-loss problem in qualcosa di
affrontabile.
Il fallimento più costoso del 2026 non è stato un bug
di produzione: è stato un build OOM in Angular SSR. Avevo settecento
route prerendered, il processo Node consumava tutta la memoria del VPS,
e per due notti consecutive il deploy falliva senza un errore
sufficientemente chiaro. Senza GSD l’avrei trattato come “problema
isolato, fix locale”. Con GSD l’ho aperto come Phase dedicata, ho
lasciato che la skill di debugging guidasse l’investigazione (V8 heap
limit interno, non kernel OOM), ho creato Plan separati per heap
configuration / swap setup / build profiling, e ho documentato il
pattern in memory/project_build_oom_heap_limit.md in modo
che la prossima volta che il modello vede sintomi simili sappia da dove
partire. Quattro giorni di lavoro, ma il sapere è restato sistemico,
non aneddotico.
Un altro caso emblematico è la traduzione XLF in diciassette lingue.
Avevamo undicimila chiavi i18n da tradurre con LLM locali (Ollama
qwen2.5:14b). I primi due batch erano pieni di problemi: placeholder
persi nelle traduzioni, route slug tradotti linguisticamente (rompendo
i link interni), inflazione dei punteggi nella dashboard di audit. Ho
consolidato sei lezioni operative in
memory/feedback_xlf_translation_lessons.md: ogni nuovo
batch parte caricando quel file, e gli errori non si sono più ripetuti.
È esattamente il tipo di lezione che senza un sistema di planning
esplicito viene persa al primo cambio di sessione.
Anche il provider AI è una decisione che porta
l’impronta di GSD. All’inizio multiplexavo Cloudflare Workers AI per i
tool runtime, poi mi sono accorto che pagavo per chiamate che la rete
e la latenza degradavano in pratica e che la privacy degli utenti non
mi convinceva (i prompt passavano per un servizio managed esterno).
La decisione di passare a Ollama on-prem sul VPS come
provider primario (modello llama3.1:8b) è stata catturata
come Key Decision in PROJECT.md e applicata a cascata
nelle phase successive. Nessuna pull request misteriosa con
“refactor AI provider”: una decisione visibile, datata,
reversibile.
Infine c’è la lancia OSS di Phase 9: dovevo lanciare
diciotto repository pubblici (sei plan template GSD, sei skill pack
Superpowers, sei snippet vari) e il piano iniziale prevedeva di
pubblicare tutto in una settimana. Il plan-checker mi ha bloccato:
“Wave 1 UI-only soltanto. Repo + CI + stars + HN launch sono Wave 2
con dipendenze esterne (community feedback, CI provider setup) che
non controlli - deferiscili.” Ho ascoltato. Wave 1 chiusa
2026-05-20 con diciotto card OSS in projects.json, hub e
detail pages live, sitemap aggiornata. Wave 2 è ancora in coda. La
serie è viva, il lancio reale viene quando i repo sono pronti - non
quando il calendario lo dice.
Diagramma decisionale: quale tool per quale task
La matrice comparativa di seguito è densa. Per chi cerca un colpo d’occhio veloce, il diagramma seguente sintetizza la decision tree che applico quando devo scegliere fra i cinque tool.
Confronto onesto con gli altri tool agentici (matrice 5×10)
Questa è la matrice che apre la sub-page comparativa. Il tono che adotto in tutta la serie è mix bilanciato: dove un tool vince lo dico, dove perde anche. Niente partisan post, niente “Claude Code è il futuro e basta”. Ognuno ottimizza per un caso d’uso diverso. La mia raccomandazione cambia in base al contesto.
Riassunto matrice comparativa
| Criterio | Claude Code + SP + GSD | Cursor | Aider | Cline | Plain Claude |
|---|---|---|---|---|---|
| Ambiente | CLI + IDE + Web + Desktop | IDE fork VS Code | CLI | VS Code ext | Web only |
| Agent multi-step | Sì (sub-agent + wave) | Sì (Composer) | Limitato | Sì (autonomous) | No |
| Multi-agent orchestration | Sì (GSD wave) | No | No | No | No |
| Planning system strutturato | Sì (GSD) | No | No | No | No |
| Skill / plugin marketplace | Sì (Superpowers + plugin) | Limited (Cursor rules) | No | MCP-based | No |
| MCP support | Native (full ecosystem) | In evoluzione | No | Native | Limitato |
| Git integration | Native + worktree isolation | Limitata | Native (auto-commit + undo) | Limitata | No |
| Costo tipico | €20/mo + API | €20/mo + API | Pay-per-use BYOK | Pay-per-use BYOK | €20/mo o free |
| Curva di apprendimento | Alta | Bassa | Media | Media | Bassissima |
| Quando vince | Brownfield long-running multi-fase | Greenfield IDE-driven | Hot-fix git-tracciati | VS Code estensione semplice | Chat one-shot |
Lettura corretta della tabella: se devi mantenere un progetto vivo per dodici-trentasei mesi con decine di feature parallele, Claude Code + SP + GSD ripaga la curva di apprendimento. Se devi tirare giù un MVP in una settimana e poi non lo guarderai più, Cursor o plain Claude ti danno il time-to-market migliore. Se vuoi automatizzare un singolo refactor su un repo tracciato con git, Aider è imbattibile.
Cinque lead-magnet PDF scaricabili
Cinque PDF gratuiti, uno per ogni angolo del workflow. Sono i template, le decision matrix e i pattern che uso davvero - non documenti generati per generare lead. Ognuno è scaricabile via opt-in alla newsletter “AI Engineering Workflow” (lista dedicata su Buttondown, non vendiamo nulla, decido io quando inviarla, di solito una mail al mese con quello che ho imparato fra una phase e l’altra).
- Workflow Agentico 2026: 18 pattern dal portfolio - sintesi dei diciotto cluster con un pattern per cluster, diagramma sintetico e un esempio.
- Skill Design Cookbook - dieci skill template Markdown completi (brainstorming, debugging, TDD, code-reviewer, security-reviewer, refactor-cleaner, build-error-resolver, doc-updater, e2e-runner, test-automator).
- GSD Planning Recipe Book - dieci plan template per use case ricorrenti: feature brownfield, refactor architetturale, doc-only update, OSS launch, content series, dev-tool aggiungi, schema migration, i18n batch, security audit, infrastructure setup.
- Agent Orchestration Patterns - cinque pattern wave-based parallel + sub-agent delega (parallel research wave, sequential dependency chain, fan-out fan-in, sub-agent isolation worktree, recursive task decomposition).
- Cost Optimization Claude Code - decision matrix Opus/Sonnet/Haiku per task type + benchmark cost mensile reale (range sanitized).
Come questa serie cita gli autori upstream
Superpowers è creato da obra (Jesse Vincent). Il
repository pubblico è il riferimento da cui prendere skill ufficiali e
esempi. Get Shit Done è creato da qrx ed è il
planning system di cui parlo in tutta la serie. Nei cluster cito i repo
pubblici dei due autori e, dove uso un esempio loro, lo dico esplicitamente
con un link contestuale. Niente outreach pre-pubblicazione (non voglio
bloccare la serie su feedback altrui), niente affiliate. Se obra o qrx
leggono e vogliono segnalare imprecisioni, l’email
federico@federicocalo.dev è aperta come per tutti gli altri.
Quando NON usare Claude Code + Superpowers + GSD
Un capitolo che spesso manca nei post entusiasti sui framework agentici è il quando non usarli. Lo aggiungo qui per onestà intellettuale e per evitare di vendere il workflow come soluzione universale, perché non lo è.
Non usarli per script one-shot da 50 righe. Se devi parsare un CSV una volta sola, plain Claude o Cursor sono più veloci. Aprire una phase GSD, scrivere un PLAN, validarlo con plan-checker e poi spawnare un executor è overhead non giustificato. La regola empirica che applico: se il task non porterà valore in due settimane (cioè non si ripeterà), salta GSD.
Non usarli su MVP greenfield in modalità sprint. Quando ho costruito il primo prototipo del marketplace dataset (Phase 4 originale, poi rifatto in Phase 17), GSD avrebbe rallentato la velocità di iterazione esplorativa. In quella fase Cursor con Composer multi-file è oggettivamente più adatto: serve fare, non strutturare. GSD vince dopo, quando l’MVP regge il primo utente reale e diventa brownfield.
Non scrivere Superpowers skill per pattern usati una volta. Una skill SKILL.md ha overhead di manutenzione: frontmatter, description tuning, validazione che il modello la invochi quando serve. Se un comportamento ti serve due volte all’anno, un prompt ad-hoc è più economico. Le mie skill attive coprono comportamenti che chiamo settimanalmente (debugging, code-review, TDD, refactor-cleaner).
Non delegare a sub-agent task piccoli. Lo spawn di un sub-agent ha un costo (context loading, fixture setup, prompt tax). Per modifiche < 50 righe in un singolo file conviene fare in line. I sub-agent danno valore quando il task è disjoint (file diversi), lungo (> 200 righe modificate) o quando vuoi isolare il context window (analisi senza inquinare la conversazione principale).
In sintesi: Claude Code + Superpowers + GSD è un investimento che ripaga su progetti long-running con backlog visibile. Per one-shot, sprint MVP, fix isolati, gli strumenti tradizionali (Cursor, Aider, plain Claude) restano migliori. La decision matrix nel diagramma sopra cattura questa logica in modo visivo.
Strategia evergreen: principi prima della sintassi
Claude Code, Superpowers e GSD evolvono in fretta. Una sintassi corretta oggi può essere riscritta domani. Per questo la serie è scritta undated e principi-first: descrivo pattern (skill design, planning fasato, wave parallelization) trasferibili anche se il comando cambia nome. Quando mostro un comando lo faccio per esempio, mai per copia-incolla mission-critical. Aggiornamenti maggiori dei framework vengono riflessi in note al footer dell’articolo invece di riscrivere l’intera sezione.
Domande frequenti
Le cinque domande più ricevute via email dopo la prima bozza della
serie. Il blocco è renderizzato anche come FAQPage
structured data per i rich snippet Google.
Cosa sono Superpowers e Get Shit Done?
Superpowers è uno skill marketplace per Claude Code creato
da obra che permette di registrare skill richiamabili in automatico
dal modello (brainstorming, debugging, TDD, code review).
Get Shit Done è un planning system fasato di
qrx che struttura il lavoro in ROADMAP → PHASE → PLAN
con plan-checker, agent orchestration e wave-based parallelization.
Come scelgo tra Claude Code, Cursor e Aider per progetti complessi?
Cursor è IDE-native (curva di apprendimento bassa, miglior pair-programming inline). Aider è CLI git-aware (commit auto, undo nativo). Claude Code + Superpowers + GSD è la combinazione preferibile per progetti brownfield long-running con planning strutturato: paghi una curva di apprendimento alta in cambio di sub-agent orchestration e plan-checker iterativo che riducono cicli di rework.
Posso usare Superpowers senza Claude Code?
No. Superpowers è un plugin che dipende dal sistema di skill auto-discovery
di Claude Code (lettura di SKILL.md con frontmatter, invocazione
automatica via description matching). Fuori da Claude Code la cartella
skill resta inerte. GSD invece è un set di slash command system che può
essere richiamato in qualunque ambiente con supporto Claude Code.
Quanto costa usare Claude Code professionalmente per un portfolio brownfield?
Sul mio portfolio (diciannove phase eseguite, sessantaquattro sub-agent, cinquecentododici dev-tool, settecentodue articoli) la spesa mensile resta nel range €100–€300 grazie a una decision matrix sul modello: Opus per planning e plan-checker, Sonnet per esecuzione e code review, Haiku per batch lookup ripetitivi. Senza decision matrix la spesa sarebbe almeno il doppio.
Come configuro GSD per un brownfield project senza riscrivere la roadmap?
GSD si attacca al brownfield senza forzare riscritture. Avvii con
/gsd:new-project, importi le decisioni esistenti via
/gsd:ingest-docs che sintetizza file di planning preesistenti,
e definisci una ROADMAP orizzontale (fasi tematiche orizzontali) che
lavora in parallelo invece di forzare un waterfall. La sezione “GSD su
brownfield” della sub-page /career/gsd/ ha la
guida step-by-step.
Cosa ho imparato scrivendo questa cornerstone
Scrivere una cornerstone su due framework che uso ogni giorno mi ha costretto a una cosa che evitavo: rendere espliciti i pattern impliciti. Quando lavori su un workflow personalizzato da mesi, molte regole sono nella memoria muscolare. Trasformarle in cluster article con titoli, esempi e anti-pattern significa dire ad alta voce “ecco perché questa cosa funziona”, e qualche volta scoprire che non funzionava per il motivo che pensavo.
La seconda lezione è sul confronto con gli altri tool. Avevo l’istinto di raccontare Claude Code + SP + GSD come la scelta giusta. Mentre scrivevo la matrice comparativa mi sono reso conto che Cursor è oggettivamente migliore in due dimensioni dove io non lo userei (pair-programming inline, onboarding di un nuovo collega in due ore) e che Aider risolve un problema che io continuo a maltrattare a mano (atomic commit con git undo). Il confronto onesto è il valore. Se la serie ne convince qualcuno a rimanere su Cursor perché è la scelta giusta per il suo contesto, io ho fatto la mia parte.
Anti-pattern evitati
- Vendere il workflow come prodotto. Niente “GSD Setup Personalizzato €200 + 1h call”. La serie è educational, non commerciale. Il valore tangibile (i template PDF) è gratis dietro opt-in newsletter. Volevo evitare il framing “ecco perché il mio workflow è il futuro” che genera engagement breve ma reputazione fragile.
- Pubblicare comandi corretti oggi ma fragili domani. La sintassi dei framework cambia. Articoli undated più focus su principi astratti sono la mia copertura contro l’obsolescenza. Ogni esempio di codice ha un disclaimer implicito: “pattern, non production-ready copy-paste”.
Una storia ricevuta che vale la pena condividere
Questa sezione comparirà nei cluster article via via che arrivano le
mail dei lettori (con consenso esplicito + pseudonimizzazione). Per ora
è qui come segnaposto del feedback loop: se sei arrivato fin qui e hai
una storia sul tuo workflow Claude Code da raccontarmi,
scrivimi a federico@federicocalo.dev. La leggo
io personalmente, rispondo a tutte, e con il tuo consenso esplicito potrei
pseudonimizzarla e citarla nei cluster successivi.
Commenti
Caricamento commenti...
Accedi per commentare