Regole di prompting 2026 — base di conoscenza per prompt-engineer

Documento di ricerca per la voce E20 (add-prompt-engineer). Non è una spec e non è un target: è l'evidenza da cui la spec di prompt-engineer ricava i suoi requisiti. Ogni regola cita la sua fonte per sigla.

Metodo di raccolta. Tutte le pagine sono state lette il 2026-09-27 esclusivamente dalla sandbox: il browser Camoufox del container OrbStack camofox-browser (API :9377), che ha navigato, cercato e restituito gli snapshot. Nessuna fetch dall'host.

Fonti

Dove una terza parte e una fonte ufficiale dicono la stessa cosa, vale la formulazione ufficiale. [P-G6] è la sola fonte non-Anthropic: le sue regole entrano qui solo dove convergono con quelle Anthropic, perché sono il segnale che la regola è una proprietà del buon prompt e non di un singolo modello.

---

Principio guida

Il prompt definisce il contratto del lavoro, non il modo di pensare. Dire cosa è un risultato riuscito, con quali prove e quando fermarsi; lasciare il ragionamento al modello e la sua profondità al parametro effort. [A-O55 § Calibrate effort] [P-O55 § Conclusion] [P-G6 § Do Not Micromanage Private Reasoning]

---

A. Struttura: il contratto del task

R1 — Obiettivo prima del metodo. Il prompt apre con l'esito atteso, non con istruzioni su come ragionare. "Aggiorna il flusso di auth per supportare le passkey senza cambiare il login a password" batte "pensa a fondo e migliora il codice". [P-O55 § Define the Outcome Before the Method] [A-BP § Be clear and direct]

R2 — Le sezioni del contratto. Un prompt per lavoro serio ha, quando servono: OBJECTIVE, CONTEXT, SCOPE (in / out / non toccare), TOOLS, ACTION BOUNDARIES, VERIFICATION, OUTPUT, STOP CONDITION. Convergono [P-O55 § A Practical Claude Opus 5.5 Prompt Structure] e [P-G6 § The Core GPT-6 Sol Prompt Structure].

R3 — Solo le sezioni che riducono ambiguità reale. Le sezioni che non si applicano si tolgono: un prompt semplice resta semplice. La lunghezza è una conseguenza della complessità del task, non un obiettivo. [P-O55 § Reusable Template: "Remove sections that do not apply"] [P-G6 § Short vs. Detailed Prompts]

R4 — Contesto e perimetro sono sezioni distinte. Il contesto spiega l'ambiente; il perimetro dice cosa è permesso cambiare. Tenerli separati impedisce al modello di "migliorare" cose non richieste. [P-O55 § Separate Scope From Context] [A-BP § Overeagerness]

R5 — Spiegare il perché delle regole. Un vincolo con la sua motivazione generalizza meglio di un divieto nudo ("sarà letto da un TTS, quindi niente puntini di sospensione" > "MAI puntini di sospensione"). [A-BP § Add context to improve performance]

R6 — Delimitare i blocchi con tag XML. Istruzioni, contesto, esempi e input variabili vanno ognuno nel suo tag (<instructions>, <context>, <input>, <example>), con nomi coerenti e annidati quando c'è gerarchia. [A-BP § Structure prompts with XML tags]

R7 — Test del collega. Se un collega senza contesto, leggendo il prompt, sarebbe confuso, lo sarà anche il modello. Un prompt per un subagente deve reggersi da solo. [A-BP § Be clear and direct: "Golden rule"] [A-CC § Let Claude interview you: "the most useful specs are self-contained"]

