create-pwt 1.0.0

package/template/.claude/skills/blueprint/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: blueprint
+description: Genera e aggiorna BLUEPRINT.xml — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON usare placeholder generici (es. "[da definire]", "[tipo]", "[condizione]") in nessun elemento del Blueprint XML. Ogni campo, tipo, policy e endpoint deve contenere dati reali derivati dagli output delle task dipendenti.
+</HARD-GATE>
+
+# Skill: Blueprint XML vivente
+
+Sei un agente specializzato nella generazione e aggiornamento del Blueprint XML del progetto. Il Blueprint è la sorgente di verità tecnica usata dagli agenti AI nella fase di implementazione.
+
+## Input atteso (passato dall'orchestratore)
+- Output 4.1 (architettura, schema DB, API)
+- Output 4.2 (struttura progetto, convenzioni, tracking)
+- Output 1.2 (feature core)
+- Output 1.3 (stack, KPI)
+- Eventuale BLUEPRINT.xml esistente (se è un aggiornamento)
+
+## Schema XML da produrre
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<blueprint version="1.0" project="[nome]" updated="[YYYY-MM-DD]">
+
+  <project>
+    <name>[nome]</name>
+    <description>[elevator pitch]</description>
+    <stack>
+      <item layer="frontend" tech="Next.js 15" notes="App Router, TypeScript"/>
+      <item layer="backend" tech="Supabase" notes="PostgreSQL, Auth, Storage, Realtime"/>
+      <item layer="deploy" tech="Vercel" notes="Edge Functions, CI/CD da GitHub"/>
+      <!-- aggiungere eccezioni dallo stack -->
+    </stack>
+  </project>
+
+  <features>
+    <feature id="[id]" priority="must|should|could" status="planned|in-progress|done">
+      <title>[titolo]</title>
+      <description>[descrizione]</description>
+      <screens>[lista schermate coinvolte]</screens>
+    </feature>
+  </features>
+
+  <database>
+    <table name="[nome]">
+      <field name="[campo]" type="[tipo]" nullable="false" notes="[note]"/>
+      <!-- ... -->
+      <rls>
+        <policy action="SELECT" role="authenticated" condition="[condizione]"/>
+      </rls>
+    </table>
+  </database>
+
+  <api>
+    <endpoint method="[GET|POST|...]" path="[path]" auth="[none|bearer|service]">
+      <description>[descrizione]</description>
+      <input>[schema input]</input>
+      <output>[schema output]</output>
+    </endpoint>
+  </api>
+
+  <conventions>
+    <item area="[area]" rule="[regola]"/>
+  </conventions>
+
+  <tracking>
+    <event name="[nome_evento]" trigger="[quando]" properties="[prop1,prop2]"/>
+  </tracking>
+
+</blueprint>
+```
+
+## Regole di generazione
+
+1. Ogni elemento deve avere dati reali — nessun placeholder generico
+2. Le features devono corrispondere esattamente all'output 1.2
+3. Lo schema DB deve corrispondere esattamente all'output 4.1
+4. Aggiungi commenti XML (`<!-- -->`) solo dove necessario per chiarire decisioni non ovvie
+5. Se stai aggiornando un Blueprint esistente: preserva i campi esistenti, aggiorna solo quelli cambiati, aggiungi `updated="[data]"` sul nodo radice
+
+## Output
+Il file XML completo, pronto per essere salvato come `docs/BLUEPRINT.xml`.

package/template/.claude/skills/deploy/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: deploy
+description: Deploy e release — checklist pre-deploy, env vars, smoke test — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON saltare nessun item della checklist pre-deploy. Ogni item deve essere verificato e marcato come completato, non applicabile (con motivazione), o bloccante.
+</HARD-GATE>
+
+# Skill: Deploy e release
+
+Sei un agente specializzato nella configurazione e verifica del deploy di applicazioni Next.js su Vercel + Supabase. Produci checklist operative e documentazione infrastrutturale.
+
+## Input atteso (passato dall'orchestratore)
+- Stack e ambienti da 1.3 e `system/preferences.json`
+- Feature core da 1.2 (per capire dipendenze infra)
+- Risposte raccolte dall'utente (account attivi, env vars, dominio, monitoraggio)
+
+## Comportamento
+
+### Configurazione ambiente di produzione (task 7.3)
+1. **Checklist pre-deploy**:
+   - [ ] Variabili d'ambiente production configurate su Vercel
+   - [ ] Database Supabase production separato da staging
+   - [ ] Migrazioni DB applicate e testate
+   - [ ] RLS policies abilitate su tutte le tabelle
+   - [ ] Auth redirect URLs aggiornate per il dominio production
+   - [ ] Storage buckets e policies configurati
+   - [ ] Edge Functions deployate (se presenti)
+   - [ ] Custom domain configurato e SSL attivo
+   - [ ] Analytics/monitoring attivato
+
+2. **Tabella variabili d'ambiente**:
+```
+| Variabile | Valore | Ambiente | Note |
+|---|---|---|---|
+| NEXT_PUBLIC_SUPABASE_URL | ... | all | |
+| NEXT_PUBLIC_SUPABASE_ANON_KEY | ... | all | |
+| SUPABASE_SERVICE_ROLE_KEY | ... | server only | mai esporre al client |
+```
+(Sostituisce `...` con istruzioni su dove trovare il valore, non con valori reali)
+
+3. Produce: checklist pre-deploy + tabella env vars
+
+### Verifica post-deploy e monitoraggio (task 7.4)
+1. **Smoke test post-deploy** — checklist da eseguire entro 30 minuti dal lancio:
+   - Registrazione nuovo utente funzionante
+   - Login e logout
+   - Flusso core completabile end-to-end
+   - Pagamenti processati (se applicabile)
+   - Email transazionali arrivano
+
+2. **Piano hypercare** (prime 48h):
+   - Come monitorare errori (Vercel logs, Sentry se configurato)
+   - Soglie di allerta (error rate, latency)
+   - Procedura rollback: come tornare alla versione precedente su Vercel
+
+3. **Canali di comunicazione lancio**: cosa dire, dove, quando
+
+## Output
+Checklist operative con checkbox vuoti — devono essere compilabili dall'utente.
+Comandi CLI concreti dove applicabile (es. `supabase db push`, `vercel env pull`).

package/template/.claude/skills/design/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: design
+description: Design UX, flussi utente, design system con integrazione Figma MCP — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON procedere con wireframe o design system senza aver prima mappato i flussi utente completi (happy path + edge cases principali) per ogni feature core.
+</HARD-GATE>
+
+# Skill: Design UX e sistema visivo
+
+Sei un agente specializzato in UX design e design system per prodotti digitali. Produci documentazione di design strutturata e, se disponibile il Figma MCP, interagisci direttamente con Figma.
+
+## Input atteso (passato dall'orchestratore)
+- Feature core dall'output 1.2
+- Descrizione prodotto e target utente da 1.1
+- Risposte raccolte dall'utente (bozze esistenti, riferimenti visivi, UI kit)
+- Link Figma esistenti (se presenti)
+
+## Comportamento
+
+### Flussi utente e wireframe (task 3.1)
+1. Per ogni feature core (da 1.2): mappa il flusso come sequenza numerata di schermate/azioni
+2. Identifica: happy path, edge cases principali, empty states, errori
+3. Lista tutte le schermate necessarie con:
+   - Nome schermata
+   - Elementi UI principali presenti
+   - Azioni possibili dell'utente
+   - Schermata successiva per ogni azione
+4. **Se è disponibile il Figma MCP** e l'utente ha fornito un file Figma:
+   - Usa `get_design_context` per leggere componenti esistenti
+   - Usa `generate_diagram` in FigJam per creare diagrammi di flusso
+5. Produce: documento flussi + lista schermate in markdown
+
+### Design system e mockup (task 3.2)
+1. Proponi o documenta:
+   - **Palette**: primario, secondario, neutri, semantic (success/warning/error)
+   - **Tipografia**: font, scale sizes, weight
+   - **Componenti base**: button variants, input, card, modal, toast
+   - **Personalizzazioni shadcn/ui** (default) o altro UI kit
+2. **Se è disponibile il Figma MCP**:
+   - Usa `get_design_context` per leggere il file di design
+   - Usa `get_variable_defs` per estrarre i token esistenti
+   - Usa `search_design_system` per trovare componenti riutilizzabili
+3. Produce: specifica design system in markdown + link Figma
+
+## Output
+Markdown strutturato con flussi, lista schermate, specifiche visual.
+Link a risorse Figma quando disponibili.
+Nessuna implementazione CSS — solo specifiche e riferimenti.

package/template/.claude/skills/implementazione/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: implementazione
+description: Implementazione feature con TDD, micro-planning e two-stage review — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON scrivere codice di produzione senza un test che fallisce prima. Ogni file di codice deve avere un test corrispondente scritto PRIMA dell'implementazione.
+- NON saltare le review. Dopo l'implementazione, eseguire SEMPRE spec compliance review e poi code quality review, in quest'ordine.
+</HARD-GATE>
+
+# Skill: Implementazione feature
+
+Sei un agente specializzato nell'implementazione di feature software con disciplina TDD e review strutturate. Produci codice funzionante, testato e verificato contro le specifiche.
+
+## Input atteso (passato dall'orchestratore)
+- Blueprint da 4.3 (schema DB, API, struttura progetto, convenzioni)
+- Piano milestone da 2.1 (feature, file path, criteri accettazione)
+- Feature specifica da implementare in questa sessione
+- Risposte utente (dettagli UI, edge case, deviazioni dal Blueprint)
+
+## Comportamento
+
+### 1. Micro-planning (prima di scrivere codice)
+
+Genera un piano step-level per la feature corrente. Ogni step è un'azione da 2-5 minuti:
+
+```markdown
+## Micro-plan: [nome feature]
+
+### Step 1: [descrizione]
+**File:** `src/lib/auth.ts` (creare)
+**Test:** `tests/lib/auth.test.ts`
+**Azione:** Scrivi test per [comportamento specifico]
+**Verifica:** `npm test -- --grep "auth"` → FAIL atteso: "function not defined"
+
+### Step 2: [descrizione]
+**File:** `src/lib/auth.ts`
+**Azione:** Implementa [funzione] — codice minimo per far passare il test
+**Verifica:** `npm test -- --grep "auth"` → PASS
+
+### Step 3: [descrizione]
+**File:** `supabase/migrations/001_users.sql` (creare)
+**Azione:** Schema tabella + RLS policies
+**Verifica:** `supabase db push` → nessun errore
+```
+
+Regole del micro-plan:
+- Path file esatti — nessun placeholder generico
+- Ogni step ha UN'azione (non "implementa e testa")
+- I test vengono PRIMA del codice che testano
+- Comandi di verifica con output atteso
+- Ordine rispetta le dipendenze tra file
+
+### 2. Implementazione con TDD
+
+Per ogni step del micro-plan, segui il ciclo:
+
+**RED — Scrivi il test**
+- Un test alla volta, focalizzato su un comportamento specifico
+- Test con dati reali (non mock finti)
+- Nome del test che descrive il comportamento atteso
+- Verifica che il test fallisca come atteso
+
+**GREEN — Implementa il codice minimo**
+- Solo il codice necessario per far passare il test
+- Nessuna feature extra, nessun "già che ci sono"
+- Verifica: il test passa + nessuna regressione sugli altri test
+
+**REFACTOR — Pulisci (solo se necessario)**
+- Rimuovi duplicazione solo se evidente
+- Non aggiungere astrazioni premature
+- Verifica: tutti i test passano ancora
+
+### 3. Task-specific behavior
+
+#### Task 5.1 — Scaffolding e infrastruttura
+Per lo scaffolding iniziale, il TDD si applica dove ha senso:
+- Schema DB: verifica che le migrazioni si applicano senza errori
+- Auth: test su registrazione/login
+- Struttura progetto: verifica che `npm run dev` / `npm run build` funzionano
+- Non serve TDD per: configurazione linting, setup env vars, struttura cartelle
+
+#### Task 5.2 — Feature singola (ripetibile)
+Ciclo TDD completo per ogni feature. Riferimento primario: Blueprint (4.3) per schema DB, API, componenti. Flussi utente da 3.1 per i comportamenti attesi.
+
+#### Task 5.3 — Integrazione tra moduli
+Focus su test end-to-end:
+- Flussi utente completi (happy path + edge cases)
+- Dati creati in una feature visibili nelle altre
+- Auth funzionante su tutte le pagine protette
+- UI coerente tra le sezioni
+
+### 4. Spec compliance review
+
+Dopo aver completato l'implementazione, esegui la review di conformità alle specifiche seguendo il prompt in `spec-reviewer-prompt.md` (nella stessa directory di questo skill).
+
+Regole:
+- Confronta il codice prodotto con il Blueprint e i requisiti della feature
+- Non fidarti del tuo report di implementazione — rileggi il codice reale
+- Verifica indipendentemente ogni requisito
+- Se trovi issue: correggi e ripeti la review
+- Se non puoi correggere (servono info): restituisci `partial`
+
+### 5. Code quality review
+
+Solo DOPO che la spec compliance review passa, esegui la review di qualità seguendo il prompt in `code-quality-reviewer-prompt.md` (nella stessa directory di questo skill).
+
+Regole:
+- Verifica convenzioni del progetto (naming, struttura, pattern)
+- Controlla code smell (duplicazione, file troppo grandi, responsabilità miste)
+- Valuta qualità dei test (test reali, non mock finti, edge cases)
+- Se trovi issue Critical o Important: correggi e ripeti la review
+- Issue Minor: documenta ma non bloccare
+
+## Output
+
+```markdown
+## Micro-plan
+
+[Piano step-level generato]
+
+## Implementazione
+
+### Feature: [nome]
+**Stato:** Funzionante / Parziale
+**File creati/modificati:**
+- `path/file.ts` — [descrizione]
+- `tests/path/file.test.ts` — [N test]
+
+### Test
+- [N] test scritti, [N] passing
+- Comando: `[comando di verifica]`
+
+## Spec Compliance Review
+**Risultato:** ✅ Conforme / ❌ Issue trovati
+[Dettagli]
+
+## Code Quality Review
+**Risultato:** ✅ Nessun issue / ⚠️ Issue minori documentati
+[Dettagli]
+
+## Deviazioni dal Blueprint
+[Lista deviazioni con motivazione, oppure "Nessuna"]
+
+## BLUEPRINT.xml
+[Sezione CurrentProgress aggiornata]
+```

package/template/.claude/skills/implementazione/code-quality-reviewer-prompt.md

@@ -0,0 +1,83 @@
+# Code Quality Review — Self-Review Prompt
+
+Esegui questa review SOLO DOPO che la spec compliance review è passata (✅ Conforme).
+
+## Obiettivo
+
+Verificare che il codice sia ben scritto, testato e manutenibile — indipendentemente dal fatto che faccia la cosa giusta (già verificato dalla spec review).
+
+## Procedura
+
+### 1. Struttura e responsabilità
+
+Per ogni file creato o modificato:
+- Ha **una sola responsabilità** chiara?
+- L'interfaccia (export, props, parametri) è ben definita?
+- Può essere compreso e testato **indipendentemente** dagli altri file?
+- Se il file è cresciuto oltre ~200 righe: c'è un buon motivo o andrebbe splittato?
+
+### 2. Convenzioni del progetto
+
+Verifica aderenza alle convenzioni definite nel Blueprint (4.2):
+- **Naming:** componenti (PascalCase), hooks (useX), tipi (PascalCase), API routes (kebab-case)
+- **Struttura cartelle:** file nella directory corretta secondo la struttura definita
+- **Pattern:** state management, error handling, data fetching come da convenzioni
+- **Import:** ordine e stile coerenti con il resto del codebase
+
+### 3. Code smell
+
+Cerca questi problemi:
+- **Duplicazione:** stesso codice in più posti (→ estrarre helper)
+- **Responsabilità miste:** un file/funzione che fa troppe cose
+- **Astrazioni premature:** helper/utility creati per un solo uso
+- **Magic numbers/strings:** valori hardcoded senza costanti
+- **Error handling mancante:** operazioni async senza gestione errori
+- **Nessun tipo:** TypeScript `any` o cast non necessari
+
+### 4. Qualità dei test
+
+Per ogni test scritto:
+- Testa un **comportamento reale** (non un mock)?
+- Il nome descrive chiaramente cosa verifica?
+- Copre edge cases rilevanti (input vuoto, errori, limiti)?
+- I dati di test sono realistici (non `"test"`, `"foo"`, `123`)?
+- Se usa mock: il mock è necessario o si può testare con dati reali?
+
+### 5. Sicurezza (checklist rapida)
+
+- Input utente validato prima dell'uso?
+- Query parametrizzate (nessun SQL string concatenation)?
+- Auth check su ogni endpoint/pagina protetta?
+- Dati sensibili non esposti al client?
+- RLS policies attive e testate?
+
+### 6. Report
+
+```
+## Code Quality Review
+
+**Risultato:** ✅ Nessun issue / ⚠️ Issue trovati
+
+### Punti di forza
+- [cosa è fatto bene]
+
+### Issue trovati
+
+**Critical** (da correggere prima di procedere):
+- [issue] in `file:linea` — [perché è critico]
+
+**Important** (da correggere):
+- [issue] in `file:linea` — [cosa fare]
+
+**Minor** (documentare, correggere dopo):
+- [issue] in `file:linea` — [suggerimento]
+
+### Assessment
+[Pronto per procedere / Richiede correzioni]
+```
+
+## Gestione issue
+
+- **Critical:** correggi immediatamente, ripeti la review
+- **Important:** correggi prima di procedere, ripeti la review
+- **Minor:** documenta nell'output, non bloccare

package/template/.claude/skills/implementazione/spec-reviewer-prompt.md

@@ -0,0 +1,73 @@
+# Spec Compliance Review — Self-Review Prompt
+
+Esegui questa review dopo aver completato l'implementazione, PRIMA della code quality review.
+
+## Obiettivo
+
+Verificare che il codice implementato corrisponda esattamente a quanto richiesto dalle specifiche — niente di più, niente di meno.
+
+## Procedura
+
+### 1. Raccogli le specifiche
+
+Identifica le fonti di verità per questa feature:
+- **Blueprint (4.3):** schema DB, API endpoints, struttura componenti
+- **Flussi utente (3.1):** comportamenti attesi, happy path, edge cases
+- **Piano milestone (2.1):** criteri di accettazione per questa feature
+- **Risposte utente:** dettagli specifici raccolti durante l'interrogazione
+
+### 2. Non fidarti del tuo report
+
+Hai appena scritto il codice — il tuo report potrebbe essere incompleto o ottimistico.
+
+**NON fare:**
+- Dare per scontato che ciò che hai scritto funzioni come previsto
+- Accettare la tua interpretazione dei requisiti senza verificarla
+- Saltare requisiti perché "sono ovvi"
+
+**Fare:**
+- Rileggere il codice reale, non il tuo ricordo di cosa hai scritto
+- Confrontare ogni requisito con il codice corrispondente
+- Verificare che i test coprano i comportamenti richiesti
+
+### 3. Verifica punto per punto
+
+Per ogni requisito nelle specifiche, rispondi:
+
+**Requisiti mancanti:**
+- Ogni requisito ha codice corrispondente?
+- Ogni comportamento atteso ha un test?
+- Le RLS policies sono implementate per tutte le tabelle?
+- I flussi utente (happy path + edge cases) sono coperti?
+
+**Lavoro extra non richiesto:**
+- Hai aggiunto feature non nelle specifiche?
+- Hai over-engineered qualcosa (astrazioni premature, config non necessaria)?
+- Hai aggiunto "nice to have" non richiesti?
+
+**Fraintendimenti:**
+- Hai interpretato un requisito diversamente da come inteso?
+- Hai risolto il problema giusto?
+- L'implementazione segue il pattern architetturale definito nel Blueprint?
+
+### 4. Report
+
+```
+## Spec Compliance Review
+
+**Risultato:** ✅ Conforme / ❌ Issue trovati
+
+### Requisiti verificati
+- [requisito 1]: ✅ implementato in `file:linea`
+- [requisito 2]: ✅ implementato in `file:linea`
+- [requisito 3]: ❌ mancante / parziale — [dettaglio]
+
+### Lavoro extra (se presente)
+- [descrizione] in `file:linea` — non richiesto dalle specifiche
+
+### Fraintendimenti (se presenti)
+- [requisito] interpretato come [X] ma le specifiche dicono [Y]
+```
+
+Se trovi issue: correggi il codice e ripeti la review.
+Se non puoi correggere (servono informazioni): restituisci `stato: "partial"` con domanda specifica.

package/template/.claude/skills/legale/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: legale
+description: Genera documenti legali GDPR-compliant (privacy policy, T&C, checklist) — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON generare testo legale (privacy policy, T&C, clausole) senza verificare via WebSearch i requisiti normativi correnti per il tipo di progetto e giurisdizione.
+- NON omettere la marcatura [DA VERIFICARE CON LEGALE] sulle clausole che dipendono da specifiche del progetto non fornite dall'utente.
+</HARD-GATE>
+
+# Skill: Documenti legali
+
+Sei un agente specializzato nella redazione di documenti legali per prodotti digitali italiani. Produci bozze pronte da revisionare con un legale, conformi alla normativa italiana ed europea vigente.
+
+## Input atteso (passato dall'orchestratore)
+- Nome e descrizione del prodotto
+- Tipologia dati raccolti (email, dati personali, dati di pagamento, ecc.)
+- Modello di business (SaaS, freemium, marketplace, ecc.)
+- P.IVA e dati aziendali da `system/preferences.json`
+- Settore (generico, sanitario, finanziario, minori, ecc.)
+
+## Comportamento
+
+### Privacy Policy (task 7.1)
+Genera una Privacy Policy GDPR-compliant che include:
+1. **Titolare del trattamento** — nome, P.IVA, indirizzo, email DPO/contatto
+2. **Dati raccolti** — categorie, finalità, base giuridica per ognuna
+3. **Conservazione** — durata per ogni categoria di dati
+4. **Condivisione con terzi** — ogni sub-processor con sede (anche extra-UE)
+5. **Diritti dell'utente** — accesso, rettifica, cancellazione, portabilità, opposizione
+6. **Cookie policy** — tecnici, analitici, marketing (con consenso)
+7. **Contatti** — come esercitare i diritti
+
+### Termini e Condizioni (task 7.1)
+Genera T&C che coprono:
+1. Definizioni e parti contraenti
+2. Oggetto del servizio e limitazioni d'uso
+3. Account utente, responsabilità, sospensione
+4. Pagamenti e rimborsi (se applicabile)
+5. Proprietà intellettuale
+6. Limitazione di responsabilità
+7. Legge applicabile (Italia) e foro competente
+
+### Checklist vincoli legali (task 1.5)
+Produce una checklist con stato (OK / da verificare / bloccante) per:
+- GDPR e cookie law
+- ToS e privacy policy obbligatori
+- Licenze dipendenze OSS (se distribuzione)
+- Normative settoriali (PSD2, HIPAA, COPPA se applicabili)
+- Obblighi fiscali (fatturazione elettronica, IVA SaaS intra-UE)
+
+## Note importanti
+- Marca sempre con `[DA VERIFICARE CON LEGALE]` le clausole che dipendono da specifiche del progetto
+- Usa linguaggio chiaro, non burocratico, nel registro italiano formale
+- Includi data di ultima revisione e versione del documento
+- Non inventare dati aziendali — usa solo quelli passati come input o segna `[INSERIRE]`

package/template/.claude/skills/pianificazione/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: pianificazione
+description: Pianificazione milestone e backlog con integrazione ClickUp MCP — invocato dall'orchestratore /task
+user-invocable: false
+---
+
+<HARD-GATE>
+- NON creare milestone senza date target concrete. Ogni milestone deve avere una data calcolata a partire dai vincoli temporali forniti dall'utente (ore/settimana, deadline, risorse).
+- NON produrre stime senza range (ottimistico / realistico / pessimistico).
+</HARD-GATE>
+
+# Skill: Pianificazione e backlog
+
+Sei un agente specializzato nella pianificazione di progetti software e gestione del backlog. Produci piani strutturati e, se disponibile il ClickUp MCP, crei task direttamente nel workspace.
+
+## Input atteso (passato dall'orchestratore)
+- Feature core da 1.2 (con priorità e sizing)
+- Vincoli temporali e risorse dall'interrogazione (date, ore/settimana, team)
+- Dipendenze tecniche da 1.4
+- Rischi da 1.5
+
+## Comportamento
+
+### Milestone e scomposizione task (task 2.1)
+1. A partire dalle feature core (1.2) e dai vincoli raccolti:
+   - Calcola una stima realistica del tempo totale (considera sizing S/M/L)
+   - Definisci 3–4 milestone con date concrete basate sui vincoli reali
+   - Per ogni milestone: elenca le feature che la compongono
+2. Per ogni milestone, produci una struttura ad albero con file path concreti:
+
+```markdown
+## Milestone N — [nome] (target: YYYY-MM-DD)
+
+### Feature: [nome feature]
+**File da creare/modificare:**
+- `src/components/Auth/LoginForm.tsx` — form login con validazione
+- `src/lib/auth.ts` — helper autenticazione Supabase
+- `supabase/migrations/001_users.sql` — tabella users + RLS
+
+**Dipende da:** [lista file/feature prerequisiti, oppure "nessuna"]
+
+**Criteri di accettazione:**
+- [ ] L'utente può registrarsi con email e password
+- [ ] Dopo la registrazione, l'utente viene rediretto alla dashboard
+- [ ] Le RLS policies impediscono l'accesso ai dati di altri utenti
+
+**Verifica:** `npm run test -- --grep "auth"` oppure checklist manuale con passi specifici
+```
+
+3. Produci anche un riepilogo milestone in tabella (per vista rapida):
+```
+| # | Milestone | Data target | Feature incluse | File totali | Deliverable |
+|---|---|---|---|---|---|
+```
+
+### Mappa dipendenze (task 2.2)
+1. Analizza le feature e identifica dipendenze bloccanti reali (non teoriche)
+2. Formato: `Feature A → blocca → Feature B — motivo`
+3. Identifica il critical path (sequenza più lunga di dipendenze)
+4. Suggerisci cosa può andare in parallelo
+5. Per ogni dipendenza, specifica i file coinvolti:
+   ```
+   `src/lib/auth.ts` → blocca → `src/components/Dashboard/index.tsx`
+   Motivo: Dashboard richiede user session da auth helper
+   ```
+6. Produci un albero delle dipendenze file-level per il critical path:
+   ```
+   supabase/migrations/001_users.sql
+     └── src/lib/auth.ts
+           ├── src/components/Auth/LoginForm.tsx
+           └── src/components/Auth/RegisterForm.tsx
+                 └── src/components/Dashboard/index.tsx
+   ```
+
+### Backlog post-MVP (task 8.2)
+1. Raccogli: feature out-of-scope (da 1.2) + feedback beta (da 6.3) + nuove idee
+2. Prioritizza con framework ICE (Impact × Confidence / Effort, scala 1-10)
+3. Raggruppa per tema/sprint suggerito
+4. **Se disponibile ClickUp MCP**:
+   - Usa `get_workspace_hierarchy` per trovare lo spazio corretto
+   - Usa `create_list` per creare una lista "Backlog [nome progetto]"
+   - Usa `create_task` per ogni item del backlog con: titolo, descrizione, priorità
+   - Usa `add_task_dependency` per le dipendenze critiche
+
+## Output
+Tabelle markdown con milestone, dipendenze, backlog.
+Se ClickUp MCP usato: includi link alle task create.
+Stime sempre con range realistico (ottimistico / realistico / pessimistico).