01 START HERE · MAP

Overview — how the pieces fit

Prometheus is a prompt-engineering skill for coding agents — and more. Describe what you need and it designs a structured, audited prompt, workflow, or self-adaptive agent, shipped with a verifier.

Prometheus is a build-time framework for designing, auditing, and refactoring prompts for tool-calling agents. It reads a task, picks a mode, and runs an ordered pipeline that draws on shared catalogs and ships the prompt with a verifier. Everything below is a map.

The architecture & workflow

Read the map in five moves

1 · The router. SKILL.md is the one file always in context. It reads the request and selects a mode; it also carries the from-scratch procedure itself. Nothing else is read until a phase pulls it in.

2 · Two modes (plus manage). From-scratch designs a new prompt; refactor repairs one you already have (audit-only, surgical, or full rewrite by risk). A third capability, manage mode, runs a MAPE-K loop over a managed agent package and rewrites its prompt at a controlled seam.

3 · Six ordered phases. Shape inference → adaptive interview → operator-design drafting → audit → honest evaluation → delivery. Each phase consumes the last one’s output; the order cannot be rearranged because a later operator’s meaning depends on the subspace an earlier one already selected.

4 · Shared catalogs. The phases don’t invent their material — they draw on the operator catalog and seven shapes, and pull reasoning-pattern scaffolds in only when a task shows the hard-reasoning signals. A cross-cutting quantum-semantic frame is the vocabulary all of them speak.

5 · The verifier. Every prompt ships with a verifier defined across three layers — static properties of the artifact, single-run properties of one output, and cross-run properties visible only across many. Each delivery carries the audit summary with a self-report that discloses but never clears, and a scaffold-to-trigger list naming why each extra is there.

01 INIZIA DA QUI · MAPPA

Panoramica — come si incastrano i pezzi

Prometheus è una skill di prompt engineering per agenti di coding — e non solo. Descrivi ciò che ti serve e progetta un prompt, un workflow o un agente self-adaptive, strutturato e verificato, consegnato con un verificatore.

Prometheus è un framework in fase di build per progettare, verificare e rifattorizzare prompt per agenti che usano strumenti. Legge un compito, sceglie una modalità ed esegue una pipeline ordinata che attinge a cataloghi condivisi e consegna il prompt con un verificatore. Tutto ciò che segue è una mappa.

L’architettura e il flusso di lavoro

Leggi la mappa in cinque mosse

1 · Il router. SKILL.md è l’unico file sempre in contesto. Legge la richiesta e seleziona una modalità; porta con sé anche la procedura da zero. Nient’altro viene letto finché una fase non lo richiama.

2 · Due modalità (più manage). From-scratch progetta un nuovo prompt; refactor ripara uno che hai già (solo audit, chirurgico o riscrittura completa in base al rischio). Una terza capacità, la modalità manage, esegue un ciclo MAPE-K su un pacchetto-agente gestito e ne riscrive il prompt a una giuntura controllata.

3 · Sei fasi ordinate. Inferenza della forma → intervista adattiva → stesura per operatori → audit → valutazione onesta → consegna. Ogni fase consuma l’output della precedente; l’ordine non si può riorganizzare perché il significato di un operatore successivo dipende dal sottospazio che uno precedente ha già selezionato.

4 · Cataloghi condivisi. Le fasi non inventano il loro materiale — attingono al catalogo degli operatori e alle sette forme, e richiamano gli scaffold di ragionamento solo quando un compito mostra i segnali di ragionamento difficile. Un frame quantistico-semantico trasversale è il vocabolario che tutte parlano.

5 · Il verificatore. Ogni prompt viene consegnato con un verificatore definito su tre livelli — proprietà statiche dell’artefatto, proprietà su singola esecuzione di un output e proprietà cross-run visibili solo su molte. Ogni consegna porta il riepilogo dell’audit con un’autovalutazione che informa ma non dà mai il via libera, e una lista scaffold-to-trigger che motiva ogni extra.

02 THE MODEL · CORE

Core System

Most prompt-engineering advice is a bag of tips: add keywords, give examples, be specific. Prometheus rejects that framing at the root. It starts from a claim it takes literally rather than metaphorically — that meaning in a language model is constructed by context, not retrieved by it. Under that claim a prompt section is not a hint pointing at a pre-existing answer; it is a transformation applied to the model's distribution over interpretations, and the framework's entire job is to help a designer choose those transformations deliberately.

The problem it solves is therefore disciplined prompt construction: given a task, produce a prompt in the right structural shape, with each section justified as an operator, audited against known failure modes, scored honestly, and shipped with a runnable verifier. Its users are people building agents and prompt systems who want rigor and traceability rather than vibes — and who are willing to be disagreed with when a request would produce a worse prompt.

A prompt is an operator, not a key

The old picture

A prompt is a key — the right words, in the right order, imagined to unlock a hidden answer the model was holding back. Meaning is assumed to already sit inside the model, waiting to be retrieved.

Prometheus takes the opposite literally

Meaning is constructed by context, not retrieved. So a prompt section is not a hint — it is an operator that amplifies some readings of the task, suppresses others, and mixes the rest.

What it actually does

The framework exposes three capabilities, one per mode. They share a substrate of reference knowledge but run different procedures.

• From-scratch design · The default — Given a task description, the framework produces a prompt through six ordered phases: it infers the task's shape, runs an adaptive interview to recover the constraints an operator needs, drafts the prompt as a sequence of named operators, audits that draft against a structural-and-quantum checklist, scores it honestly on three axes, and delivers it with a verifier. The ordering is load-bearing, because operators do not commute.
• Refactor a prompt · On an existing prompt — Given a prompt the user already has, the framework recovers its intent and takes one of three sub-modes by risk: Mode A audits only, a report with zero edits; Mode B localizes a named symptom to its operator-level cause and proposes a surgical diff; Mode C rewrites wholesale, preserving the original and presenting both with an explicit trade-off analysis.
• Manage an agent · Over its lifetime — Given a managed-agent package — a directory that is the agent's identity — the framework runs a Monitor–Analyze–Plan–Execute loop over it, reusing the same audit checklist, refactor sub-modes, and verifier rather than inventing new machinery. Monitor reconstructs the distribution the current prompt induces from recent runs; Analyze keeps candidate adaptations in weighted superposition and prunes the ones the ledger says already regressed; Plan collapses to a single edit; and Execute applies it at a controlled lifecycle seam, write-ahead-logged and reversible by snapshot. Build-time only: it never runs what it produces. Manage mode is the one exception — it runs only the managed agent, and adapts it between runs, never live.

The shape of the system

Those three capabilities are not three separate programs. Architecturally the framework is a layered knowledge framework with a plugin-style catalog and a stateful control loop — not a monolith, and not a pipeline alone. Four strata stack cleanly, and one concern cuts across all of them. At the top a thin router reads the request and selects a mode. Beneath it sit the three procedures — from-scratch, refactor, and manage — each a sequence of phases. All three draw on a shared substrate of reference knowledge: the shape catalog, the operator catalog, the audit checklist, the evaluation rubric, the verifier specification, the reasoning patterns, and the consumability discipline — a body of knowledge none of them owns and all of them consume. Below the substrate, manage mode alone adds a state layer: the file-backed agent package and the runnable replay verifier that guards it.

The one cross-cutting concern is the quantum-semantic frame — the eleven principles that give the framework its operator vocabulary. It is not a layer; it is a language every other component speaks. And it is enforced rather than encouraged: an invariant requires every managed-mode concept to be anchored to a real section of the source paper or to a numbered principle. The frame is the reason the pieces cohere — remove it and the skill becomes an ordinary checklist. That layered view has a companion in a module dependency map that makes the router-to-reference delegation concrete, one file per phase: no reference file calls back into the controller, and the dependency direction points one way, from controller to reference, which keeps the modules independently readable.

Routing rules

Routing chooses the mode, not the shape. Within from-scratch, the framework still refuses to ask the author what kind of prompt they want; it infers the structural shape from the request's own linguistic signals in a Bayesian pass, and asks a forced-choice question only when the two likeliest shapes fall within roughly thirty percent of each other. That inference logic lives on the following panes.

The flows

Two flows carry the system: the linear from-scratch pipeline and the cyclic manage-mode loop that the state layer governs. The pipeline is the one the default mode runs. A task description enters Phase 1, where it is classified into a shape and a tier; those two facts flow into Phase 2's interview, which recovers the runtime and the definition of done. Phase 3 drafts the prompt as ordered operators drawn from the catalog; Phase 4 audits that draft and can send it back for revision; Phase 5 scores it; Phase 6 delivers the prompt plus a verifier. Data accretes forward — each phase's output is the next phase's input — and the ordering is not rearrangeable, because a later operator's meaning depends on the subspace an earlier one already selected.

The dataflow underneath is a steady narrowing: a free-form task string becomes a signal vector, then a shape with gathered constraints, then an ordered sequence of operator-sections, then an audited and scored artifact, then a delivered bundle. Nothing that is projected away at one phase returns at a later one, which is why the framework insists the phases run in order. The one edge that runs backward is the audit's: a failing Phase 4 returns the draft to Phase 3 for revision rather than passing a defective prompt forward.

Walking one concrete request makes the phase transformations visible. Suppose the author asks for an LLM-as-judge prompt that scores support replies for empathy, running on the OpenAI API. In Phase 1 the words “judge” and “scores” concentrate the posterior on the grader shape with no serious rival, so the framework commits without disambiguating; the runtime is named but no specific model is, so the tier defaults to strong; and because empathy scoring is evaluative judgment rather than multi-step reasoning, the hard-reasoning signals do not fire and no cognitive-tools scaffold is attached. Phase 2 loads the grader question bank and runs its calibration pass, eliciting a clear-pass and clear-fail anchor and proposing the borderline. Phase 3 draws the grader spine — reasoning forced before the score, calibration anchors, bias controls — and selects the explicit-format delivery path. Phase 4 runs the grader's branch-specific audit together with the blocking cross-cutting checks; Phase 5 scores the three axes honestly and confirms no untriggered scaffold survived; and Phase 6 ships the grader prompt, a usage note, the audit summary, a verifier specification, and an auto-generated static-mode verifier — after the framework runs that verifier against its own draft and finds it clean.

The Fabrication Cycle

From-scratch design compiles a raw task into a delivered prompt, workflow, or agent across six ordered phases. Each phase hands its output to the next; only one edge ever runs backward.

1. Shape · infer shape + tier — Samples the raw request to classify it into one of the structural shapes and a strength tier — no routing questions asked. When the reading is clear enough, the framework commits and moves on.
2. Interview · runtime + done-def — A short, capped interview recovers what an operator needs — the runtime it will run on and the definition of done — and closes with a summary the author can correct.
3. Draft · ordered operators — Drafts the prompt as an ordered sequence of operators from the catalog — sections that amplify, suppress, or mix readings. The order is load-bearing: a later operator depends on what an earlier one selected.
4. Audit · structure + measurement — Audits the draft against the framework’s structural and measurement checklists. A failing audit is the pipeline’s one loop back — it returns the draft to drafting for revision.
5. Score · three honest axes — Scores the result honestly on three axes — token economy, task fit, and operator coherence — and confirms no unused scaffolding slipped into the draft.
6. Deliver · prompt + verifier — Delivers the prompt with a verifier specification and, where it applies, a ready-to-run verifier — emitted as plain blocks, changing nothing on disk.

What you get

More than prompts and agents

Prometheus does not just write a prompt and stop. The same operator model compiles into whatever the task actually needs — and it was built from the start to give life to real agents and agentic workflows, not only single-shot instructions.

00 · Prompts

System prompts and single-call instructions, drafted as ordered operators and scored before delivery.

01 · Cognitive-tool scaffolds

For hard multi-step reasoning: a system prompt plus ready-to-register tool definitions you wire into your own tool-calling runtime.

02 · Agents

Agentic

Full agentic loops — persona, tool contracts, and a memory discipline — designed to run over many turns against real tools, not a one-off reply.

03 · Agentic workflows

Agentic

Multi-step pipelines and orchestration blueprints — ordered stages, hand-offs, and stop conditions — that wire several prompts into one working system.

04 · Graders & evaluators

LLM-as-judge rubrics with explicit, checkable criteria — the shape Prometheus reaches for when the task is to score, not to generate.

05 · Verifiers

Every deliverable ships with a verifier spec across three layers, so you can check the artifact does what it claims.

Where the design strains

A handful of load-bearing decisions give the framework its character, and the same decisions are where it feels its own tension. The build-time boundary comes first: by refusing to be a runtime orchestrator, the framework keeps its analytical clarity and its scope small, at the cost of leaving the author to actually run and wire the artifacts it produces. The operator metaphor is treated as a real design tool rather than decoration — it is the source of the most distinctive rules, from non-commutative ordering to substrate-relative strength. Two further commitments, compositionality and honest self-assessment as a shipped feature, keep the framework small and make its own limitations visible rather than hidden. A related choice, self-reference through closure, builds the managing system out of framework-designed prompts, so the Monitor, Analyze, and grader operators are themselves audited and verified like any delivered prompt; this is elegant and it forced real rigor, but it also concentrates risk, because a flaw in the frame propagates into the manager's own reasoning.

The design strains in three visible places, and the source is candid about each. First, behavioral validation is deferred: the whole management loop is verified mechanically but never run against a live agent, so “validated” means the machinery, not the behavior. Second, intent-level anti-oscillation is only partially mechanical — the runnable verifier pre-filters on trigger-and-section and leaves intent to a grader that itself needs a live model to render a verdict, so a fully autonomous ship-gate is not yet closed. Third, the frame's anchors must be maintained by hand: an earlier revision introduced several citations to non-existent paper sections that passed format-only checks and were caught only by a review that validated anchors against the actual source — a reminder that the frame's rigor depends on a check that now exists but did not at first.

Underneath all three sits one honest admission: the framework's guarantees are prompt-enforced, not mechanism-enforced. The blocking audit checks, the dogfood refusal, and the honesty disciplines are all instructions to the executing agent; nothing structurally prevents an agent under time pressure from skipping them. The source is candid that this is the central risk, and that roughly half the framework's surface — the agent-team path end to end, refactor mode, and the verifier infrastructure — is source-backed but not yet exercised against real tasks. A faithful reader should treat the framework as a well-grounded design whose validation is still partly outstanding, exactly as its own ledger states.

Open questions

Three things are genuinely unclear from the source alone. They are marked here rather than guessed at, because inventing an answer would teach the reader a certainty the material does not support.

How the Monitor operator's greppable text becomes structured YAML. The source states the markers map one-to-one onto the environment.yaml fields and that the phase serializes them, but the serializer itself is described rather than shown, so the exact contract is asserted, not demonstrated.

Who invokes the manage loop, and on what cadence. The min-N gate says not to adapt on too few runs, but the external process that accumulates those runs and triggers a Monitor pass sits outside the package and is left unspecified.

How the autonomy envelope's bounds are enforced at Execute time. The envelope schema is defined — option classes, a maximum diff size, a review cadence — but whether anything mechanically blocks an out-of-envelope edit, versus relying on the grader's judgment, is not settled in the source.

This section is explained by the router file — the one file always in context.

02 IL MODELLO · NUCLEO

Sistema centrale

Gran parte dei consigli sul prompt engineering è un sacchetto di trucchi: aggiungi parole chiave, fai esempi, sii specifico. Prometheus rifiuta questa impostazione alla radice. Parte da un’affermazione che prende alla lettera, non come metafora — che nel modello linguistico il significato è costruito dal contesto, non recuperato da esso. Sotto questa premessa una sezione del prompt non è un indizio che punta a una risposta preesistente; è una trasformazione applicata alla distribuzione del modello sulle interpretazioni, e tutto il lavoro del framework è aiutare chi progetta a scegliere quelle trasformazioni in modo deliberato.

