Prima viene la spec.E la leggi prima del codice.

Il ciclo: spec, revisione, piano, revisione, attività, build

Invece di un grande prompt e una pila di codice, il lavoro passa per documenti, ognuno controllato da te prima che venga scritto il successivo.

1. Spec: cosa e perché

   Cosa deve fare la funzione, per chi e cosa non deve fare. Ancora niente nomi di file né scelte tecnologiche.

2. Piano: come

   L’approccio: quali parti cambiano, in che ordine, con quali rischi. Il piano risponde alla spec.

3. Attività: piccoli passi

   Una checklist che l’agente può percorrere e spuntare, ogni attività abbastanza piccola da poterla verificare.

4. Build

   Solo ora l’agente scrive codice, a partire da documenti che hai già letto.

Un breve modello di spec

Una spec non deve essere lunga. Bastano sei titoli per cogliere la maggior parte dei malintesi:

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals e Open questions sono quelli che le persone saltano e di cui gli agenti hanno più bisogno. Un agente a cui si dice cosa non costruire, e cosa è ancora da decidere, chiede invece di indovinare.

Farlo in Claude Code, Codex e Cursor

Tutti e tre possono scrivere i documenti, e ognuno ha un plan mode per il passo di pianificazione: plan mode di Claude Code, plan mode di Codex e plan mode di Cursor.

Per rendere automatico il passo di revisione, metti una regola in CLAUDE.md o AGENTS.md: dopo aver scritto una spec o un piano, mandalo a te con request_review in DotMD e aspetta. L’agente si ferma allora dopo ogni documento e aspetta i tuoi commenti o la tua approvazione, senza usare token mentre aspetta. DotMD può aggiungere la regola per te: vedi CLAUDE.md e AGENTS.md.

Una revisione che regge

La chat è un brutto posto per rivedere un documento. Leggi invece la spec renderizzata in DotMD, selezioni il passaggio sbagliato e premi ⌥⌘M. Il commento è legato alle sue righe, quindi l’agente sa esattamente cosa intendi. Puoi scrivere prima tutti i commenti e inviarli una volta sola.

Quando l’agente li ha corretti, ogni modifica è mostrata nel file: testo vecchio in rosso, testo nuovo in verde, accanto al commento a cui risponde. Accept o Reopen per ciascuna. DotMD elenca anche le modifiche che nessuno ha chiesto. Vedi Rivedere le modifiche.

Per un secondo parere, lascia che un altro agente riveda per primo. Una spec scritta da Claude Code e commentata da Codex ti arriva con le lacune evidenti già segnate, e decidi tu quali osservazioni arrivano a chi l’ha scritta: Un agente rivede l’altro.

Strumenti per lo sviluppo guidato dalle spec

• Semplice Markdown nel repo. Una cartella docs/specs e il modello qui sopra sono una configurazione completa.
• I plan mode. Il modo di ogni agente di pianificare prima di costruire.
• GitHub Spec Kit. Un toolkit open source che dà al tuo agente comandi per ogni passo e scrive per te spec.md, plan.md e tasks.md: GitHub Spec Kit.

Qualunque cosa scegli, i documenti sono file Markdown, e DotMD li legge tutti.

Domande sullo sviluppo guidato dalle spec

Altre domande