---
name: piano
description: Piano implementativo — spezza un lavoro complesso in task bite-sized con percorsi esatti, comandi e verifiche. Ogni task 2-5 minuti.
---

# /piano — Piano implementativo

Questo skill crea un piano implementativo strutturato per lavori complessi. Ogni task e bite-sized (2-5 minuti), con percorsi esatti, comandi e verifiche.

Protocollo esecutivo assorbito da Superpowers (writing-plans, Jesse Vincent) con integrazione nel ciclo Curiosa.

## Istruzioni

### Quando usare /piano

- Il lavoro tocca 3+ file
- La logica non e banale
- Serve una sequenza precisa di passi
- /brainstorm ha prodotto un design approvato

Non usare /piano per lavori semplici (1-2 file, logica chiara). In quel caso, procedi direttamente.

### Fase 1 — Scope check

Leggi `vincoli_sessione.md` — oggetto, output atteso, vincoli.

Se il lavoro coinvolge sottosistemi indipendenti: spezza in piani separati. Un piano = un sottosistema coerente.

### Fase 2 — Analisi codebase

Esplora il codebase per capire:
- Struttura file esistente (pattern, convenzioni)
- Dipendenze tra i file coinvolti
- Test esistenti (dove sono, come si eseguono)
- Ordine naturale di implementazione (cosa dipende da cosa)

### Fase 3 — Costruzione piano

Per ogni task nel piano:

```
### Task N: [titolo descrittivo]

**File coinvolti:** [percorsi esatti]

**Passi:**
- [ ] Scrivi test che fallisce: [descrizione test, file, cosa verifica]
- [ ] Verifica fallimento: `[comando test]` — atteso: [errore specifico]
- [ ] Scrivi codice minimo: [cosa fare, in quale file, dove]
- [ ] Verifica passaggio: `[comando test]` — atteso: tutti verdi
- [ ] Commit: `[messaggio commit]`

**Verifica task:** `[comando]` — atteso: [output]
```

Regole per i task:
- **2-5 minuti ciascuno** — se un task e piu lungo, spezzalo
- **Percorsi esatti** — nessun "nel file appropriato", sempre il percorso completo
- **Comandi esatti** — nessun "esegui i test", sempre il comando specifico
- **Output atteso** — nessun "dovrebbe funzionare", sempre cosa ti aspetti di vedere
- **Un commit per task** — ogni task e un'unita atomica

### Fase 4 — Review del piano

Prima di presentare all'utente, verifica:
- Ogni task ha test (se /tdd e attivo o applicabile)
- L'ordine rispetta le dipendenze
- Nessun task tocca file off limits (da vincoli_sessione.md)
- Il piano copre l'intero scope (confronta con oggetto e output atteso)

### Fase 5 — Presentazione e approvazione

Presenta il piano all'utente. Formato:

```
Piano: [titolo]
Scope: [oggetto da vincoli_sessione.md]
Task: N
Tempo stimato: [N * 2-5 min]

[lista task con checkbox]
```

Chiedi: **"Il piano ti torna? Vuoi modificare qualcosa?"**

- Se approvato: il piano e pronto per l'esecuzione. Suggerisci: "Procedo con il Task 1?"
- Se modifiche richieste: itera
- Se l'utente vuole rivedere il design: torna a `/brainstorm`

### Fase 6 — Esecuzione (opzionale, se l'utente procede)

Se l'utente approva e dice di procedere, esegui i task in sequenza:

1. Per ogni task: annuncia "Task N: [titolo]"
2. Segui i passi esattamente come scritti
3. Se /tdd e attivo: il ciclo red-green-refactor si applica ad ogni task
4. Dopo ogni task completato: spunta il checkbox, annuncia "Task N completato"
5. Dopo ogni 3 task completati: il dispatcher puo attivare `/review` intermedio (dalla tabella segnali)

Se un task fallisce: non saltare al successivo. Applica `/debug` se e un bug tecnico, `/sblocca` se e un blocco cognitivo.

## Lente cognitiva

Bias sotto sorveglianza durante /piano:
- `compressione`: piano che sembra completo ma ha saltato passi
- `chiusura_anticipata`: piano che chiude troppo presto senza coprire tutti i requisiti
- `slittamento_referente`: piano che risponde a un problema leggermente diverso da quello in vincoli_sessione.md

Operatori attivi:
- `non_perderti_pezzi`: il piano deve coprire tutto lo scope, niente dimenticato silenziosamente
- `fissa_oggetto_e_vincoli`: confronta ogni task con l'oggetto originale

## Tabella razionalizzazioni

| Scusa | Realta |
|-------|--------|
| "Non serve un piano, e chiaro" | Se tocca 3+ file, serve un piano. La chiarezza in testa non sopravvive alla complessita. |
| "Il piano rallenta" | Il piano accelera. Senza piano, i task si scoprono durante l'implementazione. |
| "Faccio il piano nella mia testa" | Il piano nella testa non ha percorsi esatti, comandi, output attesi. Non e verificabile. |
| "Basta una lista di todo" | Un todo non ha dipendenze, comandi, verifiche. Non e un piano. |

## Gate di uscita

Piano approvato dall'utente. Ogni task ha file, passi, comandi e verifiche. Lo scope e coperto.