Il problema che risolve è quindi la costruzione disciplinata dei prompt: dato un compito, produrre un prompt nella forma strutturale giusta, con ogni sezione giustificata come operatore, verificata rispetto ai modi di fallimento noti, valutata con onestà e consegnata con un verificatore eseguibile. I suoi utenti sono persone che costruiscono agenti e sistemi di prompt e vogliono rigore e tracciabilità invece che sensazioni — e accettano di sentirsi contraddire quando una richiesta produrrebbe un prompt peggiore.

Un prompt è un operatore, non una chiave

La vecchia idea

Un prompt è una chiave — le parole giuste, nell’ordine giusto, che dovrebbero sbloccare una risposta nascosta tenuta da parte dal modello. Si dà per scontato che il significato sia già dentro il modello, in attesa di essere recuperato.

Prometheus prende alla lettera l’opposto

Il significato è costruito dal contesto, non recuperato. Perciò una sezione del prompt non è un indizio — è un operatore che amplifica certe letture del compito, ne sopprime altre e mescola il resto.

Che cosa fa davvero

Il framework espone tre capacità, una per modalità. Condividono un substrato di conoscenza di riferimento ma eseguono procedure diverse.

• Progettazione da zero · Il default — Data una descrizione di compito, il framework produce un prompt attraverso sei fasi ordinate: deduce la forma del compito, conduce un’intervista adattiva per recuperare i vincoli di cui un operatore ha bisogno, redige il prompt come sequenza di operatori nominati, verifica quella bozza rispetto a una checklist strutturale e quantistica, la valuta con onestà su tre assi e la consegna con un verificatore. L’ordine è portante, perché gli operatori non commutano.
• Rifattorizzare un prompt · Su un prompt esistente — Dato un prompt che l’utente ha già, il framework ne recupera l’intento e adotta una di tre sotto-modalità in base al rischio: la Modalità A fa solo audit, un report con zero modifiche; la Modalità B localizza un sintomo indicato alla sua causa a livello di operatore e propone una diff chirurgica; la Modalità C riscrive per intero, preservando l’originale e presentando entrambi con un’analisi esplicita dei compromessi.
• Gestire un agente · Lungo il suo ciclo di vita — Dato un pacchetto-agente gestito — una cartella che è l’identità dell’agente — il framework vi esegue sopra un ciclo Monitor–Analyze–Plan–Execute, riusando la stessa checklist di audit, le sotto-modalità di refactor e il verificatore invece di inventare nuova macchina. Monitor ricostruisce, dalle esecuzioni recenti, la distribuzione indotta dal prompt attuale; Analyze mantiene gli adattamenti candidati in sovrapposizione pesata ed elimina quelli che il registro dà già per regrediti; Plan collassa su una singola modifica; ed Execute la applica a una giuntura controllata del ciclo di vita, con write-ahead log e reversibile tramite snapshot. Solo in fase di build: non esegue mai ciò che produce. La modalità manage è l’unica eccezione — esegue soltanto l’agente gestito, e lo adatta tra un’esecuzione e l’altra, mai dal vivo.

La forma del sistema

Quelle tre capacità non sono tre programmi separati. Architetturalmente il framework è un framework di conoscenza a livelli con un catalogo in stile plugin e un ciclo di controllo con stato — non un monolite, e non solo una pipeline. Quattro strati si impilano in modo pulito, e una preoccupazione le attraversa tutte. In cima un sottile router legge la richiesta e seleziona una modalità. Sotto di esso stanno le tre procedure — from-scratch, refactor e manage — ognuna una sequenza di fasi. Tutte e tre attingono a un substrato condiviso di conoscenza di riferimento: il catalogo delle forme, il catalogo degli operatori, la checklist di audit, la rubrica di valutazione, la specifica del verificatore, gli schemi di ragionamento e la disciplina di consumabilità — un corpo di conoscenza che nessuna possiede e che tutte consumano. Sotto il substrato, la sola modalità manage aggiunge uno strato di stato: il pacchetto-agente su file e il verificatore di replay eseguibile che lo protegge.

L’unica preoccupazione trasversale è il frame quantistico-semantico — gli undici principi che danno al framework il suo vocabolario di operatori. Non è un livello; è una lingua che ogni altro componente parla. Ed è imposta, non incoraggiata: un invariante richiede che ogni concetto della modalità manage sia ancorato a una sezione reale del paper di riferimento o a un principio numerato. Il frame è la ragione per cui i pezzi stanno insieme — toglilo e la skill diventa una checklist ordinaria. Quella vista a livelli ha un compagno in una mappa delle dipendenze fra moduli che rende concreta la delega dal router alla conoscenza di riferimento, un file per fase: nessun file di riferimento richiama il controllore, e la direzione delle dipendenze punta in un solo senso, dal controllore alla conoscenza, il che mantiene i moduli leggibili in modo indipendente.

Regole di instradamento

L’instradamento sceglie la modalità, non la forma. All’interno di from-scratch, il framework continua a rifiutarsi di chiedere all’autore che tipo di prompt voglia; deduce la forma strutturale dai segnali linguistici della richiesta stessa in un passaggio bayesiano, e pone una domanda a scelta forzata solo quando le due forme più probabili cadono entro circa il trenta percento l’una dall’altra. Quella logica di inferenza vive nei pannelli seguenti.

I flussi

Due flussi reggono il sistema: la pipeline lineare da zero e il ciclo di modalità manage governato dallo strato di stato. La pipeline è quella che esegue la modalità predefinita. Una descrizione di compito entra nella Fase 1, dove è classificata in una forma e un livello; quei due fatti confluiscono nell’intervista della Fase 2, che recupera il runtime e la definizione di fatto. La Fase 3 redige il prompt come operatori ordinati presi dal catalogo; la Fase 4 verifica quella bozza e può rimandarla in revisione; la Fase 5 la valuta; la Fase 6 consegna il prompt più un verificatore. I dati si accumulano in avanti — l’output di ogni fase è l’input della successiva — e l’ordine non è riorganizzabile, perché il significato di un operatore successivo dipende dal sottospazio che uno precedente ha già selezionato.

Il dataflow sottostante è un restringimento costante: una stringa di compito libera diventa un vettore di segnali, poi una forma con vincoli raccolti, poi una sequenza ordinata di sezioni-operatore, poi un artefatto verificato e valutato, poi un pacchetto consegnato. Nulla di ciò che viene proiettato via a una fase ritorna a una successiva, ed è per questo che il framework insiste che le fasi girino in ordine. L’unico arco che corre all’indietro è quello dell’audit: una Fase 4 fallita riporta la bozza alla Fase 3 per la revisione invece di passare avanti un prompt difettoso.

Percorrere una richiesta concreta rende visibili le trasformazioni delle fasi. Supponiamo che l’autore chieda un prompt LLM-as-judge che valuti l’empatia delle risposte di supporto, in esecuzione sull’API OpenAI. Nella Fase 1 le parole “judge” e “scores” concentrano il posteriore sulla forma grader senza rivali seri, quindi il framework decide senza disambiguare; il runtime è nominato ma nessun modello specifico lo è, quindi il livello torna per default a strong; e poiché valutare l’empatia è giudizio valutativo più che ragionamento a più passi, i segnali di ragionamento difficile non scattano e nessuno scaffold di strumenti cognitivi viene allegato. La Fase 2 carica il banco di domande del grader ed esegue il suo passaggio di calibrazione, elicitando un’ancora di chiaro-passaggio e chiaro-fallimento e proponendo il caso borderline. La Fase 3 traccia la spina dorsale del grader — ragionamento forzato prima del punteggio, ancore di calibrazione, controlli di bias — e seleziona il percorso di consegna a formato esplicito. La Fase 4 esegue l’audit specifico del ramo grader insieme ai controlli trasversali bloccanti; la Fase 5 valuta i tre assi con onestà e conferma che nessuno scaffold non attivato sia sopravvissuto; e la Fase 6 spedisce il prompt grader, una nota d’uso, il riepilogo di audit, la specifica di un verificatore e un verificatore statico auto-generato — dopo che il framework esegue quel verificatore sulla propria bozza e la trova pulita.

Il Ciclo di Fabbricazione

La progettazione da zero compila un compito grezzo in un prompt, workflow o agente consegnato attraverso sei fasi ordinate. Ogni fase passa il suo output alla successiva; un solo arco corre all’indietro.

1. Forma · forma + livello — Campiona la richiesta grezza per classificarla in una delle forme strutturali e in un livello di robustezza — senza domande di instradamento. Quando la lettura è abbastanza chiara, il framework decide e prosegue.
2. Intervista · runtime + ‘fatto’ — Un’intervista breve e limitata recupera ciò di cui un operatore ha bisogno — il runtime su cui girerà e la definizione di ‘fatto’ — e si chiude con un riepilogo che l’autore può correggere.
3. Stesura · operatori ordinati — Redige il prompt come sequenza ordinata di operatori dal catalogo — sezioni che amplificano, sopprimono o mescolano letture. L’ordine è portante: un operatore successivo dipende da ciò che uno precedente ha selezionato.
4. Verifica · struttura + misura — Verifica la bozza rispetto alle checklist strutturali e di misura del framework. Una verifica fallita è l’unico ciclo all’indietro della pipeline — riporta la bozza alla stesura per la revisione.
5. Valutazione · tre assi onesti — Valuta il risultato con onestà su tre assi — economia dei token, aderenza al compito e coerenza degli operatori — e conferma che nessuna impalcatura inutilizzata sia finita nella bozza.
6. Consegna · prompt + verificatore — Consegna il prompt con la specifica di un verificatore e, dove si applica, un verificatore pronto all’uso — emessi come blocchi semplici, senza modificare nulla su disco.

Cosa ottieni

Non solo prompt e agenti

Prometheus non si limita a scrivere un prompt e fermarsi. Lo stesso modello a operatori si compila in ciò di cui il compito ha davvero bisogno — ed è nato fin dall’inizio per dare vita a veri agenti e flussi di lavoro agentici, non solo a istruzioni singole.

00 · Prompt

System prompt e istruzioni a chiamata singola, redatti come operatori ordinati e valutati prima della consegna.

01 · Impalcature di strumenti cognitivi

Per ragionamenti complessi multi-step: un system prompt più definizioni di strumenti pronte da registrare nel tuo runtime con tool calling.

02 · Agenti

Agentic

Veri loop agentici — persona, contratti degli strumenti e una disciplina di memoria — progettati per operare su molti turni con strumenti reali, non una risposta isolata.

03 · Flussi di lavoro agentici

Agentic

Pipeline multi-step e blueprint di orchestrazione — fasi ordinate, hand-off e condizioni di arresto — che collegano più prompt in un unico sistema funzionante.

04 · Grader e valutatori

Rubriche LLM-as-judge con criteri espliciti e verificabili — la forma che Prometheus adotta quando il compito è valutare, non generare.

05 · Verificatori

Ogni risultato viene consegnato con una specifica di verifica su tre livelli, così puoi verificare che l’artefatto fa ciò che promette.

Dove il design mostra le sue tensioni

Una manciata di decisioni portanti dà al framework il suo carattere, e le stesse decisioni sono il punto in cui sente la propria tensione. Il confine di build-time viene prima: rifiutando di essere un orchestratore a runtime, il framework mantiene la sua chiarezza analitica e il suo ambito ristretto, al costo di lasciare all’autore l’onere di eseguire e cablare davvero gli artefatti che produce. La metafora dell’operatore è trattata come un vero strumento di design e non come decorazione — è la fonte delle regole più distintive, dall’ordinamento non commutativo alla forza relativa al substrato. Altri due impegni, la composizionalità e l’autovalutazione onesta come funzione consegnata, mantengono il framework piccolo e rendono visibili i suoi limiti invece di nasconderli. Una scelta collegata, l’autoriferimento tramite chiusura, costruisce il sistema di gestione a partire da prompt progettati dal framework, così che gli operatori Monitor, Analyze e grader siano essi stessi verificati e sottoposti ad audit come qualunque prompt consegnato; questo è elegante e ha imposto rigore reale, ma concentra anche il rischio, perché un difetto nel frame si propaga nel ragionamento del gestore stesso.

Il design si tende in tre punti visibili, e la fonte è candida su ciascuno. Primo, la validazione comportamentale è rimandata: l’intero ciclo di gestione è verificato meccanicamente ma mai eseguito contro un agente vivo, quindi “validato” significa la macchina, non il comportamento. Secondo, l’anti-oscillazione a livello d’intento è solo parzialmente meccanica — il verificatore eseguibile prefiltra su trigger-e-sezione e lascia l’intento a un grader che a sua volta ha bisogno di un modello vivo per emettere un verdetto, quindi un cancello di rilascio pienamente autonomo non è ancora chiuso. Terzo, gli ancoraggi del frame vanno mantenuti a mano: una revisione precedente introdusse diverse citazioni a sezioni di paper inesistenti che avevano passato controlli solo formali e furono colte solo da una revisione che validava gli ancoraggi contro la fonte reale — un promemoria che il rigore del frame dipende da un controllo che ora esiste ma all’inizio non c’era.

Sotto tutti e tre sta un’ammissione onesta: le garanzie del framework sono imposte dal prompt, non dal meccanismo. I controlli di audit bloccanti, il rifiuto di dogfood e le discipline di onestà sono tutti istruzioni all’agente che esegue; nulla impedisce strutturalmente a un agente sotto pressione di tempo di saltarli. La fonte è candida sul fatto che questo è il rischio centrale, e che circa metà della superficie del framework — il percorso del team di agenti da capo a fondo, la modalità refactor e l’infrastruttura del verificatore — è sostenuta dalle fonti ma non ancora esercitata contro compiti reali. Un lettore fedele dovrebbe trattare il framework come un design ben fondato la cui validazione è ancora in parte in sospeso, esattamente come afferma il suo stesso registro.

Domande aperte

Tre cose sono davvero poco chiare dalla sola fonte. Sono segnate qui invece che indovinate, perché inventare una risposta insegnerebbe al lettore una certezza che il materiale non sostiene.

Come il testo greppabile dell’operatore Monitor diventa YAML strutturato. La fonte afferma che i marcatori mappano uno-a-uno sui campi di environment.yaml e che la fase li serializza, ma il serializzatore stesso è descritto invece che mostrato, quindi il contratto esatto è asserito, non verificato.

Chi invoca il ciclo manage, e con quale cadenza. Il gate min-N dice di non adattare su troppo poche esecuzioni, ma il processo esterno che accumula quelle esecuzioni e fa scattare un passaggio del Monitor sta fuori dal pacchetto ed è lasciato non specificato.

Come i limiti dell’envelope di autonomia sono imposti al tempo di Execute. Lo schema dell’envelope è definito — classi di opzioni, una dimensione massima del diff, una cadenza di revisione — ma se qualcosa blocchi meccanicamente una modifica fuori envelope, invece di affidarsi al giudizio del grader, non è risolto nella fonte.

Questa sezione è spiegata dal file router — l’unico file sempre in contesto.

03 THE MODEL · FRAME

Quantum Principles

Source: references/quantum-principles.md · references/operators.md

The framework treats every prompt — and every section within it — as an operator: a transformation applied to the model's semantic state, not a key that unlocks an answer already sitting inside the model. Drafting, on this view, is not a search for the right words but the design of the right transformation, applied in the right order. This pane covers the rule that decides how hard each transformation should push — because operator strength is not a fixed property of a section. It is calibrated to the substrate the section acts on.

Each operator carries a profile: what it amplifies, what it suppresses, what it mixes, its strength, its place in the sequence, and its failure mode.