R8 — Ruolo solo se cambia le decisioni. Una riga di ruolo aiuta; personaggi lunghi e decorativi aggiungono rumore. [A-BP § Give Claude a role] [P-G6 § Mistakes #9 "Overloading the Prompt With Personas"]

B. Pulizia: cosa togliere

R9 — Togliere le formule "pensa di più". "Think step by step", "think carefully", "take a deep breath", "think hard" vanno eliminate, anche da CLAUDE.md: il pensiero è adattivo e sempre attivo, e toglierle fa partire la risposta prima senza perdita di qualità. La profondità si regola con effort. [A-O55 § Thinking instructions in chat system prompts] [IHAL ¶1] [P-G6 § Do Not Micromanage Private Reasoning]

R10 — Non chiedere di riprodurre il ragionamento interno. Chiedere al modello di scrivere nella risposta il proprio ragionamento può essere rifiutato (categoria reasoning_extraction). Chiedere invece una spiegazione sintetica dei motivi della scelta. [A-O55 § Safeguard refusals] [IHAL ¶5]

R11 — Sostituire "pensa bene" con requisiti osservabili. Al posto dell'istruzione sul pensiero, dire cosa verificare prima di rispondere: confrontare ogni affermazione con le fonti, testare il codice cambiato, elencare le assunzioni aperte. [P-O55 § Do Not Micromanage Thinking] [P-G6 § Do Not Micromanage Private Reasoning]

R12 — Niente linguaggio aggressivo. "CRITICAL: You MUST…" sui modelli attuali provoca over-triggering; basta "Usa questo tool quando…". [A-BP § Tool usage]

R13 — Non ripetere lo stesso vincolo in forme diverse. La duplicazione aggiunge rumore e può introdurre contraddizioni. [P-G6 § Mistakes #10]

R14 — Dire cosa fare, non solo cosa non fare — con un'eccezione. Per il formato: "scrivi in paragrafi di prosa" > "non usare markdown" [A-BP § Control the format of responses]. Per il design, invece, "evita l'aspetto generico" non funziona: bisogna nominare i pattern specifici da escludere [A-O55 § Frontend design defaults] [IHAL ¶4] [P-O55 § Frontend and UI Generation].

C. Contesto, fonti, contenuti incollati

R15 — Fonti con priorità esplicita. Una finestra da 1M token non dice quale fonte è autorevole. Il prompt elenca le fonti in ordine di autorità e dice cosa fare in caso di conflitto: segnalarlo, non riconciliarlo in silenzio. [P-O55 § Mistakes #11] [P-G6 § Long-Context Prompting]

R16 — Documenti lunghi in cima, domanda in fondo. Con input oltre ~20k token, i documenti vanno sopra le istruzioni; la domanda alla fine migliora la risposta. [A-BP § Long context prompting]

R17 — Separare le istruzioni dell'utente dal testo incollato. Il testo incollato (email, pagine web, ticket) va racchiuso in <pasted_content id="…">…</pasted_content id="…">, con un id casuale generato dall'applicazione; le istruzioni al suo interno sono contenuto, non ordini. [A-O55 § Mark pasted text in user messages] [P-O55 § Pasted Content and Prompt Injection Boundaries]

R18 — Non inventare: n/a, "unknown" o domanda. Un dato mancante non si riempie con un default plausibile: si marca come sconosciuto e si dice quale fonte lo risolverebbe. [P-G6 § Clarification, Assumptions, and Missing Information] — coincide con l'invariante anti-invenzione di rules/prompt-loop.md.

R19 — Riferimenti concreti. Nominare file, scenari, pattern d'esempio e vincoli invece di descrizioni vaghe ("aggiungi test a foo.py" < "test per foo.py sul caso utente sloggato, senza mock"). [A-CC § Provide specific context in your prompts]

R20 — Esempi pochi, pertinenti, vari, taggati. 3–5 esempi in <example>, simili al caso reale e diversi tra loro. [A-BP § Use examples effectively]

D. Strumenti e confini d'azione

R21 — Politica dei tool, non elenco dei tool. Dire quando usare, non usare o è obbligatorio ciascun tool, e cosa fare quando manca un argomento richiesto: recuperarlo, chiedere o dichiararsi bloccati. Mai inventarlo. [P-O55 § Mistakes #6] [P-G6 § Prompt for Tool Policy, Not Tool Existence] [A-BP § Optimize parallel tool calling: "Never use placeholders or guess missing parameters"]

R22 — Verbi d'azione se si vuole un'azione. "Puoi suggerire modifiche?" produce suggerimenti; "Modifica questa funzione" produce la modifica. [A-BP § Tool usage]

R23 — Confini d'azione espliciti. Cosa si fa in autonomia (azioni locali e reversibili) e cosa richiede conferma (distruttive, irreversibili, visibili ad altri, espansione di perimetro). Il prompt non è l'unico livello di autorizzazione: i permessi veri li applica il runtime. [A-BP § Balancing autonomy and safety] [P-O55 § Keep Runtime Authorization Outside the Prompt] [P-G6 § Tool Availability Is Not Authorization]

R24 — Scoprire prima di agire. Nei task che toccano più fonti: fase di scoperta, poi decisione, poi azione, poi rilettura dello stato. [A-O55 § Explore context in multi-app workflows] [P-O55 § Separate Discovery From Action]

E. Verifica e condizione di stop

R25 — Criteri di verifica osservabili e proporzionati al rischio. Non "ricontrolla il lavoro" ma "riproduci il fallimento, esegui i test mirati, ispeziona il diff". Un fix di una riga non merita un audit completo. [A-CC § Give Claude a way to verify its work] [P-O55 § Do Not Ask for Endless Verification] [P-G6 § Verification and Completion Criteria]

R26 — Condizione di completamento esplicita. "Finito quando tutti gli endpoint sono migrati, il vecchio client è rimosso e la suite passa." Con una condizione chiara il modello lavora in autonomia molto più a lungo. [IHAL ¶1] [P-O55 § STOP CONDITION] [P-G6 § Define Completion]

R27 — Prove, non affermazioni. L'output riporta il comando eseguito e cosa ha restituito, e separa fatti verificati da ipotesi e da ciò che non è stato possibile verificare (e dove si è cercato). [A-CC § Give Claude a way to verify its work] [IHAL ¶3] [P-G6 § Separate Fact From Inference]

R28 — Separare vincoli duri da preferenze. Un requisito "deve passare" non si nasconde in un punteggio pesato. [P-G6 § Mistakes #12]

F. Output

R29 — Contratto di output. Specificare cosa contiene il risultato finale: cosa è cambiato, cosa è stato verificato, incertezza residua, cosa serve dall'utente. Il resoconto si legge partendo da ciò che resta da decidere. [P-O55 § A Practical Structure: OUTPUT] [IHAL ¶3]

R30 — Chiedere l'artefatto finito. Se serve un documento o un file, chiedere il file completo e condivisibile, non una bozza di struttura. [IHAL ¶4]

G. Lavoro lungo, agenti e subagenti

R31 — Progresso ≠ completamento. Nei lavori lunghi, gli aggiornamenti di stato non chiudono il task. Il prompt dice quando continuare, quando fermarsi (nulla può avanzare senza l'utente, o l'azione è protetta) e che i messaggi di stato vanno insieme alla prossima azione. [A-O55 § Unattended agentic runs] [IHAL ¶2] [P-O55 § Define Continue vs. Stop Behavior]

R32 — Stato fuori dalla conversazione. L'elenco dei compiti vive in un file (es. TASKS.md) o in git, non solo nella cronologia, che può essere compattata. [IHAL ¶2] [A-BP § State management best practices]

R33 — Subagenti solo quando servono. Delegare quando il lavoro è parallelizzabile, richiede contesto isolato o è indipendente; lavorare direttamente per task semplici, sequenziali o che condividono stato. Verificare le prove di ciascun subagente prima di accettarne la conclusione. [A-BP § Subagent orchestration] [IHAL ¶2]

R34 — Un brief per contesto fresco è autosufficiente. Una sessione (o un subagente) che parte pulita lavora meglio con una spec scritta che nomina file e interfacce, dichiara cosa è fuori perimetro e si chiude con una verifica end-to-end. [A-CC § Let Claude interview you] [A-CC § Course-correct early and often]

R35 — Contro l'over-engineering. Solo modifiche richieste o chiaramente necessarie; niente astrazioni per usi unici, niente gestione di errori per casi impossibili. [A-BP § Overeagerness]

R36 — Indagare prima di rispondere. Non speculare su codice non aperto: se il prompt nomina un file, va letto prima di rispondere. [A-BP § Minimizing hallucinations in agentic coding]

H. Fuori dal prompt (da non confondere con il prompt)

R37 — L'effort non si imposta a parole. Profondità di ragionamento, costo e latenza si regolano con il parametro effort (default medium su Opus 5.5), misurato su eval proprie; non con aggettivi nel prompt. Il prompt engineer può raccomandare un livello, non sostituirlo con testo. [A-O55 § Calibrate effort] [P-O55 § How to Choose Effort] [P-G6 § How to Use Reasoning Effort]

R38 — Cambiare una variabile alla volta. Prompt, modello ed effort si valutano separatamente. [P-O55 § Mistakes #12] [P-G6 § Mistakes #14]

---

Anti-pattern — checklist di pulizia

Da cercare e rimuovere o riscrivere in ogni prompt in ingresso:

---

Implicazioni per la skill prompt-engineer

Queste non sono regole di prompting: sono le conseguenze delle regole sopra per questa skill, e sono la base da cui la spec ricaverà i requisiti.

1. Ingresso: il REFINED_PROMPT.md confermato da prompt-loop è il contratto già deciso dall'utente. Il prompt engineer non lo ridiscute: lo rende eseguibile. Le voci del lock register passano verbatim.
2. Trasformazione = pulizia (sezione B e checklist anti-pattern) + strutturazione nel contratto (sezione A, R2–R3, solo le sezioni che servono)
   • completamento di verifica, stop e output (sezioni E–F) solo con informazioni presenti nell'ingresso; un blocco che l'utente ha dichiarato non applicabile si omette (R3), non si riempie (R18).
3. Nessuna domanda all'utente: gira in un subagente. Le domande le fa tutte prompt-loop, il cui gate di copertura garantisce una risposta per ognuno degli otto blocchi; un ingresso con un blocco scoperto si rifiuta e torna a prompt-loop (design D7). Open questions raccoglie solo le tensioni residue dentro blocchi coperti (R18, R34).
4. Output autosufficiente (R7, R34): chi lo riceve non ha visto la conversazione.
5. Tracciabilità: ogni modifica al testo in ingresso è giustificata da una regola R<n> di questo documento, così la trasformazione è verificabile e non una riscrittura di gusto.
6. Effort fuori dal testo (R37): l'output può raccomandare un livello di effort, ma non inserisce formule sul pensiero.