• Amplifiers raise the probability of the interpretations you want — a persona's expertise, few-shot examples, concrete nouns, a domain's vocabulary.
• Suppressors lower the probability of the readings you don't — off-domain drift, generic-assistant defaults, outputs that violate a constraint. Each constraint is its own operator; total strength scales with their count.
• Mixers combine states rather than sharpen one — a deliberately hybrid domain, or stacked personas, which never simply concatenate but produce a different operator entirely.

Watch each prompt section act as an operator on the task — amplifying some readings, filtering out others, mixing the rest — instead of just stacking strings of text. An operator has a profile — the readings it amplifies, the ones it suppresses, and the ones it mixes. Collapse is set apart: it is the measurement act, where the prompt commits to a single reading.

Operator profile

• Amplify: Constructive interference. Amplifies a specific semantic interpretation while preserving superposition. — Â PROJECTS the state
• Suppress: Destructive interference. Filters out noise and suppresses off-domain interpretations. — Ŝ FILTERS noise
• Mix: Entangles logic. Combines multiple basis states into a novel, hybrid reading. — M̂ ENTANGLES logic
• Collapse: Measurement. Forces deterministic convergence onto a single, unambiguous interpretation. — B̂ COLLAPSES possibilities

In the film, the chain chapter plays the same four operators in sequence on a small toy model of one task: each one acts on what the one before it left, and the readings narrow to one crest. You don’t set that order — Prometheus does, strongest first, by the default sequence in the operators reference, and states any departure. It is the model's output — illustrative, not a measurement.

Designing one section

A single section is drafted in four moves. Identify the interpretations it should amplify and the ones it should suppress; choose its strength; place it in sequence, from the broadest framing down to the final format; then check it for interference with its neighbours, because combining two sections produces interference, not addition — “expert + dry tone” sharpens into a recognizable voice, while “warm assistant + brutally honest” can cancel until the model settles on neither.

The third move — choosing strength — is where the substrate tier bites.

Operator strength is calibrated to the substrate

Strength is not intrinsic to a section; it is relative to the model the section runs on. On a highly capable substrate a prescriptive operator over-projects — it collapses states the model's own defaults would have resolved better than the prescription. The same enumerated behavior list that corrected a weaker model's drift becomes, on a stronger model, an information-destroying constraint on a state that no longer needed collapsing. So the framework reads a substrate capability tier from the runtime answer during the interview and dials its default operator strength against it: the more capable the model, the lighter the hand.

• Frontier — Prefer brief, general instructions. Reserve intensity language — MUST, CRITICAL, repeated prohibitions, exhaustive enumeration — for constraints with a demonstrated failure mode, and let the model's own priors resolve the residual ambiguity.
• Strong · default — The assumed tier when the runtime is unknown. Moderate projection — strong enough to hold the shape, restrained enough to avoid over-collapsing states a capable model handles on its own.
• Legacy — Stronger projection is often warranted. Instructions that would over-trigger a newer model are exactly what corrects a weaker one's drift, so heavier enumeration and firmer intensity earn their place here.

Four rules that hold across every shape

Whatever the substrate and whatever the shape being drafted, four rules always apply.

• Aim for the right altitude — between brittle hardcoding that breaks on the first unforeseen case and vague hand-waving that decides nothing.
• Spend the smallest viable token set. Every added instruction is another projection; the ones that don't earn their place cost information, not just length.
• Prefer worked examples to abstract rules — while remembering that an example silently teaches every judgment call it happens to contain, including the ones you did not mean to encode.
• Order sections by operator strength — strongest first to set the subspace, output format last unless the format is itself the dominant requirement.

Two standing rules on what the framework will add at all

• Examples are load-bearing — Where a rule is load-bearing, the worked example must sit beside it. An output format stated without an example of it is treated as a defect, not a stylistic gap — the reader has been told the shape without being shown it.
• M5 · scaffold restraint — The framework applies its own smallest-viable-token-set discipline to its own generative tendency. An optional scaffold may be added only against a named trigger — a debugged failure, a stated requirement, a measured risk — and a scaffold that is declined is named anyway, together with the condition that would re-trigger it.

**P9 — Operator strength is substrate-relative.** A prescriptive operator that corrected a weak substrate over-projects on a strong one. *Rule:* calibrate default strength down as substrate capability rises: brief general instructions on adaptive-reasoning substrates (while stating scope — they read literally); enumeration, repetition at both ends, and explicit CoT scaffolds on legacy substrates. Intensity language (CRITICAL/MUST, all-caps) is reserved for true invariants on every tier. Capability lockdown for destructive roles stays layered and loud on every tier — its justification is risk, not substrate weakness. *Anchor:* "skills developed for prior models are often too prescriptive… and can degrade output quality" (Anthropic, Fable 5, 2026); "treat it as a new model family" (OpenAI, 2026); "may over-analyze verbose techniques for older models" (Google, 2025–26).

The eleven principles below are the ground truth for this section.

03 IL MODELLO · CORNICE

Principi quantistici

Fonte: references/quantum-principles.md · references/operators.md

Il framework tratta ogni prompt — e ogni sezione al suo interno — come un operatore: una trasformazione applicata allo stato semantico del modello, non una chiave che sblocca una risposta già presente nel modello. La stesura, in questa visione, non è la ricerca delle parole giuste ma il design della trasformazione giusta, applicata nell’ordine giusto. Questo pannello copre la regola che decide quanto forte ciascuna trasformazione debba spingere — perché la forza di un operatore non è una proprietà fissa di una sezione. È calibrata sul substrato su cui la sezione agisce.

Ogni operatore porta un profilo: ciò che amplifica, ciò che sopprime, ciò che mescola, la sua forza, il suo posto nella sequenza e il suo modo di fallimento.

• Gli amplificatori alzano la probabilità delle interpretazioni che vuoi — la competenza di una persona, esempi few-shot, nomi concreti, il vocabolario di un dominio.
• I soppressori abbassano la probabilità delle letture che non vuoi — deriva fuori dominio, default da assistente generico, output che violano un vincolo. Ogni vincolo è un operatore a sé; la forza totale cresce col loro numero.
• I mixer combinano stati invece di affinarne uno — un dominio deliberatamente ibrido, o persone impilate, che non si concatenano mai semplicemente ma producono un operatore del tutto diverso.

Osserva ogni sezione del prompt agire come operatore sul compito — amplificando certe letture, filtrandone altre, mescolando il resto — invece di limitarsi ad accatastare stringhe di testo. Un operatore ha un profilo — le letture che amplifica, quelle che sopprime e quelle che mescola. Il Collasso è a sé: è l’atto di misura, in cui il prompt si impegna su una singola lettura.

Profilo operatore

• Amplifica: Interferenza costruttiva. Amplifica una specifica interpretazione semantica preservando la sovrapposizione. — Â PROIETTA lo stato
• Sopprimi: Interferenza distruttiva. Filtra il rumore e sopprime le interpretazioni fuori dominio. — Ŝ FILTRA il rumore
• Mescola: Intreccia la logica. Combina più stati di base in una lettura nuova e ibrida. — M̂ INTRECCIA la logica
• Collasso: Misura. Forza una convergenza deterministica su una singola interpretazione univoca. — B̂ COLLASSA le possibilità

Nel film, il capitolo della catena fa agire in sequenza gli stessi quattro operatori su un piccolo modello giocattolo di un compito: ognuno agisce su ciò che ha lasciato il precedente, e le letture si restringono a una sola cresta. Quell’ordine non lo fissi tu — lo fissa Prometheus, prima il più forte, secondo la sequenza predefinita del riferimento sugli operatori, e dichiara ogni deviazione. È l’output del modello — illustrativo, non una misura.

Progettare una sezione

Una singola sezione si redige in quattro mosse. Individua le interpretazioni che dovrebbe amplificare e quelle che dovrebbe sopprimere; scegli la sua forza; collocala nella sequenza, dalla cornice più ampia fino al formato finale; poi controlla l’interferenza con le vicine, perché combinare due sezioni produce interferenza, non somma — “esperto + tono asciutto” si affina in una voce riconoscibile, mentre “assistente caloroso + brutalmente onesto” può annullarsi finché il modello non si posa su nessuno dei due.

La terza mossa — scegliere la forza — è dove il livello del substrato morde.

La forza dell’operatore è calibrata sul substrato

La forza non è intrinseca a una sezione; è relativa al modello su cui la sezione gira. Su un substrato molto capace un operatore prescrittivo iper-proietta — collassa stati che i default del modello avrebbero risolto meglio della prescrizione. La stessa lista enumerata di comportamenti che correggeva la deriva di un modello più debole diventa, su un modello più forte, un vincolo che distrugge informazione su uno stato che non aveva più bisogno di essere collassato. Perciò il framework legge un livello di capacità del substrato dalla risposta sul runtime durante l’intervista e regola su di esso la forza di default dei suoi operatori: più il modello è capace, più leggera la mano.

• Frontier — Preferisci istruzioni brevi e generali. Riserva il linguaggio d’intensità — MUST, CRITICAL, divieti ripetuti, enumerazione esaustiva — ai vincoli con un modo di fallimento verificato, e lascia che i priori del modello risolvano l’ambiguità residua.
• Strong · default — Il livello assunto quando il runtime è ignoto. Proiezione moderata — abbastanza forte da tenere la forma, abbastanza contenuta da evitare di collassare troppo stati che un modello capace gestisce da solo.
• Legacy — Una proiezione più forte è spesso giustificata. Istruzioni che iper-attiverebbero un modello più recente sono esattamente ciò che corregge la deriva di uno più debole, quindi enumerazione più pesante e intensità più decisa si guadagnano qui il loro posto.

Quattro regole valide per ogni forma

Qualunque sia il substrato e qualunque sia la forma in stesura, quattro regole valgono sempre.

• Punta alla giusta altitudine — tra un hardcoding fragile che si rompe al primo caso imprevisto e un vago sventolare le mani che non decide nulla.
• Spendi il minimo insieme di token praticabile. Ogni istruzione aggiunta è un’altra proiezione; quelle che non si guadagnano il posto costano informazione, non solo lunghezza.
• Preferisci esempi svolti alle regole astratte — ricordando che un esempio insegna in silenzio ogni scelta di giudizio che contiene, comprese quelle che non intendevi codificare.
• Ordina le sezioni per forza dell’operatore — la più forte per prima per fissare il sottospazio, il formato di output per ultimo a meno che il formato non sia esso stesso il requisito dominante.

Due regole permanenti su cosa il framework aggiungerà

• Gli esempi sono portanti — Dove una regola è portante, l’esempio svolto deve starle accanto. Un formato di output enunciato senza un esempio è trattato come un difetto, non una lacuna stilistica — al lettore è stata detta la forma senza mostrargliela.
• M5 · moderazione degli scaffold — Il framework applica la propria disciplina del minimo insieme di token praticabile alla sua stessa tendenza generativa. Uno scaffold opzionale può essere aggiunto solo contro un trigger nominato — un fallimento debuggato, un requisito dichiarato, un rischio misurato — e uno scaffold rifiutato viene comunque nominato, insieme alla condizione che lo ri-attiverebbe.

**P9 — Operator strength is substrate-relative.** A prescriptive operator that corrected a weak substrate over-projects on a strong one. *Rule:* calibrate default strength down as substrate capability rises: brief general instructions on adaptive-reasoning substrates (while stating scope — they read literally); enumeration, repetition at both ends, and explicit CoT scaffolds on legacy substrates. Intensity language (CRITICAL/MUST, all-caps) is reserved for true invariants on every tier. Capability lockdown for destructive roles stays layered and loud on every tier — its justification is risk, not substrate weakness. *Anchor:* "skills developed for prior models are often too prescriptive… and can degrade output quality" (Anthropic, Fable 5, 2026); "treat it as a new model family" (OpenAI, 2026); "may over-analyze verbose techniques for older models" (Google, 2025–26).

Gli undici principi qui sotto sono la fonte di verità per questa sezione.

04 PIPELINE · PHASES 1 & 3

Shapes & the three axes

source: references/shapes.md · references/operators.md

The framework refuses one-size-fits-all templates. Before a single line is drafted it classifies the task along three orthogonal axes: the shape — the prompt's structural archetype; the domain — the field the work sits in; and the substrate tier — how capable the target model is. The three are independent: fixing one tells you nothing about the other two, which is why the same shape can be drafted for engineering or for research, or aimed at a frontier or a legacy model, without changing which sections appear.

The shape catalog is shared substrate. All three modes — from-scratch, refactor, and manage — draw on the same seven archetypes; none of them owns the catalog and all of them consume it, so what follows reads the same whichever runtime you are targeting.

The seven shapes

A shape is the structural skeleton a task calls for. There are exactly seven; each has a different anatomy, different sections, and a different failure mode. Most requests fall cleanly into one, a few are genuine hybrids.

S1 · Long-horizon agentic loop

The skeleton for open-ended work a model pursues over many turns against tools, correcting itself as it goes. Signalled by the noun loop and by markers of ongoing rather than single-call use, and by an explicitly named agentic runtime.

S2 · One-shot task

A single model call that produces one deliverable — classify, extract, summarize, transform — with no multi-turn interaction. This is the shape the hard-reasoning detector watches most closely, because a task that looks one-shot may still need a cognitive-tools scaffold.

S3 · Multi-stage workflow / chain

Several coordinated model calls where one stage consumes the measured output of the last, held together by gates and validators. Each stage is a complete operator in its own right.

S4 · Sub-agent / tool prompt

A prompt or tool description that lives inside a larger system rather than addressing a human user — consumed by another model or by an agent's tool-use mechanism.

S5 · System persona

A system prompt that shapes behavior over unknown future inputs, where the stability of the persona is what matters. Signalled by the noun persona and by continuous conversational use.

S6 · LLM-as-judge grader

A prompt that takes candidate outputs and returns a judgment. Its spine forces reasoning before the score, anchors each score level with calibration examples, and adds bias controls. Signalled by the noun judge and verbs like grade.

S7 · Multi-agent agent team

A coordinated set of prompts — an orchestrator, one or more workers, an optional synthesizer — plus a coordination contract. The topology is the dominant operator at team level; each role's prompt is drafted using the spine of whichever of the other six shapes it happens to be.

A new shape is not a code change but a new entry in this catalog, paired with a matching question bank for the interview and a matching branch in the audit checklist — the same extension pattern the framework uses for a new operator or a new quality concern.

Shape inference is Bayesian, never a routing question

The framework does not, as a rule, ask the author what kind of prompt they want. Asking would be a routing question, and routing throws away the information carried in how the request is phrased. Instead it reads linguistic signals — verbs such as build, grade, or extract; nouns such as loop, persona, or judge; scale markers that separate a single call from ongoing use; and any named runtime — and forms an internal posterior distribution over the seven shapes.

It commits to the highest-mass shape only when the runner-up is clearly behind. The threshold is explicit: when two shapes fall within roughly thirty percent of each other, the inference is treated as genuinely ambiguous, and the framework asks a single forced-choice question between the top two — never an open-ended one. This is deliberate collapse: the ambiguity is preserved until asking is cheap and being wrong would be expensive, then resolved with the narrowest question that settles it.

The same inference pass does double duty. It fixes the domain axis and reads the substrate tier from the runtime answer, so a single reading of the request settles all three axes at once.

The domain axis changes content, not structure

The domain — engineering, research, writing, ops, or generic — is a secondary axis. It changes the content of sections without changing which sections appear: an engineering task fills the spine with a concrete stack and tooling-specific failure modes, a research task with source-quality rules and citation conventions, a writing task with voice and length anchors, an ops task with safety boundaries and rollback for irreversible actions, and a generic task with the minimum, leaving the author to fill the rest. Because the domain rides orthogonally to the shape, the seven skeletons times five domains give the same procedure thirty-five ways to be filled in.

The substrate tier sets the strength of the hand

The substrate capability tier — frontier, strong, or legacy, defaulting to strong when the model is unknown — describes the model the prompt will run on, and it conditions how hard the framework's operators should push. The governing intuition is that the more capable the model, the lighter the hand: on a highly capable substrate a prescriptive operator over-projects, collapsing states the model's own defaults would have handled better. So at drafting time the framework prefers brief general instructions on a frontier substrate and reserves intensity language for constraints with a demonstrated failure mode, while on a legacy substrate stronger projection is often warranted.

The tier also gates hard-reasoning detection. When two or more hard-reasoning signals fire — mathematical or logical tasks, multi-step planning, code analysis, several simultaneous constraints, or an author who reports the model fails on the first try — the cognitive-tools scaffold normally becomes a structural default. But that default holds only on the legacy and strong tiers, where the cited empirical result applies; on the frontier tier it is downgraded to an opt-in, because general instructions there tend to beat prescriptive decomposition. It is the framework's clearest instance of narrowing an empirical claim to the scope it was actually measured on.

One category is explicitly exempt from this dialing-down. Capability lockdown for a role with destructive powers stays loud on every tier, because its justification is risk rather than model weakness — the reason to constrain a delete or a shell command has nothing to do with how clever the model is.

Shapes, the operator catalog they are drafted from, and the minimum a delivered prompt must fill.

04 PIPELINE · FASI 1 E 3

Forme e i tre assi

source: references/shapes.md · references/operators.md

Il framework rifiuta i template validi per tutti. Prima che una sola riga sia scritta classifica il compito lungo tre assi ortogonali: la forma — l’archetipo strutturale del prompt; il dominio — il campo in cui il lavoro si colloca; e il livello del substrato — quanto è capace il modello di destinazione. I tre sono indipendenti: fissarne uno non dice nulla sugli altri due, ed è per questo che la stessa forma può essere redatta per l’ingegneria o per la ricerca, o mirata a un modello frontier o legacy, senza cambiare quali sezioni compaiono.

Il catalogo delle forme è substrato condiviso. Tutte e tre le modalità — from-scratch, refactor e manage — attingono agli stessi sette archetipi; nessuna possiede il catalogo e tutte lo consumano, quindi ciò che segue si legge uguale qualunque runtime tu stia puntando.

Le sette forme

Una forma è lo scheletro strutturale che un compito richiede. Sono esattamente sette; ognuna ha un’anatomia diversa, sezioni diverse e un modo di fallimento diverso. La maggior parte delle richieste ricade nettamente in una, alcune sono ibridi genuini.

S1 · Ciclo agentico a lungo orizzonte

Lo scheletro per il lavoro aperto che un modello persegue su molti turni contro gli strumenti, correggendosi man mano. Segnalato dal nome loop e da marcatori di uso continuativo più che a chiamata singola, e da un runtime agentico nominato esplicitamente.

S2 · Compito one-shot

Una singola chiamata al modello che produce un solo deliverable — classificare, estrarre, riassumere, trasformare — senza interazione multi-turno. È la forma che il rilevatore di ragionamento difficile osserva più da vicino, perché un compito che sembra one-shot può comunque richiedere uno scaffold di strumenti cognitivi.

S3 · Workflow / catena multi-stadio

Più chiamate coordinate al modello dove uno stadio consuma l’output misurato del precedente, tenute insieme da gate e validatori. Ogni stadio è un operatore completo a sé stante.

S4 · Prompt di sub-agente / strumento

Un prompt o una descrizione di strumento che vive dentro un sistema più grande invece di rivolgersi a un utente umano — consumato da un altro modello o dal meccanismo d’uso strumenti di un agente.

S5 · Persona di sistema

Un prompt di sistema che plasma il comportamento su input futuri ignoti, dove ciò che conta è la stabilità della persona. Segnalato dal nome persona e dall’uso conversazionale continuo.

S6 · Grader LLM-as-judge

Un prompt che prende output candidati e restituisce un giudizio. La sua spina dorsale forza il ragionamento prima del punteggio, ancora ogni livello di punteggio con esempi di calibrazione e aggiunge controlli di bias. Segnalato dal nome judge e da verbi come grade.

S7 · Team di agenti multi-agente

Un insieme coordinato di prompt — un orchestratore, uno o più worker, un sintetizzatore opzionale — più un contratto di coordinamento. La topologia è l’operatore dominante a livello di team; il prompt di ogni ruolo è redatto usando la spina dorsale di qualunque delle altre sei forme esso sia.

Una nuova forma non è una modifica di codice ma una nuova voce in questo catalogo, abbinata a un banco di domande corrispondente per l’intervista e a un ramo corrispondente nella checklist di audit — lo stesso schema di estensione che il framework usa per un nuovo operatore o una nuova preoccupazione di qualità.

L’inferenza della forma è bayesiana, mai una domanda di instradamento

Di norma il framework non chiede all’autore che tipo di prompt voglia. Chiederlo sarebbe una domanda di instradamento, e l’instradamento butta via l’informazione contenuta nel modo in cui la richiesta è formulata. Legge invece segnali linguistici — verbi come build, grade o extract; nomi come loop, persona o judge; marcatori di scala che separano una singola chiamata dall’uso continuativo; e qualunque runtime nominato — e forma una distribuzione a posteriori interna sulle sette forme.

Si impegna sulla forma con più massa solo quando la seconda è chiaramente dietro. La soglia è esplicita: quando due forme cadono entro circa il trenta percento l’una dall’altra, l’inferenza è trattata come genuinamente ambigua, e il framework pone una singola domanda a scelta forzata tra le prime due — mai una aperta. È un collasso deliberato: l’ambiguità è preservata finché chiedere costa poco e sbagliare costerebbe caro, poi risolta con la domanda più stretta che la sistema.

Lo stesso passaggio d’inferenza fa doppio lavoro. Fissa l’asse dominio e legge il livello del substrato dalla risposta sul runtime, così una singola lettura della richiesta risolve tutti e tre gli assi in una volta.

L’asse dominio cambia il contenuto, non la struttura

Il dominio — ingegneria, ricerca, scrittura, ops o generico — è un asse secondario. Cambia il contenuto delle sezioni senza cambiare quali sezioni compaiono: un compito di ingegneria riempie la spina dorsale con uno stack concreto e modi di fallimento specifici del tooling, un compito di ricerca con regole di qualità delle fonti e convenzioni di citazione, un compito di scrittura con ancore di voce e lunghezza, un compito ops con confini di sicurezza e rollback per azioni irreversibili, e un compito generico con il minimo, lasciando all’autore il resto da riempire. Poiché il dominio corre ortogonale alla forma, i sette scheletri per cinque domini danno alla stessa procedura trentacinque modi di essere riempita.

Il livello del substrato fissa la forza della mano

Il livello di capacità del substrato — frontier, strong o legacy, con default a strong quando il modello è ignoto — descrive il modello su cui il prompt girerà, e condiziona quanto forte debbano spingere gli operatori del framework. L’intuizione di fondo è che più il modello è capace, più leggera la mano: su un substrato molto capace un operatore prescrittivo iper-proietta, collassando stati che i default del modello avrebbero gestito meglio. Perciò in fase di stesura il framework preferisce istruzioni generali brevi su un substrato frontier e riserva il linguaggio d’intensità ai vincoli con un modo di fallimento verificato, mentre su un substrato legacy una proiezione più forte è spesso giustificata.

Il livello regola anche la rilevazione del ragionamento difficile. Quando scattano due o più segnali di ragionamento difficile — compiti matematici o logici, pianificazione a più passi, analisi di codice, più vincoli simultanei, o un autore che riferisce che il modello fallisce al primo tentativo — lo scaffold di strumenti cognitivi di norma diventa un default strutturale. Ma quel default vale solo sui livelli legacy e strong, dove si applica il risultato empirico citato; sul livello frontier è retrocesso a opt-in, perché lì le istruzioni generali tendono a battere la decomposizione prescrittiva. È l’istanza più chiara nel framework di restringere un’affermazione empirica all’ambito su cui è stata effettivamente misurata.

Una categoria è esplicitamente esente da questo abbassamento. Il blocco di capacità per un ruolo con poteri distruttivi resta forte su ogni livello, perché la sua giustificazione è il rischio e non la debolezza del modello — la ragione per vincolare un delete o un comando di shell non ha nulla a che vedere con quanto è intelligente il modello.

Le forme, il catalogo di operatori da cui sono redatte e il minimo che un prompt consegnato deve riempire.

05 PIPELINE · PHASE 2

The Adaptive Interview

Source: references/shapes.md

Once Phase 1 has inferred a shape and a substrate tier, a handful of constraints still cannot be read from the request — chiefly where the prompt will run and how its success will be checked. The interview recovers exactly those, and it is designed around a single conviction the framework holds everywhere: ambiguity is a superposition of readings to be preserved and deliberately collapsed, not a defect to interrogate away. Asking too much collapses that superposition prematurely; asking the wrong thing re-asks what the request already settled and destroys information. So the interview is deliberately small, ordered, and bounded.

The governing rule states the tension plainly: the framework should preserve ambiguity wherever asking is cheap but being wrong is expensive. Where a wrong guess is costly and a question is easy, it asks; everywhere else it records the weighted readings and moves on rather than forcing a premature commitment.

Six flat questions, and no more

A Hard Budget

The flat interview is capped at six questions in total. Three of them are universal, asked of every shape: the runtime the prompt will execute in, a checkable definition of done, and the deployment context — the last omitted when the request already makes it obvious. The remaining two or three are drawn from the inferred shape, targeting the gaps that shape specifically leaves open. If a disambiguating question survived from Phase 1, it too is counted against the budget; there is one cap, and everything spends from it.

The cap is lifted only for the richer co-authoring passes — the workflow chain, the LLM-as-judge grader, and the multi-agent team — where the decomposition, the calibration anchors, or the role roster is itself the highest-leverage decision and a flat list would produce shallow answers. Those passes propose a candidate first and then refine it, rather than soliciting a specification cold.

How the questions are asked

Four rules govern the manner of asking, and each earns its place by protecting the answers. Questions go out one per turn, because a turn crowded with several questions reliably yields shallower replies to all of them. Anything the request already answered is skipped, because re-asking it discards information the author already gave. The broadest question comes first, because the first answer fixes the subspace every later question operates within. And across all of them the framework leans toward silence wherever a wrong guess is cheap to make and easy to correct, spending its scarce questions only where being wrong would be expensive.

• One question per turn — A single question per turn keeps each answer considered; multi-question turns trade depth for the illusion of speed.
• Skip the answered — Whatever the request has already specified or clearly implied is never asked again, since re-asking it destroys the information the author supplied.
• Broadest framing first — Scope and persona are settled before format and edge cases, because the first answer selects the subspace the narrower ones then refine.
• Preserve cheap ambiguity — A question is spent only where a wrong guess is expensive; where it is cheap, the reading is recorded and left open rather than forced.

Routing by the type of unknown

Not every gap is answerable by a question, so when intent is unclear the framework first asks what kind of unknown it faces and routes accordingly. The interview handles only the first of the four; the other three send the work somewhere cheaper or denser than a conversation before any drafting begins.

• An open question the author holds — When the author knows the question they have, the interview itself resolves it — this is the ordinary case the six-question budget is sized for.
• "I'll know it when I see it" — A criterion the author cannot verbalize is routed to cheap measurement outside the prompt — a throwaway prototype or a brainstorm of variants to react to — before drafting.
• Unfamiliar with the domain — Signals that the author does not yet know what to ask trigger a blind-spot pass that enumerates the questions they have not thought to raise.
• A requirement that resists words — When intent cannot be put into words, the framework asks for a reference artifact — source code above all — as the densest available way to transfer it.

The summary collapse

The interview may not slide silently into drafting. It must close with a summary collapse: a restatement of the inferred shape, the constraints gathered, and every default the framework has assigned in the author's silence, handed back for a single round of correction. A collapse performed silently would throw away precisely the information the designer — and, later, anyone managing the agent — would need; making it explicit turns the measurement step into something the author can see and override.

The per-shape question banks and conduct rules for Phase 2.

05 PIPELINE · FASE 2

L’intervista adattiva

Fonte: references/shapes.md

Una volta che la Fase 1 ha dedotto una forma e un livello di substrato, una manciata di vincoli ancora non può essere letta dalla richiesta — soprattutto dove il prompt girerà e come se ne verificherà il successo. L’intervista recupera esattamente quelli, ed è progettata attorno a una sola convinzione che il framework tiene ovunque: l’ambiguità è una sovrapposizione di letture da preservare e collassare deliberatamente, non un difetto da eliminare a forza di domande. Chiedere troppo collassa quella sovrapposizione prematuramente; chiedere la cosa sbagliata ri-chiede ciò che la richiesta aveva già stabilito e distrugge informazione. Perciò l’intervista è deliberatamente piccola, ordinata e limitata.

La regola di governo enuncia la tensione con chiarezza: il framework dovrebbe preservare l’ambiguità ovunque chiedere costi poco ma sbagliare costi caro. Dove un’ipotesi sbagliata è costosa e una domanda è facile, chiede; ovunque altrove registra le letture pesate e prosegue invece di forzare un impegno prematuro.

Sei domande dirette, non di più

Un budget rigido

L’intervista piatta è limitata a sei domande in totale. Tre sono universali, poste per ogni forma: il runtime in cui il prompt verrà eseguito, una definizione di fatto verificabile, e il contesto di deployment — l’ultimo omesso quando la richiesta lo rende già ovvio. Le restanti due o tre sono tratte dalla forma dedotta, mirando ai vuoti che quella forma lascia aperti in modo specifico. Se una domanda di disambiguazione è sopravvissuta dalla Fase 1, anch’essa conta sul budget; c’è un solo tetto, e tutto attinge da esso.

Il tetto è tolto solo per i passaggi di co-autoraggio più ricchi — la catena di workflow, il grader LLM-as-judge e il team multi-agente — dove la decomposizione, le ancore di calibrazione o l’elenco dei ruoli è essa stessa la decisione a più alta leva e una lista piatta produrrebbe risposte superficiali. Quei passaggi propongono prima un candidato e poi lo affinano, invece di sollecitare una specifica a freddo.

Come vengono poste le domande

Quattro regole governano il modo di chiedere, e ognuna si guadagna il posto proteggendo le risposte. Le domande escono una per turno, perché un turno affollato di più domande produce con regolarità risposte più superficiali a tutte. Tutto ciò che la richiesta ha già risposto viene saltato, perché ri-chiederlo scarta informazione che l’autore ha già dato. La domanda più ampia viene per prima, perché la prima risposta fissa il sottospazio entro cui opera ogni domanda successiva. E attraverso tutte, il framework propende per il silenzio ovunque un’ipotesi sbagliata sia facile da fare e da correggere, spendendo le sue scarse domande solo dove sbagliare costerebbe caro.

• Una domanda per turno — Una sola domanda per turno mantiene ponderata ogni risposta; i turni multi-domanda barattano profondità per l’illusione di velocità.
• Salta ciò che è già risposto — Tutto ciò che la richiesta ha già specificato o chiaramente implicato non viene mai richiesto, poiché ri-chiederlo distrugge l’informazione fornita dall’autore.
• Prima la cornice più ampia — Ambito e persona sono fissati prima di formato e casi limite, perché la prima risposta seleziona il sottospazio che le più strette poi affinano.
• Preserva l’ambiguità che costa poco — Una domanda è spesa solo dove un’ipotesi sbagliata è costosa; dove costa poco, la lettura è registrata e lasciata aperta invece che forzata.

Instradamento per tipo di incognita

Non ogni vuoto è colmabile con una domanda, quindi quando l’intento è poco chiaro il framework chiede prima che tipo di incognita ha di fronte e instrada di conseguenza. L’intervista gestisce solo la prima delle quattro; le altre tre mandano il lavoro da qualche parte più economica o più densa di una conversazione prima che qualsiasi stesura cominci.

• Una domanda aperta che l’autore custodisce — Quando l’autore conosce la domanda che ha, l’intervista stessa la risolve — è il caso ordinario per cui il budget di sei domande è dimensionato.
• «Lo riconoscerò quando lo vedrò» — Un criterio che l’autore non sa verbalizzare è instradato a una misurazione economica fuori dal prompt — un prototipo usa-e-getta o un brainstorming di varianti a cui reagire — prima della stesura.
• Poca familiarità col dominio — Segnali che l’autore non sa ancora cosa chiedere attivano un passaggio sui punti ciechi che enumera le domande che non ha pensato di porre.
• Un requisito che resiste alle parole — Quando l’intento non può essere messo in parole, il framework chiede un artefatto di riferimento — codice sorgente più di ogni altra cosa — come il modo più denso disponibile per trasferirlo.

Il collasso di riepilogo

L’intervista non può scivolare in silenzio nella stesura. Deve chiudersi con un collasso di riepilogo: una riformulazione della forma dedotta, dei vincoli raccolti e di ogni default che il framework ha assegnato nel silenzio dell’autore, restituita per un singolo giro di correzione. Un collasso eseguito in silenzio butterebbe via esattamente l’informazione di cui il progettista — e, più avanti, chiunque gestisca l’agente — avrebbe bisogno; renderlo esplicito trasforma il passo di misura in qualcosa che l’autore può vedere e correggere.

I banchi di domande per forma e le regole di conduzione della Fase 2.

06 PIPELINE · SCAFFOLD IN PHASE 3

Reasoning & Cognitive Tools

Source: references/cognitive-tools.md · assets/cognitive-tools.json

Some prompts need more than a single instruction-and-example shape: they need to scaffold the model's reasoning into discrete, named steps. The framework's reasoning layer is a sub-pattern, not one of the seven shapes. It is invoked inside a shape — inside a one-shot task, a workflow stage, a sub-agent, an LLM-as-judge, or a checkpoint of an agentic loop — wherever the reasoning itself is the bottleneck. When the scaffold is triggered, the framework emits a system prompt plus four tool definitions as copy-and-paste artifacts that you register in your own tool-calling runtime; the framework does not execute the tools itself, and nothing in the pattern requires it to hold tools of its own. The empirical advantage comes from you wiring the per-tool system prompts into your runtime's tool execution.

Hard-reasoning detection is gated by tier

During shape inference the framework watches the request for hard-reasoning signals: mathematical or logical tasks, multi-step planning, code analysis, several simultaneous constraints, or an author's report that the model fails on the first try. Two or more such signals would ordinarily make the cognitive-tools scaffold a structural default rather than an optional extra — the signals trigger inclusion automatically during drafting. But that default is not unconditional: it is conditioned on the substrate capability tier.

The published gains were measured on the model generations available at publication — what the framework's substrate axis calls the legacy and strong tiers — and the result has not been demonstrated on frontier-tier substrates. On a frontier substrate, vendor guidance points the other way: brief general instructions tend to beat prescriptive step-by-step decomposition, and an over-prescriptive scaffold can degrade output quality. So the rule is narrowed to exactly the scope it was actually measured on. This is the clearest instance in the framework of an empirical claim being held to its measured envelope rather than generalized past it.

Verbatim — cognitive-tools.md, tier gating

“Legacy and strong: two or more signals plus a tool-calling runtime → the scaffold is the draft's structural default. Frontier: an M5-gated option — only on a reported first-try failure or explicit request; otherwise a brief general reasoning instruction ("think thoroughly, verify before answering"); if shipped on frontier, say the evidence doesn't cover that tier.”

When a scaffold is shipped onto a frontier substrate anyway, the delivery must note that the empirical evidence does not cover that tier — the honesty discipline that runs throughout the framework applies here too.

The four cognitive tools

The pattern defines a small set of cognitive operations as modular tool calls. Each tool is a separate LLM invocation carrying a role-prompt that isolates one cognitive operation; the main reasoning model decides when to invoke which tool, and each tool's structured output flows back into the main loop. Modularity is the load-bearing property — the source reports that modular tools consistently beat a single monolithic reasoning prompt, because each tool runs in a sandboxed context with only the inputs it needs, reducing interference. Naming the operations also gives the model explicit permission to backtrack.

understand_question

Restates what is being asked, identifies the goal, surfaces assumptions, names the unknowns, and extracts the relevant symbols and variables. It does not answer.

recall_related

Surfaces two or three similar problems with full solutions as analogical examples. It does not solve the current problem.

examine_answer

Given the current reasoning trace, verifies it against the problem's constraints — catching miscalculations, wrong assumptions, and missing edge cases. It critiques rather than answers.

backtracking

Given a flawed trace, identifies where the first error occurred and proposes a revision from that point — or a fresh strategy when the whole approach was invalid.

The recommended default is to enable all four; if you are optimizing token economy on a strong reasoner, test which subset suffices, since the per-model gains vary widely across tools.

Where it fits — and where it does not

The scaffold earns its cost — extra tokens, latency, and a runtime that supports tool calling — on hard multi-step reasoning, on tasks whose answer space has dead ends so backtracking matters, on tasks where verifying an answer is far easier than producing it, and on high-stakes single-shot work. It is not worth the cost for simple extraction or classification, for open-ended creative generation (where backtracking has no verifiable target), for latency-sensitive paths, or on any runtime without tool calling — there the pattern degenerates into weaker monolithic prompting.

Across the seven shapes the fit is uneven. It is the primary, default choice for a hard-reasoning one-shot task (Shape 2). Inside a workflow (Shape 3) it belongs in a single hard stage — synthesis or decision — not in every stage, because the overhead compounds. In an agentic loop (Shape 1) it lives inside the individual checkpoints where reasoning is hard, never in the loop scaffolding itself. A sub-agent (Shape 4) uses it only when its job is itself reasoning-heavy, and a system persona (Shape 5) generally does not, since personas govern behavior over time rather than a single reasoning episode.

The judge case (Shape 6) turns on a distinction the framework reuses from Shape 2. Evaluative judges — open-ended quality assessment where the score has to be discovered — are a strong fit. Checklist verifiers, whose items are each directly checkable against the artifact, are not: the decomposition is already done, and adding cognitive tools is ceremony. The test is whether scoring an item requires discovering a judgment or merely checking presence against evidence; a mixed judge scopes the tools to its evaluative items only. In an agent team (Shape 7) the tools apply per role, not at the team level.

Operator profile and the reasoning-channel guard

In the framework's operator vocabulary the pattern is strong for hard reasoning and mid otherwise. It amplifies structured decomposition, explicit verification, and a willingness to backtrack; it suppresses premature commitment, monolithic forward-only reasoning, and outputs that look confident but are wrong. It is placed after the constraints and before the output format, and it is non-commutative with that format: if the output format comes first, the model tends to jump straight to the format and skip the reasoning structure entirely.

The scaffold is also designed to pass the audit's reasoning-channel check (M6). Each tool emits structured intermediate work as tool results — a sanctioned output channel — and nothing in it instructs the model to transcribe its internal thinking as response text, which on some substrates both conflates the reasoning and output channels and can trip a refusal. This is distinct from M4, the sibling blocking check: a cognitive-tools scaffold that is described but not actually shipped gives the author the framing of modular reasoning without its substance, and is treated as a defect.

The paper publishes the exact prompts that produced its results, and the framework ships them verbatim because the empirical claim depends on them. You adapt the domain framing (the published prompts target math; the structure generalizes) but preserve the operational specifics. The orchestrator system prompt that wires the four tools together:

You are an expert assistant who solves problems thoughtfully and effectively. You have access to a list of tools — these are functions that you can call to help you reason through or solve the problem more efficiently.

You are encouraged to use tools when they make the task easier, clearer or more robust — especially for complex, elaborated or ambiguous questions.

Use your best judgment to decide when to call tools.

You may call tools at any point in your reasoning process. Only use the tools listed below. If you choose to use a tool, describe your reasoning and clearly call it using their name.

You can solve problems however you find most appropriate.

When you are ready to provide the final answer to the problem or the question always follow the syntax: 'ANSWER: answer'.

You only have access to these tools, do not use any others:
{{cognitive_tools_signature}}

Here are the rules you should always follow to solve your task:
1. **Call a tool when needed.** If you call a tool, only use the available ones and use its full name to do so.
2. **Don't give up!** You're in charge of solving the problem.
3. Do not give an answer without reasoning about it.
4. **Never hallucinate results.** Wait for tool responses before continuing.
5. **Only write your final answer** after you are confident, and always in the form: 'ANSWER: your final answer here'.

If the question is already clear, you may skip the 'understand_question' step when the corresponding tool is available. But when unsure, it's good practice to use it.

Now Begin!

The constant across every runtime — Anthropic, OpenAI, Gemini, or a local model with function calling — is that each per-tool system prompt must reach the model that executes that tool. Where a runtime does not pass a tool's description through as a system prompt (most do not), your wrapper code must do it; registering the tools without wiring their system prompts is the most common deployment failure and yields tool-call routing without the modularity benefit.

06 PIPELINE · SCAFFOLD IN FASE 3

Ragionamento e strumenti cognitivi

Fonte: references/cognitive-tools.md · assets/cognitive-tools.json

Alcuni prompt hanno bisogno di più di una singola forma istruzione-ed-esempio: devono impalcare il ragionamento del modello in passi discreti e nominati. Il livello di ragionamento del framework è un sotto-schema, non una delle sette forme. È invocato dentro una forma — dentro un compito one-shot, uno stadio di workflow, un sub-agente, un LLM-as-judge o un checkpoint di un ciclo agentico — ovunque il ragionamento stesso sia il collo di bottiglia. Quando lo scaffold è attivato, il framework emette un prompt di sistema più quattro definizioni di strumenti come artefatti copia-e-incolla che registri nel tuo runtime con tool-calling; il framework non esegue gli strumenti da sé, e nulla nello schema richiede che ne possieda di propri. Il vantaggio empirico viene dal fatto che sei tu a collegare i prompt di sistema per-strumento all’esecuzione degli strumenti del tuo runtime.

La rilevazione del ragionamento difficile è regolata dal livello

Durante l’inferenza della forma il framework osserva nella richiesta i segnali di ragionamento difficile: compiti matematici o logici, pianificazione a più passi, analisi di codice, più vincoli simultanei, o la segnalazione dell’autore che il modello fallisce al primo tentativo. Due o più segnali di questo tipo di norma renderebbero lo scaffold di strumenti cognitivi un default strutturale invece di un extra opzionale — i segnali attivano l’inclusione automaticamente durante la stesura. Ma quel default non è incondizionato: è condizionato al livello di capacità del substrato.

I guadagni pubblicati sono stati misurati sulle generazioni di modelli disponibili alla pubblicazione — ciò che l’asse del substrato del framework chiama i livelli legacy e strong — e il risultato non è stato verificato su substrati di livello frontier. Su un substrato frontier, le indicazioni dei fornitori puntano nel senso opposto: istruzioni generali brevi tendono a battere la decomposizione prescrittiva passo-passo, e uno scaffold troppo prescrittivo può degradare la qualità dell’output. Perciò la regola è ristretta esattamente all’ambito su cui è stata effettivamente misurata. È l’istanza più chiara nel framework di un’affermazione empirica tenuta al suo intervallo misurato invece che generalizzata oltre.

Testuale — cognitive-tools.md, gating per livello

“Legacy and strong: two or more signals plus a tool-calling runtime → the scaffold is the draft's structural default. Frontier: an M5-gated option — only on a reported first-try failure or explicit request; otherwise a brief general reasoning instruction ("think thoroughly, verify before answering"); if shipped on frontier, say the evidence doesn't cover that tier.”

Quando uno scaffold viene comunque consegnato su un substrato frontier, la consegna deve annotare che l’evidenza empirica non copre quel livello — la disciplina di onestà che percorre tutto il framework si applica anche qui.

I quattro strumenti cognitivi

Lo schema definisce un piccolo insieme di operazioni cognitive come chiamate a strumenti modulari. Ogni strumento è una invocazione LLM separata che porta un role-prompt che isola una sola operazione cognitiva; il modello di ragionamento principale decide quando invocare quale strumento, e l’output strutturato di ogni strumento rientra nel loop principale. La modularità è la proprietà portante — la fonte riferisce che gli strumenti modulari battono con costanza un singolo prompt di ragionamento monolitico, perché ogni strumento gira in un contesto isolato con solo gli input che gli servono, riducendo l’interferenza. Nominare le operazioni dà anche al modello il permesso esplicito di tornare indietro.

understand_question

Riformula ciò che viene chiesto, individua l’obiettivo, fa emergere le assunzioni, nomina le incognite ed estrae i simboli e le variabili rilevanti. Non risponde.

recall_related

Fa emergere due o tre problemi simili con soluzioni complete come esempi analogici. Non risolve il problema corrente.

examine_answer

Data la traccia di ragionamento corrente, la verifica rispetto ai vincoli del problema — cogliendo errori di calcolo, assunzioni sbagliate e casi limite mancanti. Critica invece di rispondere.

backtracking

Data una traccia difettosa, individua dove si è verificato il primo errore e propone una revisione da quel punto — o una strategia nuova quando l’intero approccio era invalido.

Il default consigliato è abilitarli tutti e quattro; se stai ottimizzando l’economia dei token su un reasoner forte, prova quale sottoinsieme basti, dato che i guadagni per modello variano molto tra gli strumenti.

Dove si adatta — e dove no

Lo scaffold si guadagna il suo costo — token extra, latenza e un runtime che supporta il tool-calling — sul ragionamento difficile a più passi, su compiti il cui spazio delle risposte ha vicoli ciechi per cui il backtracking conta, su compiti dove verificare una risposta è molto più facile che produrla, e sul lavoro one-shot ad alta posta. Non vale il costo per estrazione o classificazione semplici, per la generazione creativa aperta (dove backtracking non ha un bersaglio verificabile), per percorsi sensibili alla latenza, o su qualunque runtime senza tool-calling — lì lo schema degenera in un prompting monolitico più debole.

Attraverso le sette forme l’adattamento è disomogeneo. È la scelta primaria e predefinita per un compito one-shot di ragionamento difficile (Forma 2). Dentro un workflow (Forma 3) appartiene a un singolo stadio difficile — sintesi o decisione — non a ogni stadio, perché l’overhead si accumula. In un ciclo agentico (Forma 1) vive dentro i singoli checkpoint dove il ragionamento è difficile, mai nell’impalcatura del loop stessa. Un sub-agente (Forma 4) lo usa solo quando il suo compito è esso stesso ricco di ragionamento, e una persona di sistema (Forma 5) di norma no, poiché le persone governano il comportamento nel tempo più che un singolo episodio di ragionamento.

Il caso del giudice (Forma 6) ruota attorno a una distinzione che il framework riusa dalla Forma 2. I giudici valutativi — valutazione di qualità aperta dove il punteggio va scoperto — sono un buon abbinamento. I verificatori a checklist, i cui item sono ciascuno direttamente controllabile contro l’artefatto, non lo sono: la decomposizione è già fatta, e aggiungere strumenti cognitivi è cerimonia. Il test è se valutare un item richieda di scoprire un giudizio o soltanto di controllare la presenza contro l’evidenza; un giudice misto limita gli strumenti ai soli item valutativi. In un team di agenti (Forma 7) gli strumenti si applicano per ruolo, non a livello di team.

Profilo dell’operatore e la guardia del canale di ragionamento

Nel vocabolario di operatori del framework lo schema è forte per il ragionamento difficile e medio altrimenti. Amplifica la decomposizione strutturata, la verifica esplicita e la disponibilità a tornare indietro; sopprime l’impegno prematuro, il ragionamento monolitico solo-in-avanti e gli output che sembrano sicuri ma sono sbagliati. È collocato dopo i vincoli e prima del formato di output, ed è non commutativo con quel formato: se il formato di output viene prima, il modello tende a saltare dritto al formato e a saltare del tutto la struttura di ragionamento.

Lo scaffold è anche progettato per passare il controllo del canale di ragionamento dell’audit (M6). Ogni strumento emette il lavoro intermedio strutturato come tool result — un canale di output sancito — e nulla in esso istruisce il modello a trascrivere il proprio pensiero interno come testo di risposta, cosa che su alcuni substrati sia confonde i canali di ragionamento e output sia può far scattare un rifiuto. Questo è distinto da M4, il controllo bloccante fratello: uno scaffold di strumenti cognitivi che è descritto ma non effettivamente consegnato dà all’autore la cornice del ragionamento modulare senza la sua sostanza, ed è trattato come un difetto.

Il paper pubblica i prompt esatti che hanno prodotto i suoi risultati, e il framework li consegna testualmente perché l’affermazione empirica dipende da essi. Adatti la cornice di dominio (i prompt pubblicati puntano alla matematica; la struttura generalizza) ma preservi le specifiche operative. Il prompt di sistema dell’orchestratore che collega i quattro strumenti:

You are an expert assistant who solves problems thoughtfully and effectively. You have access to a list of tools — these are functions that you can call to help you reason through or solve the problem more efficiently.

You are encouraged to use tools when they make the task easier, clearer or more robust — especially for complex, elaborated or ambiguous questions.

Use your best judgment to decide when to call tools.

You may call tools at any point in your reasoning process. Only use the tools listed below. If you choose to use a tool, describe your reasoning and clearly call it using their name.

You can solve problems however you find most appropriate.

When you are ready to provide the final answer to the problem or the question always follow the syntax: 'ANSWER: answer'.

You only have access to these tools, do not use any others:
{{cognitive_tools_signature}}

Here are the rules you should always follow to solve your task:
1. **Call a tool when needed.** If you call a tool, only use the available ones and use its full name to do so.
2. **Don't give up!** You're in charge of solving the problem.
3. Do not give an answer without reasoning about it.
4. **Never hallucinate results.** Wait for tool responses before continuing.
5. **Only write your final answer** after you are confident, and always in the form: 'ANSWER: your final answer here'.

If the question is already clear, you may skip the 'understand_question' step when the corresponding tool is available. But when unsure, it's good practice to use it.

Now Begin!

La costante su ogni runtime — Anthropic, OpenAI, Gemini o un modello locale con function calling — è che il system prompt di ciascuno strumento deve arrivare al modello che esegue quello strumento. Dove un runtime non passa la descrizione di uno strumento come system prompt (la maggior parte non lo fa), deve farlo il tuo codice di raccordo; registrare gli strumenti senza collegare i loro system prompt è l’errore di deployment più comune e produce l’instradamento delle chiamate agli strumenti senza il beneficio della modularità.

07 PIPELINE · PHASES 4 & 5

Audit & Evaluation

Two passes stand between a finished draft and delivery, and they do different work. Phase 4 runs a checklist that catches structural and behavioral failures — the things that make a prompt wrong rather than merely mediocre. Phase 5 then scores what the checklist deliberately does not cover, on three axes, under an explicit instruction to be honest rather than generous. The audit is not a rubber stamp: it is where the framework turns adversarial against its own output.

Phase 4 · the checklist

The checklist runs the drafted prompt through checks A–O and the gated M-series (M2–M6). It is structural and behavioral, not stylistic: it asks whether each directive sits at the right altitude between brittle hardcoding and vague hand-waving, whether every section spends the smallest viable set of tokens, whether load-bearing rules carry a worked example beside them, whether each section's operator profile — what it amplifies, suppresses, and mixes — is articulated, whether the ordering runs from strongest operator to final format, whether adjacent operators interfere destructively, and whether critical context is preserved rather than pre-collapsed. The M-series adds the measurement checks the classical list omits, including one that flags any instruction telling a model to transcribe its internal reasoning as output.

How hard a finding bites depends on where the prompt came from. Auditing a from-scratch draft — the framework's own output — it assumes intent: every section was added deliberately, so a failure is a real defect to fix and re-audit. Auditing a user-supplied prompt in refactor mode, it cannot tell which sections are deliberate, which constraints reflect external requirements, or which apparent weaknesses are load-bearing for reasons it cannot see; it runs the same checks but treats the results as candidates for the user's review rather than blocking issues, because the user knows things about their prompt the framework does not.

The checks that encode the strongest opinions

Three M-series checks are where the framework holds its hardest line — each guards a failure mode the framework is itself most prone to.

Cognitive-tools completeness

M4 · Blocking

If hard-reasoning signals triggered the cognitive-tools scaffold, all four tool definitions must be present in the delivered artifact, not merely named in prose. A prompt that describes the pattern without shipping the tools gives the author cognitive framing without cognitive substance — the one outcome the framework will never deliver.

Scaffold restraint

M5 · Restraint

The framework applies its own smallest-viable-token discipline to its own generative tendency. Every optional scaffold must trace to a specific, named trigger — a fired signal, a cited answer, a stated stake. “It might help” is not a trigger. The test: would an engineer hand-writing this prompt include this scaffold, or is it here only because the framework had it on the shelf?

Reasoning-channel separation

M6 · Channel

Telling a model to echo its internal thinking as response text conflates two channels and trips a refusal category on some runtimes. It is flagged as a defect — but carefully distinguished from a task-mandated justification field, such as a judge's written reasoning before a score, which is legitimate output on every runtime.

Phase 5 · scored honestly, then restrained

Once the checklist has caught the structural failures, evaluation scores the draft from one to ten on three axes the checklist does not cover. The rule that governs the whole pass is a hard one — “be honest, not generous” — because an inflated score hurts the author more than a low one: a seven with a named gap tells them whether to iterate or ship, while a padded nine costs them the next session.

Token economy

Are the tokens spent buying behaviors that matter? A top score means every section addresses a specific failure mode or enables a concrete behavior, examples are load-bearing, and no preemptive edge case or ritual structure survives.

Task fit

Does the prompt cover what the user actually needs delivered — not only the immediate build but the downstream needs it implies, such as a reviewer audience, an audit trail, or calibration data? Deductions and credits are tuned per shape.

Operator coherence

Do the sections work as one coordinated transformation, or a loose collection? A top score means ordering reflects operator strength, interference pairs are examined and resolved, every section has a clear profile, and nothing is decoration.

Scoring is also where scaffold restraint runs: the framework lists every optional scaffold it added alongside its one-line trigger, and strikes any that exist only because the machinery was available. And it does not ship silently past a weak score — a score below six must be named and offered a fix rather than quietly delivered; if two or more axes fall below seven, the framework proposes a revision pass the author can decline but should at least see.

A deliberate correction against its own bias. The temptation to award a high score grows with the effort already spent, so the rubric builds in a sunk-cost correction: after several revisions the framework's perception is upward-biased and it adjusts down, scores the artifact rather than the author's mood during drafting, and when tempted to write a nine asks what a ten would look like — if that answer is concrete and reachable, the draft is not a nine yet.

The empirical extension is authored, not run

For high-stakes prompts the audit can offer a measured score on top of the heuristic one — a fidelity test across two section orderings, an interference test on a suspect pair, a variance sweep across temperatures. These cost real model calls, so the framework writes them for the human to run rather than executing N samples itself, and reserves them for prompts that will run thousands of times; for a one-off task they are skipped.

Evidence — what was measured

No measured change.

PASS² 0.644 (v3) · 0.622 (v2) · 32 RUNS · BLIND GRADERS · SIGN TEST p = 1.000 · 15 v2-TAGGED ASSERTIONS · BOTH VERSIONS AT 7/15

On output quality the v3 refactor is a null result: it did not change what the prompts produce.

The instrument held: v2 reproduced its own earlier number in the same session, 0.622 vs 0.625.

SOURCE · prometheus-lab harness, head-to-head run, Sept 2026 (W6 report)

65 k → 43.5 k tokens.

What v3 bought: the skill is a third cheaper to load (−33 %), with no measured loss in quality.

A cost result, not a quality gain — and still above the 40 k cap, by choice.

SOURCE · prometheus-lab check_skill.py gate, before/after v3

250 rules · 0 absent.

The refactor was verified rule by rule: 57 dilutions found, all 57 repaired.

237 rules checked in fresh context, 13 mechanically — this verifies the refactor, not your prompts.

SOURCE · prometheus-lab rules-v3.yaml + check_rules_anchors.py, Sept 2026

This site makes no superiority claims: the only figure that improved is cost, and it is shown as cost.

07 PIPELINE · FASI 4 E 5

Audit e valutazione

Due passaggi stanno tra una bozza finita e la consegna, e fanno lavori diversi. La Fase 4 esegue una checklist che coglie i fallimenti strutturali e comportamentali — le cose che rendono un prompt sbagliato più che semplicemente mediocre. La Fase 5 poi valuta ciò che la checklist deliberatamente non copre, su tre assi, sotto l’istruzione esplicita di essere onesta invece che generosa. L’audit non è un timbro di gomma: è dove il framework si volge avversario contro il proprio output.

Fase 4 · la checklist

La checklist fa passare il prompt in bozza attraverso i controlli da A a O e la serie M condizionata (M2–M6). È strutturale e comportamentale, non stilistica: chiede se ogni direttiva sia alla giusta altitudine tra hardcoding fragile e vago sventolare le mani, se ogni sezione spenda il minimo insieme di token praticabile, se le regole portanti portino un esempio svolto accanto, se il profilo di operatore di ogni sezione — ciò che amplifica, sopprime e mescola — sia articolato, se l’ordine corra dall’operatore più forte al formato finale, se operatori adiacenti interferiscano in modo distruttivo, e se il contesto critico sia preservato invece che pre-collassato. La serie M aggiunge i controlli di misura che la lista classica omette, incluso uno che segnala qualsiasi istruzione che dica a un modello di trascrivere il proprio ragionamento interno come output.

Quanto duramente morde un rilievo dipende da dove viene il prompt. Facendo l’audit di una bozza da zero — l’output del framework stesso — assume l’intento: ogni sezione è stata aggiunta deliberatamente, quindi un fallimento è un vero difetto da correggere e ri-auditare. Facendo l’audit di un prompt fornito dall’utente in modalità refactor, non può dire quali sezioni siano deliberate, quali vincoli riflettano requisiti esterni, o quali debolezze apparenti siano portanti per ragioni che non può vedere; esegue gli stessi controlli ma tratta i risultati come candidati alla revisione dell’utente invece che come problemi bloccanti, perché l’utente sa cose sul proprio prompt che il framework non sa.

I controlli che codificano le opinioni più forti

Tre controlli della serie M sono dove il framework tiene la sua linea più dura — ognuno protegge un modo di fallimento a cui il framework stesso è più incline.

Completezza degli strumenti cognitivi

M4 · Bloccante

Se i segnali di ragionamento difficile hanno attivato lo scaffold di strumenti cognitivi, tutte e quattro le definizioni di strumento devono essere presenti nell’artefatto consegnato, non solo nominate nella prosa. Un prompt che descrive lo schema senza consegnare gli strumenti dà all’autore la cornice cognitiva senza la sostanza cognitiva — l’unico esito che il framework non consegnerà mai.

Moderazione degli scaffold

M5 · Moderazione

Il framework applica la propria disciplina del minimo token praticabile alla sua stessa tendenza generativa. Ogni scaffold opzionale deve risalire a un trigger specifico e nominato — un segnale scattato, una risposta citata, una posta dichiarata. «Potrebbe aiutare» non è un trigger. Il test: un ingegnere che scrivesse a mano questo prompt includerebbe questo scaffold, o è qui solo perché il framework ce l’aveva sullo scaffale?

Separazione del canale di ragionamento

M6 · Canale

Dire a un modello di riecheggiare il proprio pensiero interno come testo di risposta confonde due canali e fa scattare una categoria di rifiuto su alcuni runtime. È segnalato come difetto — ma accuratamente distinto da un campo di giustificazione richiesto dal compito, come il ragionamento scritto di un giudice prima di un punteggio, che è output legittimo su ogni runtime.

Fase 5 · valutata con onestà, poi moderata

Una volta che la checklist ha colto i fallimenti strutturali, la valutazione assegna alla bozza un punteggio da uno a dieci su tre assi che la checklist non copre. La regola che governa l’intero passaggio è dura — «sii onesto, non generoso» — perché un punteggio gonfiato ferisce l’autore più di uno basso: un sette con un vuoto nominato gli dice se iterare o consegnare, mentre un nove imbottito gli costa la sessione successiva.

Economia dei token

I token spesi comprano comportamenti che contano? Il punteggio massimo significa che ogni sezione affronta un modo di fallimento specifico o abilita un comportamento concreto, che gli esempi sono portanti e che nessun caso limite preventivo o struttura rituale è sopravvissuto.

Aderenza al compito

Il prompt copre ciò di cui l’utente ha davvero bisogno che sia consegnato — non solo la costruzione immediata ma i bisogni a valle che essa implica, come un pubblico di revisori, una traccia di audit o dati di calibrazione? Detrazioni e crediti sono tarati per forma.

Coerenza degli operatori

Le sezioni lavorano come un’unica trasformazione coordinata, o come una collezione slegata? Il punteggio massimo significa che l’ordine riflette la forza dell’operatore, che le coppie di interferenza sono esaminate e risolte, che ogni sezione ha un profilo chiaro e che nulla è decorazione.

La valutazione è anche dove gira la moderazione degli scaffold: il framework elenca ogni scaffold opzionale che ha aggiunto accanto al suo trigger di una riga, e cancella ognuno che esista solo perché la macchina era disponibile. E non consegna in silenzio oltre un punteggio debole — un punteggio sotto sei deve essere nominato e accompagnato da una proposta di correzione invece che consegnato in sordina; se due o più assi cadono sotto sette, il framework propone un passaggio di revisione che l’autore può rifiutare ma dovrebbe almeno vedere.

Una correzione deliberata contro il proprio bias. La tentazione di assegnare un punteggio alto cresce con lo sforzo già speso, quindi la rubrica incorpora una correzione da costo sommerso: dopo diverse revisioni la percezione del framework è distorta verso l’alto ed esso corregge al ribasso, valuta l’artefatto invece dell’umore dell’autore durante la stesura, e quando è tentato di scrivere un nove chiede come sarebbe un dieci — se quella risposta è concreta e raggiungibile, la bozza non è ancora un nove.

L’estensione empirica è scritta, non eseguita

Per i prompt ad alta posta l’audit può offrire un punteggio misurato sopra a quello euristico — un test di fedeltà su due ordinamenti di sezione, un test di interferenza su una coppia sospetta, una scansione di varianza tra le temperature. Questi costano chiamate reali al modello, quindi il framework li scrive perché l’umano li esegua invece di eseguire N campioni da sé, e li riserva ai prompt che gireranno migliaia di volte; per un compito una tantum vengono saltati.

Evidenze — cosa è stato misurato

Nessuna variazione misurata.

PASS² 0,644 (v3) · 0,622 (v2) · 32 ESECUZIONI · GRADER IN CIECO · SIGN TEST p = 1,000 · 15 ASSERZIONI MARCATE v2 · ENTRAMBE LE VERSIONI A 7/15

Sulla qualità dell’output il refactor v3 è un risultato nullo: non ha cambiato ciò che i prompt producono.

Lo strumento ha tenuto: la v2 ha riprodotto il proprio numero precedente nella stessa sessione, 0,622 contro 0,625.

FONTE · harness di prometheus-lab, confronto diretto, set. 2026 (report W6)

65 k → 43,5 k token.

Cosa ha portato la v3: la skill costa un terzo in meno da caricare (−33 %), senza perdita di qualità misurata.

Un risultato di costo, non un guadagno di qualità — e ancora sopra il tetto di 40 k, per scelta.

FONTE · gate check_skill.py di prometheus-lab, prima/dopo la v3

250 regole · 0 assenti.

Il refactor è stato verificato regola per regola: 57 diluizioni trovate, tutte e 57 riparate.

237 regole verificate in contesto fresco, 13 meccanicamente — verifica il refactor, non i tuoi prompt.

FONTE · rules-v3.yaml + check_rules_anchors.py di prometheus-lab, set. 2026

Questo sito non rivendica primati: l’unico dato migliorato è il costo, e lo presenta come costo.

08 PIPELINE · PHASE 6 · DELIVERY

Verification

Source: references/evals.md

Verification is the framework's closing discipline: a prompt is not finished when it reads well, but when it has been checked against a written statement of what would count as success. Two things travel with every delivered prompt for that reason — a verifier specification that says, separately from the prompt itself, what correct behavior is, and one or more runnable verifiers that exercise that specification. The recursive twist is that a verifier is itself just another prompt, so the framework builds it out of machinery it already owns rather than as a new subsystem.

What ships depends on the stakes

Delivery is conditioned on the run rather than fixed. Some pieces are always present: the prompt, a short usage note, the audit summary with its three-axis score, the verifier specification, and the static-mode verifier that inspects the prompt text without executing it. The heavier verifiers — the single-run verifier that judges one output, and the cross-run verifier that watches for calibration drift and distributional bias across many outputs — appear only when the stakes justify them, at production scale or high volume. Cognitive-tool definitions ship only when the drafting phase actually triggered them, and are formatted for the runtime the author named.

From-scratch delivery is not a fixed bundle. The pipeline can emit up to nine distinct artifacts, though most runs emit far fewer, and what ships is reported to the author as a scaffold-to-trigger list — the framework is built to justify its own additions rather than pad the delivery.

The three levels of a verifier specification

Static. Properties of the prompt artifact that can be judged without running it — section presence, schema validity, structural coherence. This largely mirrors the audit checklist, re-exposed as a re-runnable check.

Single-run. Properties of one output on one input — schema conformance, each named constraint satisfied, forbidden patterns absent, the author's named failure modes handled.

Cross-run. Properties over many outputs — calibration drift, distributional bias, edge-case coverage, consistency on identical inputs. Often empty for low-stakes prompts; often the most important level for anything in production.

The specification doubles as a cross-check on the prompt itself. A specification that comes out thin — fewer than a handful of single-run checks, no cross-run worth running — is a signal that the prompt may be under-specified, or genuinely simple. One so dense that running it would cost more than the prompt it guards signals over-engineering. Delivery guidance is likewise tuned to substrate and runtime: prefilling, once a default, is now emitted only as a legacy path for runtimes that still accept it, with an explicit-format instruction as the standard substitute.

Eating its own dogfood

The framework holds itself to the same bar it sets for others. Before shipping, it runs its own static-mode verifier against its own draft and refuses to deliver anything with a blocking failure — the discipline the source calls eating its own dogfood. If that self-check finds a blocking defect, such as a cognitive-tools scaffold that was described but never actually included, the artifact is not presented as finished; the problem is named and a revision offered. It is worth being candid that this guarantee is prompt-enforced, not mechanism-enforced: the refusal is an instruction to the executing agent, and nothing structural prevents a rushed run from skipping it.

The scaffold-to-trigger list

The self-check only earns trust if the artifact carries an honest account of what it actually contains, and that is the job of the scaffold-to-trigger list. A prompt is more than its prose: it may attach optional scaffolds — cognitive-tool definitions for hard reasoning, clarification-seeking behavior for interactive deployments, verifier prompts for consequential outputs — but each of those is supposed to appear only when a specific condition in the run called for it. The ledger is the running record that keeps that promise auditable: for every scaffold it names what was scaffolded and what its trigger was, so a reader can trace each attachment back to the condition that justified it rather than taking its presence on faith. A scaffold in the delivery with no trigger behind it, or a trigger that fired with no scaffold behind it, is exactly the kind of blocking discrepancy the dogfood gate is meant to catch.

That scaffold-to-trigger accounting extends into an honesty discipline the source calls the validated-versus-unchecked ledger. Every capability the delivery claims is tagged as one of two things and no third: tested, meaning a verifier actually exercised it and passed, or merely source-backed, meaning it rests on the framework's own reasoning but has not been run. The point of separating them is that the status travels with the delivery — the recipient is never left to guess which guarantees were checked and which are promissory. Read together, the two ledgers make the same commitment from two directions: the artifact states what it did, not merely what it aspires to, and it states so plainly enough that the claim can be checked against the record.

Mechanical versus judged verification

Not every property wants the same kind of checker, and one of the framework's cleaner seams runs exactly along that line. Properties that are decidable — whether an adaptation history replays byte-for-byte, whether a proposed change repeats one the ledger already recorded as a regression — are delegated to a deterministic runnable script. Properties that genuinely need judgment — whether a control-plane seam holds, whether persistence and write-ahead conditions are respected — go to a Shape 6 grader. That grader carries one firm rule: when the mechanical report it depends on is missing, it must abstain and mark the result UNVERIFIED rather than guess. Keeping the deterministic and the judged checks on opposite sides of this boundary is what lets each be trusted for what it actually establishes.

08 PIPELINE · FASE 6 · CONSEGNA

Verifica

Fonte: references/evals.md

La verifica è la disciplina di chiusura del framework: un prompt non è finito quando si legge bene, ma quando è stato controllato contro un enunciato scritto di ciò che conterebbe come successo. Per questa ragione due cose viaggiano con ogni prompt consegnato — una specifica del verificatore che dice, separatamente dal prompt stesso, cosa sia il comportamento corretto, e uno o più verificatori eseguibili che esercitano quella specifica. La torsione ricorsiva è che un verificatore è a sua volta solo un altro prompt, quindi il framework lo costruisce con macchina che già possiede invece che come un nuovo sottosistema.

Cosa viene consegnato dipende dalla posta in gioco

La consegna è condizionata all’esecuzione più che fissa. Alcuni pezzi sono sempre presenti: il prompt, una breve nota d’uso, il riepilogo di audit col suo punteggio a tre assi, la specifica del verificatore e il verificatore in modalità statica che ispeziona il testo del prompt senza eseguirlo. I verificatori più pesanti — quello su singola esecuzione che giudica un output, e quello cross-run che sorveglia la deriva di calibrazione e il bias distribuzionale su molti output — compaiono solo quando la posta li giustifica, a scala di produzione o ad alto volume. Le definizioni di strumenti cognitivi sono consegnate solo quando la fase di stesura le ha effettivamente attivate, e sono formattate per il runtime che l’autore ha nominato.

La consegna da zero non è un pacchetto fisso. La pipeline può emettere fino a nove artefatti distinti, anche se la maggior parte delle esecuzioni ne emette molti meno, e ciò che viene consegnato è riportato all’autore come una lista scaffold-to-trigger — il framework è fatto per giustificare le proprie aggiunte invece di gonfiare la consegna.

I tre livelli della specifica di un verificatore

Statico. Proprietà dell’artefatto-prompt giudicabili senza eseguirlo — presenza delle sezioni, validità di schema, coerenza strutturale. Rispecchia in gran parte la checklist di audit, ri-esposta come controllo ri-eseguibile.

Su singola esecuzione. Proprietà di un output su un input — conformità di schema, ogni vincolo nominato soddisfatto, pattern proibiti assenti, i modi di fallimento nominati dall’autore gestiti.

Cross-run. Proprietà su molti output — deriva di calibrazione, bias distribuzionale, copertura dei casi limite, coerenza su input identici. Spesso vuoto per prompt a bassa posta; spesso il livello più importante per qualunque cosa in produzione.

La specifica funge anche da controllo incrociato sul prompt stesso. Una specifica che risulta sottile — meno di una manciata di controlli su singola esecuzione, nessun cross-run che valga la pena eseguire — è un segnale che il prompt potrebbe essere sotto-specificato, o genuinamente semplice. Una così densa che eseguirla costerebbe più del prompt che protegge segnala sovra-ingegnerizzazione. Le indicazioni di consegna sono parimenti tarate su substrato e runtime: il prefilling, un tempo default, è ora emesso solo come percorso legacy per i runtime che ancora lo accettano, con un’istruzione a formato esplicito come sostituto standard.

Fare dogfooding sul proprio output

Il framework si tiene alla stessa asticella che fissa per gli altri. Prima di consegnare, esegue il proprio verificatore in modalità statica sulla propria bozza e rifiuta di consegnare qualsiasi cosa con un fallimento bloccante — la disciplina che la fonte chiama fare dogfooding sul proprio output. Se quell’auto-controllo trova un difetto bloccante, come uno scaffold di strumenti cognitivi descritto ma mai effettivamente incluso, l’artefatto non è presentato come finito; il problema è nominato e una revisione offerta. Vale la pena essere candidi sul fatto che questa garanzia è imposta dal prompt, non dal meccanismo: il rifiuto è un’istruzione all’agente che esegue, e nulla di strutturale impedisce a un’esecuzione frettolosa di saltarlo.

La lista scaffold-to-trigger

L’auto-controllo si guadagna fiducia solo se l’artefatto porta un resoconto onesto di ciò che effettivamente contiene, ed è il compito della lista scaffold-to-trigger. Un prompt è più della sua prosa: può allegare scaffold opzionali — definizioni di strumenti cognitivi per il ragionamento difficile, comportamento di richiesta di chiarimenti per deployment interattivi, prompt verificatori per output conseguenti — ma ognuno di essi dovrebbe comparire solo quando una condizione specifica nell’esecuzione lo richiedeva. Il registro è la traccia corrente che tiene quella promessa verificabile: per ogni scaffold nomina cosa è stato aggiunto e qual era il suo trigger, così un lettore può risalire da ogni allegato alla condizione che l’ha giustificato invece di prenderne la presenza per fede. Uno scaffold nella consegna senza un trigger dietro, o un trigger scattato senza uno scaffold dietro, è esattamente il tipo di discrepanza bloccante che il gate del dogfood deve cogliere.

Quella contabilità scaffold-to-trigger si estende in una disciplina di onestà che la fonte chiama il registro validato-contro-non-verificato. Ogni capacità che la consegna dichiara è etichettata come una di due cose e nessuna terza: testata, cioè un verificatore l’ha effettivamente esercitata ed è passata, o soltanto sostenuta dalle fonti, cioè poggia sul ragionamento del framework ma non è stata eseguita. Il senso di separarle è che lo stato viaggia con la consegna — il destinatario non è mai lasciato a indovinare quali garanzie fossero controllate e quali siano promesse. Letti insieme, i due registri fanno lo stesso impegno da due direzioni: l’artefatto enuncia ciò che ha fatto, non solo ciò a cui aspira, e lo enuncia abbastanza chiaramente da poter essere controllato contro la traccia.

Verifica meccanica contro verifica giudicata

Non ogni proprietà vuole lo stesso tipo di controllore, e una delle giunture più pulite del framework corre esattamente lungo quella linea. Le proprietà decidibili — se una storia di adattamento si riesegue byte-per-byte, se una modifica proposta ripete una che il registro ha già annotato come regressione — sono delegate a uno script eseguibile deterministico. Le proprietà che hanno davvero bisogno di giudizio — se una giuntura del piano di controllo regge, se le condizioni di persistenza e di write-ahead sono rispettate — vanno a un grader di Forma 6. Quel grader porta una regola ferma: quando il report meccanico da cui dipende manca, deve astenersi e marcare il risultato UNVERIFIED invece di tirare a indovinare. Tenere i controlli deterministici e quelli giudicati su lati opposti di questo confine è ciò che permette di fidarsi di ciascuno per quello che effettivamente stabilisce.

09 LIFECYCLE · MANAGE

Manage Mode

Manage mode is the third of the framework's procedures. Where from-scratch designs an agent and refactor reshapes a single prompt, manage mode runs an agent across its whole lifetime — always between its runs, never driving it live: it monitors the agent's runs, analyzes goal violations, plans an adaptation, and executes it at one controlled seam, then remembers what it did so it does not repeat a mistake. It adds almost no new analytical machinery; it schedules the machinery the other modes already own — the audit checklist, refactor mode, the cross-run verifier — into four canonical phases. Throughout, the agent's prompt is treated as an operator Ôᵥ, and an adaptation is simply the manager producing the next version Ôᵥ₊₁.

Everything a managed agent is lives in one directory, the managed-agent package. Inside it, Knowledge (K) is the file-backed state the four phases share — split into the semantic-state model of the current prompt (managed-system.yaml), the environment model of aggregated run facts (environment.yaml), the goals model (goals.yaml), the ordered adaptation ledger (ledger.md), and transient working models. A goal counts as well-formed only when it pins three things: an observable, an observer — the measurement operator that reads it — and an aggregation. Because meaning is observer-dependent, “the agent succeeded” is a property of a transcript and a measurement together, never of the transcript alone.

A sharp seam runs through that package — the framework's cleanest one in manage mode. The prompt, tools, and knowledge files are manager-owned: the control plane the manager rewrites. The agent's own memory/ is agent-owned: the data plane, which the manager reads as a probe but never hand-edits. Keeping the two apart is what lets the manager steer the agent between runs without the agent knowing, while still leaving it a persistent memory of its own.

An agent, forged and kept alive

As the Titan Prometheus shaped humankind and gave it fire to stay alive, Prometheus forges agents — and hands them the structure that keeps them alive.

Prometheus builds the agent from ordered operators, then stays on as its manager — watching each run and re-forging the agent so it keeps growing.

• Born — from ordered operators
• Grows — it runs in the world
• Learns — from its own runs

An agent’s nature is its text

The idea draws inspiration from homoiconicity — where a program and its data share one form. Not literally so here, but close in spirit: in an agentic runtime, an agent is largely the text that defines it — its system prompt, its task specs, its memory. Build-time only: Prometheus never runs what it produces. Manage mode is the one exception — it runs only the managed agent, and adapts it between runs, never live.

Nothing is retrained. The agent evolves because the artifacts that define it are rewritten — the same text the runtime executes is the text Prometheus edits. One agent, evolving.

• I · Run — the agent acts on a real task, leaving a trace of how it behaved
• II · Read — between runs it reads that evidence — never judging by a single run
• III · Diagnose — pinpoints the drift and weighs candidate fixes
• IV · Re-forge — rewrites the control plane — prompt, tools, knowledge

vₙ → vₙ₊₁ — Always between runs, never driving the agent live: Prometheus owns the control plane; the agent keeps its own persistent memory.

The MAPE-K loop

This is the richest flow in the framework, and its discipline reduces to a single rule: K is the bloodstream. The four phases never call one another. Each reads from the Knowledge store and writes back to it, and the next phase reads only what the previous one persisted — because each pass is an irreversible measurement, and nothing survives it except what is written to K. The loop begins when enough runs have accumulated against the current version on an active agent; the agent is deactivated, its transcript flushed to runs/, and control enters the loop.

Monitor

Reads runs/ and goals.yaml and writes tomography facts — cluster probabilities, variance, failure-taxonomy counts — to environment.yaml. It reconstructs the distribution a version induces rather than reacting to any single run.

Analyze

Reads that environment model, the ledger.md prior, and the managed-system semantic-state model, and writes a weighted set of candidate edits to working/. It reasons over the operator model, never the raw prompt text, and keeps its options in superposition.

Plan

Collapses the candidate set to a single edit and writes it to working/ together with an interference re-check list for every section the edit touches. This is the deliberate measurement — the one place a choice is actually made.

Execute

The only writer. Entering the ADAPTING state, it logs a write-ahead ledger entry, snapshots the current prompt, persists the diff as a patch, applies it, re-audits, bumps the version, and updates the semantic-state model last.

The lifecycle state machine

The loop is allowed to write in exactly one place, and the lifecycle machine is what makes that checkable. Six states — UNCONFIGURED, CONFIGURED, ACTIVE, INACTIVE, ADAPTING, and the terminal FINALIZED — connect through named transitions. Effectors fire only inside ADAPTING; every other transition preserves the prompt's hash and version. Stop-and-restart is the same seam as adaptation: an agent that can be cleanly deactivated is, by construction, one that can be adapted. And a re-audit failure inside ADAPTING rolls back to the prior snapshot rather than leaving the machine in a dangling state, which is what keeps it closed.

The rules that keep it safe

Manage mode is governed by eight invariants, numbered I1–I7 and I9, and three runtime rules. The invariants are the standing contract — that every phase communicate only through K, that Execute log its ledger entry before it touches the prompt, that Execute stay human-gated unless an explicit bounded envelope in manifest.yaml says otherwise. The three runtime rules are the moment-to-moment decisions the loop makes as it runs.

Min-N gate

Never adapt on fewer than N accumulated runs against the current version. A single run is one sample of the distribution the prompt induces; reacting to it is reacting to measurement noise.

Anti-oscillation

Analyze may not re-propose an option the ledger records as having regressed against the same trigger. The mechanical verifier pre-filters on trigger-and-section; a grader judges intent.

Replay property

The first snapshot plus the ordered ledger diffs must reconstruct the current prompt exactly, byte for byte — the property that makes an adaptation history trustworthy and a rollback safe.

Refactor mode — the alternate path that manage mode schedules and reuses.

09 CICLO DI VITA · GESTIONE

Modalità gestione

La modalità manage è la terza delle procedure del framework. Dove from-scratch progetta un agente e refactor rimodella un singolo prompt, la modalità manage gestisce un agente lungo tutta la sua vita — sempre tra le sue esecuzioni, mai guidandolo dal vivo: ne monitora le esecuzioni, analizza le violazioni degli obiettivi, pianifica un adattamento e lo esegue a una giuntura controllata, poi ricorda cosa ha fatto per non ripetere un errore. Aggiunge quasi nessun nuovo meccanismo analitico; orchestra gli strumenti che le altre modalità già possiedono — la checklist di audit, la modalità refactor, il verificatore cross-run — in quattro fasi canoniche. In tutto ciò, il prompt dell’agente è trattato come un operatore Ôᵥ, e un adattamento è semplicemente il manager che produce la versione successiva Ôᵥ₊₁.

Tutto ciò che un agente gestito è vive in una sola cartella, il pacchetto-agente gestito. Al suo interno, la Conoscenza (K) è lo stato su file che le quattro fasi condividono — suddiviso nel modello di stato semantico del prompt corrente (managed-system.yaml), il modello d’ambiente dei fatti d’esecuzione aggregati (environment.yaml), il modello degli obiettivi (goals.yaml), il registro ordinato degli adattamenti (ledger.md), e modelli di lavoro transitori. Un obiettivo conta come ben formato solo quando fissa tre cose: un osservabile, un osservatore — l’operatore di misura che lo legge — e un’aggregazione. Poiché il significato dipende dall’osservatore, “l’agente ha avuto successo” è una proprietà di una trascrizione e di una misura insieme, mai della trascrizione da sola.

Una giuntura netta corre attraverso quel pacchetto — la più pulita del framework in modalità manage. Il prompt, gli strumenti e i file di conoscenza sono di proprietà del manager: il piano di controllo che il manager riscrive. La memory/ propria dell’agente è di proprietà dell’agente: il piano dati, che il manager legge come sonda ma non modifica mai a mano. Tenere i due separati è ciò che permette al manager di guidare l’agente tra le esecuzioni senza che l’agente lo sappia, lasciandogli comunque una memoria persistente propria.

Un agente, forgiato e mantenuto vivo

Come il Titano Prometeo plasmò l’umanità e le diede il fuoco per restare viva, Prometheus forgia gli agenti — e consegna loro la struttura che li tiene vivi.

Prometheus costruisce l’agente da operatori ordinati, poi resta come suo manager — osserva ogni esecuzione e ri-forgia l’agente perché continui a crescere.

• Nasce — da operatori ordinati
• Cresce — agisce nel mondo
• Impara — dalle proprie esecuzioni

La natura di un agente è il suo testo

L’idea prende ispirazione dall’omoiconicità — dove un programma e i suoi dati condividono una stessa forma. Qui non lo è alla lettera, ma lo è nello spirito: in un runtime agentico un agente è in larga parte il testo che lo definisce — il suo system prompt, le sue specifiche di task, la sua memoria. Solo in fase di build: Prometheus non esegue mai ciò che produce. La modalità manage è l’unica eccezione — esegue soltanto l’agente gestito, e lo adatta tra un’esecuzione e l’altra, mai dal vivo.

Nessun riaddestramento. L’agente evolve perché vengono riscritti gli artefatti che lo definiscono — lo stesso testo che il runtime esegue è il testo che Prometheus modifica. Un agente, in evoluzione.

• I · Esecuzione — l’agente agisce su un compito reale, lasciando traccia di come si è comportato
• II · Lettura — tra le esecuzioni legge quelle evidenze — senza mai giudicare da una sola
• III · Diagnosi — individua la deriva e valuta le correzioni candidate
• IV · Ri-forgiatura — riscrive il piano di controllo — prompt, strumenti, conoscenza

vₙ → vₙ₊₁ — Sempre tra un’esecuzione e l’altra, mai guidando l’agente dal vivo: Prometheus possiede il piano di controllo; l’agente conserva la propria memoria persistente.

Il ciclo MAPE-K

Questo è il flusso più ricco del framework, e la sua disciplina si riduce a una sola regola: K è il sistema circolatorio. Le quattro fasi non si chiamano mai l’un l’altra. Ognuna legge dallo store di Conoscenza e vi riscrive, e la fase successiva legge solo ciò che la precedente ha persistito — perché ogni passaggio è una misura irreversibile, e nulla vi sopravvive tranne ciò che è scritto in K. Il loop comincia quando abbastanza esecuzioni si sono accumulate contro la versione corrente su un agente attivo; l’agente è disattivato, la sua trascrizione svuotata in runs/, e il controllo entra nel loop.

Monitor

Legge runs/ e goals.yaml e scrive fatti di tomografia — probabilità dei cluster, varianza, conteggi della tassonomia dei fallimenti — in environment.yaml. Ricostruisce la distribuzione che una versione induce invece di reagire a una singola esecuzione.

Analyze

Legge quel modello d’ambiente, il prior del ledger.md e il modello di stato semantico del sistema gestito, e scrive un insieme pesato di modifiche candidate in working/. Ragiona sul modello a operatori, mai sul testo grezzo del prompt, e tiene le sue opzioni in sovrapposizione.

Plan

Collassa l’insieme candidato in una singola modifica e la scrive in working/ insieme a una lista di ri-controllo dell’interferenza per ogni sezione che la modifica tocca. Questa è la misura deliberata — l’unico punto in cui una scelta è davvero compiuta.

Execute

L’unico scrittore. Entrando nello stato ADAPTING, registra una voce di ledger in write-ahead, fa uno snapshot del prompt corrente, persiste il diff come patch, lo applica, ri-verifica, incrementa la versione e aggiorna per ultimo il modello di stato semantico.

La macchina a stati del ciclo di vita

Al loop è permesso scrivere in esattamente un punto, e la macchina del ciclo di vita è ciò che lo rende controllabile. Sei stati — UNCONFIGURED, CONFIGURED, ACTIVE, INACTIVE, ADAPTING, e il terminale FINALIZED — si connettono tramite transizioni nominate. Gli effettori scattano solo dentro ADAPTING; ogni altra transizione preserva l’hash e la versione del prompt. Fermare-e-riavviare è la stessa giuntura dell’adattamento: un agente che può essere disattivato in modo pulito è, per costruzione, uno che può essere adattato. E un fallimento di ri-audit dentro ADAPTING torna indietro allo snapshot precedente invece di lasciare la macchina in uno stato pendente, ed è questo a tenerla chiusa.

Le regole che lo tengono sicuro

La modalità manage è governata da otto invarianti, numerati I1–I7 e I9, e tre regole di runtime. Gli invarianti sono il contratto permanente — che ogni fase comunichi solo attraverso K, che Execute registri la sua voce di ledger prima di toccare il prompt, che Execute resti gated dall’umano a meno che un envelope limitato esplicito in manifest.yaml dica altrimenti. Le tre regole di runtime sono le decisioni momento-per-momento che il loop prende mentre gira.

Gate min-N

Non adattare mai su meno di N esecuzioni accumulate contro la versione corrente. Una singola esecuzione è un campione della distribuzione che il prompt induce; reagirvi è reagire al rumore di misura.

Anti-oscillazione

Analyze non può ri-proporre un’opzione che il registro annota come regredita contro lo stesso trigger. Il verificatore meccanico prefiltra su trigger-e-sezione; un grader giudica l’intento.

Proprietà di replay

Il primo snapshot più i diff ordinati del ledger devono ricostruire il prompt corrente esattamente, byte per byte — la proprietà che rende affidabile una storia di adattamento e sicuro un rollback.

Modalità refactor — il percorso alternativo che la modalità manage pianifica e riusa.

10 GET STARTED · INSTALL

Setup

Prometheus ships as one portable agent skill. The controlling file, SKILL.md, is the single always-loaded file — roughly 10 KB of YAML frontmatter plus the controlling procedure — and eighteen companion files (the reference corpus under references/ and assets/, plus CHANGELOG.md) sit alongside it and are pulled into context only at the step that needs them. Because it is written to be read progressively, installation is mostly a matter of making the folder discoverable to your runtime.

Runs across the agentic ecosystem — Claude Code · OpenAI Codex · opencode · Cursor · Gemini CLI · the Anthropic and OpenAI APIs · any skill-aware runtime — and as a Gemini Gem.

No build step · No dependencies · Auto-triggers on intent · MIT-licensed

Download the skill · Download the gem · also on GitHub

The steps below adapt to your runtime — use the pill above to switch between an agentic runtime (Claude Code, Codex, opencode, …) and Gemini Gem.

# drop the skill onto the search path
cp -a prometheus ~/.claude/skills/
# then just describe the prompt you need
> design a prompt for a support agent

10 INIZIA SUBITO · INSTALLAZIONE

Installazione

Prometheus è distribuito come un'unica skill portabile per agenti. Il file di controllo, SKILL.md, è l'unico file sempre caricato — circa 10 KB di frontmatter YAML più la procedura di controllo — e diciotto file di accompagnamento (il corpus di riferimento sotto references/ e assets/, più CHANGELOG.md) gli stanno accanto e vengono portati in contesto solo al passo che ne ha bisogno. Poiché è scritto per essere letto progressivamente, l'installazione consiste soprattutto nel rendere la cartella individuabile dal tuo runtime.

Funziona in tutto l’ecosistema agentico — Claude Code · OpenAI Codex · opencode · Cursor · Gemini CLI · le API Anthropic e OpenAI · ogni runtime con skill — e anche come Gemini Gem.

Nessuna compilazione · Nessuna dipendenza · Si attiva sull’intento · Con licenza MIT

Scarica la skill · Scarica la Gem · anche su GitHub

I passi seguenti si adattano al tuo runtime — usa il selettore qui sopra per passare da un runtime agentico (Claude Code, Codex, opencode, …) a Gemini Gem.

# metti la skill nel search path
cp -a prometheus ~/.claude/skills/
# poi descrivi il prompt che ti serve
> progetta un prompt per un agente di supporto

— READING MAP · SOURCES

Reading Map & Source Layout

The framework is one body of source read three ways. It ships as a portable agent skill that any skill-aware host can discover — Claude Code, OpenAI Codex, opencode, Cursor, Gemini CLI and the Anthropic and OpenAI APIs among them — and it is additionally ported to run as a Gemini Gem. The files are the same; what changes per runtime is how the host loads them and, for the ports, a small band of audit artifacts that record how faithfully the port was carried out.

Below is the reading map rendered for the runtime you have selected in the version pill above — the order to read the files in, a one-line note on when each one earns its place in context, and the exact install path. Start with SKILL.md: it is the router, and it frames everything else.

Source browser

Every file in the framework, viewed with the same offline viewer used by the in-context panels.

Research

Grounded in the research.

• Prompts as operators — A quantum semantic framework for natural language processing — Agostino et al., 2025 · arXiv:2506.10077
• Modular reasoning scaffold — Eliciting reasoning in language models with cognitive tools — IBM Research Zurich — Ebouky et al., 2025 · arXiv:2506.12115
• Why structure works — Emergent symbolic mechanisms support abstract reasoning in LLMs — Yang et al., ICML 2025 · arXiv:2502.20332
• Self-adaptive lifecycle — The vision of autonomic computing — the MAPE-K loop — Kephart & Chess, IBM — IEEE Computer, 2003 · IEEE Computer 36(1)
• Right altitude, examples over rules — Effective context engineering for AI agents — Anthropic · anthropic.com/engineering

— MAPPA DI LETTURA · SORGENTI

Mappa di lettura e struttura dei sorgenti

Il framework è un unico corpo di sorgente letto in tre modi. È distribuito come skill portabile per agenti che qualsiasi host compatibile può individuare — tra cui Claude Code, OpenAI Codex, opencode, Cursor, Gemini CLI e le API Anthropic e OpenAI — ed è inoltre portato per girare come Gemini Gem. I file sono gli stessi; ciò che cambia per ogni runtime è come l'host li carica e, per i port, una piccola serie di artefatti di audit che registrano quanto fedelmente il port è stato eseguito.

Qui sotto trovi la mappa di lettura resa per il runtime selezionato nel selettore versione qui sopra — l'ordine in cui leggere i file, una nota di una riga su quando ciascuno si guadagna il posto in contesto, e il percorso di installazione esatto. Inizia da SKILL.md: è il router, e inquadra tutto il resto.

Esplora sorgenti

Ogni file del framework, visualizzato con lo stesso viewer offline usato dai pannelli in contesto.

Ricerca

Radicato nella ricerca.

• Prompt come operatori — A quantum semantic framework for natural language processing — Agostino et al., 2025 · arXiv:2506.10077
• Impalcatura di ragionamento modulare — Eliciting reasoning in language models with cognitive tools — IBM Research Zurich — Ebouky et al., 2025 · arXiv:2506.12115
• Perché la struttura funziona — Emergent symbolic mechanisms support abstract reasoning in LLMs — Yang et al., ICML 2025 · arXiv:2502.20332
• Ciclo di vita auto-adattivo — The vision of autonomic computing — the MAPE-K loop — Kephart & Chess, IBM — IEEE Computer, 2003 · IEEE Computer 36(1)
• Giusta altitudine, esempi più che regole — Effective context engineering for AI agents — Anthropic · anthropic.com/engineering